Safety Norms: Robotic Process Automation

1Purpose, scope, and safety principles

These norms govern the design, development, testing, deployment, operation, and retirement of robotic process automation bots in our organization. An RPA bot is software that imitates a human operator by logging into applications, reading screens or data fields, copying values, clicking controls, and passing results to other systems. Scope covers attended bots that run alongside staff, unattended bots that run on schedules or triggers, and the orchestration, credential vault, and logging platforms that support them.

The governing principle is that a bot must never have more access, speed, or autonomy than its documented purpose requires. Because bots act at machine speed and often without a person watching, one defect can repeat thousands of times before anyone notices. Safety here means protecting the people whose data is processed, the staff who depend on bot outputs, customers, and the organization from harm caused by bot actions.

• Mandatory: every production bot must have a written purpose, owner, and approved scope.
• Mandatory: no bot may run in production without completing the change process in the records and review sections or its local equivalent.
• Recommendation: treat RPA as a controlled process change, not a desktop convenience.

2Roles, competence, and accountability

The bot sponsor owns the business outcome and approves process scope. The process owner defines the rules the bot must follow and accepts residual risk. The RPA developer builds and tests the workflow. The platform administrator manages the orchestrator, licenses, environments, and credential vault. The information security lead reviews access and data handling. The operations team monitors runs and responds to alerts. Each bot must have named individuals for these roles, and the same person should not both approve and test the same change where this can be avoided.

Competence is demonstrated, not assumed. Developers must complete internal RPA training and work under supervision until a documented review is passed. Anyone with administrator rights must be authorized in writing. Where a process touches regulated data, such as health, financial, legal, or identity records, the process owner must confirm that the developer understands the applicable obligations, and specialist advice must be obtained from qualified professionals.

• Mandatory: assign one accountable owner and one named backup for every bot.
• Mandatory: grant privileged platform rights only through written authorization that is reviewed each review cycle.
• Recommendation: pair new developers with an experienced reviewer for their first three production releases.

3Hazards and risk assessment

Common hazards include credential misuse, where a bot stores or exposes passwords or tokens; over-privileged access, where a bot can read or change records beyond its task; data exposure, where personal or confidential information is written to logs, emails, or shared folders; incorrect transactions, where a bot posts wrong amounts, duplicates orders, or sends messages to the wrong recipients; cascading failure, where a bot keeps running after an upstream system changes its screens or fields; and unsafe human interaction, such as an attended bot taking over a workstation and causing lost work or blocked employees.

Assess each bot before build and again before each major change. Rate likelihood and severity on a five-point scale, using transaction volume, data sensitivity, reversibility of actions, and the number of people affected. Bots that move money, change customer or patient records, release regulated communications, or handle sensitive personal data are high risk by default and need additional approval. Record the assessment and chosen controls in the bot register.

• Mandatory: complete a documented risk assessment before any production deployment.
• Mandatory: classify any bot that can alter financial, health, legal, or identity records as high risk.
• Recommendation: estimate the maximum number of transactions a faulty bot could process in one hour and set run limits to match.

4Preventive controls and safe operating practices

Least privilege is the primary control. Each bot receives a dedicated service identity with only the application roles it needs. Credentials must be held in an approved credential vault, never embedded in workflow files, scripts, spreadsheets, or source control. Secrets must be rotated on a schedule set by the security team and immediately after suspected exposure. Bots must not share identities with people or with other bots.

Design for safe failure. Workflows must validate inputs before acting, stop when expected screens, fields, or control totals do not match, and never guess. Use approval gates for high-impact actions, such as payments above a documented threshold. Build duplicate checks so a restarted bot does not repeat a completed transaction. Apply retry limits that end in a halt and an alert rather than endless loops. Test exception paths, not only the normal path.

Stop capability is mandatory. Every unattended bot must be stoppable from the orchestrator by an authorized operator, and every attended bot must let the user pause or cancel at any step. Document the stop procedure and test it during each release. Stop functions and queue pauses must be verified, not assumed.

Change control applies to all bots. Develop in a non-production environment using synthetic or masked data. Test against a copy of the target application where available. Peer review code and configuration, keep them under version control, and retain prior versions for rollback. Before go-live, run a controlled pilot with monitoring in place and a named person available to stop it.

Safe practices for attended bots include locking the workstation when the bot is idle, not running bots on shared kiosks or unmanaged machines, and not allowing a bot to operate in the same session as sensitive manual work unless the design isolates the two.

• Mandatory: no hard-coded credentials in any workflow, script, or configuration file.
• Mandatory: every bot must have a tested stop method and a documented rollback plan.
• Mandatory: high-impact actions must require a human approval gate or a documented independent check.
• Recommendation: schedule heavy unattended runs outside peak business hours to reduce contention on shared systems.
• Recommendation: use test environments that mirror production security settings but contain no live personal data.

5Tools, environment, information, and protective safeguards

RPA has no conventional personal protective equipment, but equivalent safeguards are required. Workstations and virtual machines hosting bots must meet the organization's endpoint security baseline, including patching, malware protection, screen lock, and logging. Staff who supervise attended bots for long periods should receive ergonomic guidance on screen position, lighting, and breaks, and supervisors should schedule rest periods. Servers hosting bots must restrict administrative access, both physical and remote, to authorized personnel.

Information safeguards matter as much as technical ones. Limit the personal data a bot collects to the minimum the task requires. Mask or truncate sensitive fields in logs, screenshots, and error messages. Do not keep extracted data beyond the approved retention period, and confirm that deletion routines work. Privacy and data protection duties vary by jurisdiction and sector, so confirm them with the privacy office and qualified legal advisers before a bot handles a new data type.

Environmental controls cover the energy and hardware footprint of always-on bots and virtual machines. Retire unused bots, decommission idle servers, and record the infrastructure each bot consumes. Do not allow test or disposable environments to remain provisioned indefinitely.

• Mandatory: bot logs must not contain full account numbers, passwords, tokens, or unmasked identifiers.
• Mandatory: run bots only on managed, patched machines approved by the platform administrator.
• Recommendation: review bot access and data flows whenever a connected application changes its interface or data model.
• Recommendation: review infrastructure use each review cycle and retire bots that have no active owner.

6Incident, near-miss, emergency, and escalation

Any unexpected bot behavior is an incident candidate. Examples include wrong postings, duplicate transactions, unexpected outgoing emails, user account lockouts, unauthorized data access, and runs outside the approved schedule. Near misses, such as a bot rejecting a bad input before harm occurred, must also be reported because they reveal control weaknesses. Staff must report within the window set by local policy. The first person to notice must stop the bot or pause its queue if it is still active.

Respond in this order: stop or pause the bot, preserve logs and run history, notify the bot owner and the on-duty operations lead, assess who or what has been affected, and escalate to the information security team for suspected data exposure or credential compromise. Do not repair production data by hand without the process owner's written approval. Do not delete logs or remove evidence before security review. Where a bot has harmed people, customers, or regulated records, escalate immediately to the relevant incident and compliance functions.

Emergencies, such as a bot sending large volumes of sensitive data outside the organization or interfering with critical systems, require immediate escalation to the emergency contact named in the business continuity plan. Where a suspected breach carries legal reporting duties, follow qualified legal advice, since notification obligations are jurisdiction dependent.

• Mandatory: stop the affected bot first, then investigate.
• Mandatory: record every incident and near miss in the central register within the local reporting window.
• Mandatory: do not rerun a failed transaction batch until the root cause is documented and approved.

7Records, training, and maintenance

Maintain a bot register listing purpose, owner, risk rating, data types, credential references (never the credentials themselves), environments, schedules, dependencies, and last review date. Keep change records, test evidence, approval records, and version history. Documentation must be accurate enough that a new developer could safely take over a bot without relying on memory.

Training is required before access is granted. Developers, administrators, approvers, and operators each need role-specific training covering these norms, the platform, and incident steps. Refresh training after significant platform or policy changes. Maintenance includes patching the orchestrator and runtime, updating dependencies, checking that selectors and interface references still match the target applications, and testing recovery after platform upgrades. Schedule maintenance windows and notify affected business teams in advance.

• Mandatory: each bot must appear in the register before production use.
• Mandatory: maintain a tested recovery procedure for the orchestrator and credential vault.
• Recommendation: keep a short runbook for each bot with start, stop, and escalation steps.

8Monitoring, review, and continuous improvement

Monitor run success rates, exception counts, processing times, queue depth, access attempts, and credential failures. Set alert thresholds for each bot based on its normal pattern. Alerts must reach a named person or monitored queue, not an unattended mailbox. Review dashboards at a frequency proportionate to bot risk, with high-risk bots reviewed more often than low-risk ones.

Hold formal reviews each review cycle defined by the organization. Review access rights, data flows, exception trends, incidents, and whether the bot still serves its business purpose. Retire or redesign bots whose controls no longer match their risk. Feed lessons from incidents back into these norms and into developer training. Confirm that this document and local procedures reflect current laws, standards, and vendor guidance by consulting qualified professionals and the relevant competent authorities.

• Mandatory: review high-risk bots against their risk assessment at the frequency set in that assessment.
• Mandatory: suspend any bot whose controls no longer match its risk rating until corrective action is approved.
• Recommendation: share a short summary of incidents and corrective actions with all bot owners.

Implementation checklist

• Confirm the bot has a written purpose, named owner, named backup, and risk rating.
• Verify that all credentials are stored in the approved vault and none are embedded in code.
• Confirm the bot uses a least-privilege service identity limited to required application roles.
• Test the stop method and rollback plan in a non-production environment before release.
• Check that input validation, approval gates, duplicate checks, and retry limits are in place.
• Confirm logs and screenshots mask sensitive fields and follow the approved retention rules.
• Verify the bot runs only on managed, patched, and approved machines.
• Ensure the bot is recorded in the register with current documentation and runbook.
• Confirm the on-duty operator knows the escalation path and the emergency contact.
• Schedule the next review and confirm legal and standards requirements with qualified advisers.