Governance for Automation: Access, Audit and Change Control

An automated process reads and writes production data, moves money, changes customer records and approves things. It is a participant in your control environment, and it has considerably less judgement than the person it replaced. Governance is not paperwork wrapped around automation after the fact. It is the set of controls that lets an automation estate grow past a handful of workflows without becoming something nobody is willing to sign off.

Every automation gets its own identity

The single most common governance failure in the field is automation running under a person's credentials. It happens for understandable reasons, usually to get a pilot working quickly, and it undermines everything else.

The consequences compound. The audit trail attributes machine actions to a human who was not involved. Permissions are inherited rather than scoped, so the automation can do everything that person can do. And when they change role or leave, the process breaks in a way that takes an afternoon to diagnose. Every workflow and every robot needs its own named service identity, provisioned and reviewed like any other account.

Scope permissions to the step, not the process

Least privilege is understood in principle and rarely applied at the right granularity in automation. An invoice workflow does not need write access to the supplier master file just because one step reads from it.

Scope permissions per step, review them when the workflow changes, and be particularly careful with steps that create or modify records rather than reading them. The question to ask of any automation is what the worst thing it could do would be if its logic were wrong, and then whether it needs the permission that makes that possible.

Credentials never live in the workflow

Credentials, API keys and connection strings belong in a secrets vault and are referenced by name from the workflow definition. This is not merely about avoiding a leak, though that matters. It is about being able to rotate a credential without editing and redeploying every workflow that uses it.

A workflow definition should be safe to export, review, diff and store in a repository. If it contains secrets, none of those things are true, and the practical result is that nobody reviews workflow changes at all.

If a workflow definition cannot safely be shown to a reviewer, it will not be reviewed. Secrets in workflow files quietly remove change control from the entire estate.

Environments and promotion

Automation needs the same environment discipline as any other production software: development, test and production kept separate, with promotion between them requiring a named approver.

The requirement people resist is a test environment with realistic data, because production data cannot simply be copied and synthetic data does not contain the awkward cases. The workable answer is usually a masked extract of real historical cases, chosen to include the exceptions. It is effort, and it is the difference between testing that proves something and testing that confirms the happy path still works.

Change control proportionate to blast radius

Not every change needs a change advisory board, and treating them all the same guarantees the process is bypassed. Tier it: adjusting a notification message is not the same as changing an approval threshold, which is not the same as altering how payment records are written.

• Low impact, such as wording, formatting or a routing rule inside one team: process owner approves
• Medium impact, such as a threshold, an approver or a validation rule: process owner plus the control owner
• High impact, such as anything touching financial posting, customer records or regulated data: full change control with a documented test result
• Every tier: versioned, diffable, attributable to a named person, and reversible in one step

An audit trail that cannot be edited

Every case should carry a complete, timestamped record: what happened at each step, which rule applied, what data was read and written, who approved what and when, and what any exception was and how it was resolved. Configuration changes belong in the same record.

The essential property is that it is append-only. Administrators should be able to read and export the log and be structurally unable to alter it. An audit trail that a sufficiently privileged person could edit provides comfort rather than assurance, and auditors have become quite good at telling the difference.

Plan the decommissioning

Processes get replaced, systems get retired, and automations outlive their purpose. Without a decommissioning practice you accumulate workflows nobody owns, still running, still holding permissions, still writing to systems, with nobody quite willing to be the person who turns them off.

Review the estate on a schedule. Anything with no owner, no recent executions or no clear purpose gets flagged, disabled for a defined observation period, then removed with its service identity and its permissions. The retired workflow definition and its audit history are retained for your normal retention period. Automation you have forgotten about is a control weakness, and it is invariably discovered by somebody other than you.