vaayaa Inclusive Education
Technical risk assessment

Robotic Process Automation Risk Assessment: Bot Access, Data Handling and Change Controls

A worked example of how a technical team finds, scores and controls the risks of software bots that move data between business systems, covering credentials, data exposure, change control, vendor dependence and recovery.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: High to Medium
See the Robotic Process Automation course

Executive summary

This assessment shows how a shared services team can find, rate and control the risks of software bots that read and write business data. Eight risks were chosen because they are plausible in everyday running, change and support work. Credential compromise and data exposure in logs score highest before controls, while insider misuse and vendor dependence carry serious consequences even when unlikely. Each risk is scored before controls and again after existing and additional controls. Most risks fall to Medium or Low once the added controls are in place, but credential compromise and data exposure remain Medium because the impact stays serious. The first actions are secret rotation, log masking, change approval and a tested rollback. The scenario is a teaching example, so every score illustrates method rather than describing any real organization.

Focus area
Robotic process automation for business workflows
Setting
Shared services team that runs software bots across finance, customer records and reporting systems, with a central automation platform
Method
Five by five likelihood and impact risk register

Scope

This assessment covers software robots that log in to business applications, read and enter data, and move files between systems, from design and deployment through daily running, change and retirement. It looks at risks to confidentiality, integrity and availability, identity, logging, vendors and legal duties. It does not cover any real platform, client or data set. The jurisdiction, platform vendor, system count and data types are assumptions made for teaching, and they are labeled as such in the assumptions field.

Context

The team operates a central automation platform with a development environment, a test environment and a production environment. Bots run on dedicated virtual machines and use service accounts to sign in to finance, customer and reporting applications. A small group of developers builds the workflows, an operations team schedules and monitors them, and a vendor supplies the platform and updates. Each risk is scored before controls to show its natural level, then again after the existing controls and the additional controls that should be added.

Objectives, assets and stakeholders

The objective is to run automated workflows that are accurate, available and secure, while protecting personal data and meeting records and reporting duties. The assets in scope are the automation platform, service accounts and their secrets, bot host machines, workflow code, operational logs, queues and the business data the bots touch. Stakeholders include developers, operations staff, data protection and compliance staff, application owners, customers whose data is processed, auditors and the platform vendor. Clear roles matter: every risk has one owner role, and the head of shared services keeps the register current and reports to the governance group each quarter.

Risk matrix: before and after controls

Each cell shows hazard numbers placed by likelihood and impact. Compare the two grids to see how controls move each hazard.

Before controls

Inherent risk

Risk before controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely Likelihood 4, impact 3, score 12, high: H03 H04 Likelihood 4, impact 4, score 16, high: H01
3 Possible Likelihood 3, impact 3, score 9, medium: H08 Likelihood 3, impact 4, score 12, high: H05 H07 Likelihood 3, impact 5, score 15, high: H02
2 Unlikely Likelihood 2, impact 5, score 10, high: H06
1 Rare

After controls

Residual risk

Risk after controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely
3 Possible Likelihood 3, impact 2, score 6, medium: H04
2 Unlikely Likelihood 2, impact 2, score 4, low: H08 Likelihood 2, impact 3, score 6, medium: H03 H05 H06 H07 Likelihood 2, impact 4, score 8, medium: H01 H02
1 Rare
  • Low 1 to 4
  • Medium 5 to 9
  • High 10 to 16
  • Critical 17 to 25

Hazard register

A summary first, then the detail for each hazard.

Summary of hazards with scores before and after controls
No.HazardBeforeAfterOwner
H01 Bot credential compromise and unauthorized access 16 High 8 Medium Platform security lead
H02 Sensitive data exposure in bot logs and work queues 15 High 8 Medium Data protection officer
H03 Uncontrolled workflow changes and misconfiguration 12 High 6 Medium Automation development lead
H04 Service disruption when target applications change 12 High 6 Medium Operations manager
H05 Phishing and malware on bot host machines 12 High 6 Medium Infrastructure security engineer
H06 Insider misuse of bot privileges 10 High 6 Medium Head of shared services
H07 Vendor and supply chain exposure in the automation platform 12 High 6 Medium Procurement and vendor manager
H08 Weak records, retention and audit trail for automated decisions 9 Medium 4 Low Compliance officer
H01

Bot credential compromise and unauthorized access

Technology and data Before 16 After 8

Service account passwords or keys used by bots are stolen, shared or left in scripts, letting an attacker sign in to business applications as a trusted robot and read or change records without notice.

Who or what is affected: Customers, finance staff and system owners

Causes

Hard-coded secrets, broad account rights and shared vault access between teams.

Consequences

Unauthorized changes to records, data theft, lost trust and a notifiable incident.

Existing controls

  • Bot credentials are stored in a managed vault rather than in workflow files.
  • Service accounts are separate from personal user accounts.

Control gaps

Vault access is reviewed only when a person leaves, and some older workflows still hold secrets.

Additional controls

  • Prevent: Use short-lived tokens and rotate every service account secret on a fixed schedule.
  • Detect: Alert when a service account signs in from an unknown host or outside its scheduled window.
Likelihood 4 x impact 4 before; 2 x 4 after Owner: Platform security lead Target: Within 30 days Early warning: A service account sign in from a host that is not on the approved bot machine list.
H02

Sensitive data exposure in bot logs and work queues

Technology and data Before 15 After 8

Bots write customer identifiers, account numbers or payment details into debug logs, screenshots and work queues, where people without a need to know can read them or copy them out.

Who or what is affected: Customers, data protection staff and auditors

Causes

Verbose logging during development, default screenshot settings and queues shared across teams.

Consequences

Unauthorized disclosure, regulator contact, customer harm and rework of retained data.

Existing controls

  • Production logs are kept on the platform and not exported by default.
  • Developers are asked not to print personal fields during testing.

Control gaps

Logs from test runs are copied to shared folders, and no one checks them for personal fields.

Additional controls

  • Prevent: Mask or tokenize sensitive fields at the point the bot reads them and block them from debug output.
  • Detect: Scan log stores and work queues for patterns that match personal identifiers each week.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Data protection officer Target: Within 45 days Early warning: Log scans that find unmasked identifiers in a production or shared store.
H03

Uncontrolled workflow changes and misconfiguration

Operational Before 12 After 6

A workflow is edited directly in production, a rule is set to the wrong value or a test setting is left active, so bots begin to process records incorrectly without an approved change record.

Who or what is affected: Finance staff, customers and reporting users

Causes

Urgent fixes, weak separation between environments and manual edits to configuration values.

Consequences

Wrong postings, duplicate transactions, reporting errors and emergency rework.

Existing controls

  • Workflows are stored in a version control system with named authors.
  • Changes to production need a ticket number before release.

Control gaps

Emergency changes skip review, and rollback has not been tested on a live schedule.

Additional controls

  • Prevent: Require a second reviewer and a test run in a staging environment before any production release.
  • Recover: Keep the last approved version of every workflow ready for rollback within one hour.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: Automation development lead Target: Within 30 days Early warning: A production change with no linked approval record in the change log.
H04

Service disruption when target applications change

Operational Before 12 After 6

An update to a web page, screen layout or application interface breaks the bot's steps, so transactions stop, queues back up and deadlines are missed without any clear warning.

Who or what is affected: Operations staff, customers waiting for service and budget holders

Causes

Frequent vendor and application updates, brittle selectors and no notice from application owners.

Consequences

Missed service levels, backlogs, overtime and customer complaints.

Existing controls

  • Operations staff receive failure alerts from the platform.
  • Bots are run in a daily batch with a manual restart option.

Control gaps

Application owners do not notify the team before releases, and the manual fallback is not rehearsed.

Additional controls

  • Detect: Run a daily health check that replays a sample transaction on each key application.
  • Respond: Keep a manual procedure with named staff ready to process the queue during an outage.
Likelihood 4 x impact 3 before; 3 x 2 after Owner: Operations manager Target: Within 60 days Early warning: Failed bot runs or queue age above the agreed service level for two consecutive cycles.
H05

Phishing and malware on bot host machines

Technology and data Before 12 After 6

A bot host is infected through a phishing link, a malicious download or an unpatched component, and malware can capture the credentials the bot uses or alter the data it handles.

Who or what is affected: Platform operators, application owners and data subjects

Causes

Email links opened on administrative accounts, unpatched operating systems and browser plugins.

Consequences

Credential theft, data tampering, service outage and a costly rebuild.

Existing controls

  • Bot hosts run endpoint protection that is updated automatically.
  • Bot hosts are kept on a separate network segment from user desktops.

Control gaps

Bot hosts are not always included in patch reports, and no one checks for unexpected software.

Additional controls

  • Prevent: Apply security patches on a fixed monthly cycle and remove unused software from bot hosts.
  • Recover: Rebuild infected bot hosts from a tested image and rotate every credential they held.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Infrastructure security engineer Target: Within 45 days Early warning: Endpoint protection alerts on a bot host or an unexpected process that starts during a scheduled run.
H06

Insider misuse of bot privileges

People Before 10 After 6

A developer or operator edits a workflow to move funds, change records or export data for personal gain, using the broad rights that the bot already holds and hiding the action among routine runs.

Who or what is affected: Finance staff, customers and the business as a whole

Causes

Broad access rights, weak supervision of developers and pressure to deliver quickly.

Consequences

Financial loss, disciplinary action, legal action and damage to trust in automated processes.

Existing controls

  • Bot run histories are kept for the platform's standard retention period.
  • Staff sign a confidentiality and acceptable use agreement when they join.

Control gaps

Developers can change production workflows directly, and monthly reviews do not compare changes with tickets.

Additional controls

  • Prevent: Remove standing rights from people who only need to monitor runs and grant developer access on request.
  • Detect: Review changes made by each developer against approved tickets each month.
Likelihood 2 x impact 5 before; 2 x 3 after Owner: Head of shared services Target: Within 60 days Early warning: A workflow change made outside the approved window or by a person not on the release list.
H07

Vendor and supply chain exposure in the automation platform

Supplier Before 12 After 6

The platform vendor or a component it relies on suffers an outage, a security flaw or a change in terms, leaving the organization unable to run bots or unable to show where its data is held.

Who or what is affected: Shared services, procurement and every business unit that depends on bots

Causes

Reliance on one platform, subcontracted hosting and short notice of changes to terms.

Consequences

Service loss, unmanaged data transfer, unexpected cost and a delayed move to alternatives.

Existing controls

  • The platform contract includes service levels and a support route.
  • Vendor security reports are requested each year.

Control gaps

The exit plan is not updated when workflows change, and vendor reports are not reviewed against contract terms.

Additional controls

  • Prevent: Check each vendor's security evidence and data location before renewal or new modules are added.
  • Respond: Maintain an exit plan that lists the workflows, data and skills needed to move to another platform.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Procurement and vendor manager Target: Within 90 days Early warning: A vendor notice of an outage, a material change in terms or a change in hosting location.
H08

Weak records, retention and audit trail for automated decisions

Legal and compliance Before 9 After 4

Bots make or apply rules that affect customers, but the reasons, versions and outcomes are not kept in a form that can be explained, checked or produced when a duty requires it.

Who or what is affected: Customers, auditors and compliance staff

Causes

Logs that are overwritten after short periods, unclear ownership of rules and no link between versions and runs.

Consequences

Inability to answer an audit or customer query, and possible breach of records duties.

Existing controls

  • Run outcomes are recorded in the platform's history log.
  • Retention periods are set for the main finance records.

Control gaps

Retention settings for run logs have not been checked against the records policy.

Additional controls

  • Detect: Sample completed runs each quarter and check that the rule version, inputs and outputs can be traced.
  • Recover: Store signed copies of each released workflow version for the period set by the records policy.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Compliance officer Target: Within 90 days Early warning: A run that cannot be traced to a released workflow version within the retention period.

Rating method and evaluation

Each risk is rated on two five-point scales. Likelihood runs from Rare to Almost certain, and impact runs from Insignificant to Catastrophic. Multiplying the two gives a score from 1 to 25, which falls into one of four bands: Low from 1 to 4, Medium from 5 to 9, High from 10 to 16 and Critical from 17 to 25. The score is a guide for ordering work, not a measurement. Inherent risk is the score before any controls. Residual risk is the score after the existing and additional controls. Impact is judged on data harm, service loss, financial effect, legal exposure and trust. A risk is never rated down only because it has not yet happened. Anything still High needs senior attention and a dated plan, anything Medium needs routine controls with a named owner, and anything Low is accepted and watched. Developers, operators and application owners should challenge the ratings, and any risk is reviewed when its early warning indicator reaches the escalation point or when the platform, a vendor or a key application changes.

Likelihood, impact and rating bands

Likelihood

  • 5 Almost certain: Expected to happen in most circumstances.
  • 4 Likely: Will probably happen in many circumstances.
  • 3 Possible: Could happen at some time.
  • 2 Unlikely: Not expected, but it could happen.
  • 1 Rare: Only in exceptional circumstances.

Impact

  • 1 Insignificant: No lasting effect. Handled within routine work.
  • 2 Minor: Small effect that is quickly corrected.
  • 3 Moderate: Noticeable effect that needs managed effort to correct.
  • 4 Major: Serious effect on people, delivery or reputation.
  • 5 Catastrophic: Severe or lasting effect that threatens the whole activity.

Bands (likelihood x impact)

  • Low (1 to 4): Accept and monitor.
  • Medium (5 to 9): Manage with routine controls.
  • High (10 to 16): Senior attention and a treatment plan.
  • Critical (17 to 25): Act first. Do not proceed until reduced.

Monitoring, escalation and review

Review this assessment every 6 months, and sooner when an indicator below reaches its threshold.

Early-warning indicators and escalation thresholds
Indicator to watchEscalate when
Service account sign ins from hosts or times outside the approved bot schedule.Escalate to the platform security lead at once, and suspend the account until the sign in is explained.
Unmasked personal identifiers found in production logs or shared work queues.Escalate to the data protection officer within one working day, and clear the store within a week.
Production workflow changes without a linked approved ticket.Escalate to the head of shared services when any unapproved change is found, and roll back within 24 hours.
Failed bot runs or queue age above the agreed service level for two cycles.Escalate to the operations manager at once, and to the head of shared services if service is not restored within a day.
Vendor notices of outages, security issues or changes to terms or hosting location.Escalate to the procurement and vendor manager within one day, and to the governance group if the notice affects live services.

Contingency arrangements

If a serious event occurs, such as a confirmed credential compromise, a data exposure or a bot that is corrupting records, the operations manager pauses the affected workflows and blocks the related service accounts. The platform security lead rotates secrets and isolates the host. The data protection officer assesses notification duties through the relevant authority, as required in the applicable jurisdiction. Manual processing runs from the documented fallback, and affected customers and business owners are told what they need to know early and plainly.

Prioritized action plan

  1. Rotate all service account secrets and move them into a managed vault with access reviews, owner platform security lead, within 30 days.
  2. Mask personal fields in logs and scan shared queues for identifiers, owner data protection officer, within 45 days.
  3. Require a second reviewer and staging test before every production release, owner automation development lead, within 30 days.
  4. Patch bot hosts on a fixed monthly cycle and rebuild them from a tested image, owner infrastructure security engineer, within 45 days.
  5. Prepare and rehearse a manual fallback and a vendor exit plan, owner operations manager, within 90 days.

Conclusion

Reliable automation depends on a few steady habits: managed secrets, masked logs, reviewed changes, patched hosts, tested rollback and a clear exit plan for each vendor. The highest scores sit with credentials, data exposure and change control, and each has actions that bring the residual score down. Treat the register as a living record, review it on the stated cycle, and seek qualified security and legal advice for any real platform, data or regulatory question.

Assumptions and limitations

Assumptions

  • The organization has a central automation platform that is hosted by a third-party vendor under a standard service agreement.
  • Bots use service accounts with passwords or keys stored in a managed vault, and the team has access to vault audit logs.
  • Jurisdiction and applicable privacy rules are not specified, so legal duties are described in general terms only.

Limitations

  • The scores are examples for learning and do not describe any real platform, bot estate or organization.
  • Security, privacy and records rules differ by country and change over time, so specialist review is needed.
  • This is educational content and does not replace a formal site-specific assessment or advice from licensed security or legal professionals.

Related frameworks to study

  • Hierarchy of controls for ordering treatments
  • Least privilege access model for service accounts
  • Three lines model of risk ownership
  • Secure development lifecycle concepts for workflow design

Technical Risk Assessment

China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.

For Learning Reference Only: This assessment demonstrates how risk assessment principles are applied in a practical setting, providing a useful reference for learning and understanding. Actual assessments may be adapted to suit specific site conditions and circumstances.

Keep learning

Study the subject behind this assessment.

Robotic Process Automation course Read the best practices for this course

More Technical risk assessments

Hourly Active: 35,186 Learners