If an automation can send, pay, delete, approve, disclose, or lock, assess the action before the launch date. The technology label does not matter much. A brittle RPA script can duplicate a payment. A deterministic workflow can email the wrong attachment. An AI step can route a case with misplaced confidence.
The useful unit of review is the transaction path: trigger, reads, decision, writes, notification, and recovery. An automation risk assessment follows that path and asks what happens when each link is wrong or unavailable.
We’re gmware, a software development firm headquartered in Austin, Texas, with engineering centers in Bangalore and Mohali, India. Our intelligent process automation work covers rule-based flows, RPA, and AI-assisted steps. Our opinion: the action path deserves more attention than the label on the tool.
This is not the same review as our AI risk assessment, which covers one bounded AI system and its use. The method here crosses rule-based workflows, RPA, integrations, and AI. It ends in an automation risk register that an operations owner can use during release and after the first incident.
Draw the transaction before naming risks
Start with a single sentence:
When an approved supplier invoice arrives, the workflow reads the purchase order, checks the total and supplier identity, creates a payable draft, and sends the draft to an accounts-payable reviewer.
Now mark the systems, identities, data, and side effects at each step. Write excluded actions next to the diagram. In this example, the workflow cannot create a supplier, change bank details, approve its own draft, or release payment.
Those exclusions are controls only after they exist in code, permissions, or configuration and have a test. A sentence in a design document does not stop an API call.
Keep inherent and residual risk separate
Inherent risk describes the exposure with no proposed control credited. Residual risk describes what remains after the control has been installed and tested.
Suppose a duplicate event could create the same payable twice. The inherent impact may be high and the likelihood plausible. A stable invoice identifier, a unique constraint, and a reconciliation check reduce the likelihood. The risk register should still record what happens if a supplier reuses an invoice number or if two legal entities share a numbering scheme.
This separation stops a common shortcut: writing “human review” in the control column and marking the risk low. A reviewer who sees no source evidence, handles 400 cases an hour, or cannot reject the draft is not much of a control.
The automation risk register
Use one row per credible failure. Link the evidence rather than pasting a screenshot into the cell.
| Field | What to record |
|---|---|
| Boundary | Trigger, permitted result, excluded action, systems, and owner |
| Failure | One concrete way the transaction can harm operations, a person, money, or data |
| Inherent risk | Impact and likelihood before the proposed control |
| Preventive control | Permission, validation, limit, separation, or rule that blocks the failure |
| Detective control | Log, reconciliation, alert, or review that exposes it |
| Recovery | Rollback, compensation, quarantine, replay, or manual correction |
| Evidence | Test case, trace, permission export, drill result, or operating record |
| Residual risk | Exposure that remains after tested controls |
| Owner and decision | Person authorized to accept, treat, defer, or stop |
| Reassessment trigger | Change or observation that reopens the row |
Use words before colors. “High” means little unless the row explains the consequence and why it is credible.
Review authority first
The first control question is simple: what can this identity do?
List read, draft, update, approve, send, and delete separately. Record value and volume limits. A workflow that creates a payment draft needs different authority from one that releases funds. If a vendor connector requires a broad administrator role, that is a design constraint to resolve, not a detail to hide.
Check indirect authority too. An automation that may edit a routing table can change where later transactions go. One that may change its own prompt or threshold can expand its decision surface without a code release.
Test the permission boundary with a forbidden action. A rejected API call is stronger evidence than a configuration screenshot.
Trace the data, including the error path
Name every data source, field, transformation, destination, retention period, and operator view. Then repeat the exercise for logs, dead-letter queues, screenshots, model traces, and support tickets. Error handling often copies more data than the normal path.
Ask four questions:
- Is this field needed for the stated action?
- Which system is authoritative when values disagree?
- Who can see the value in normal operation and during support?
- How is the value corrected or deleted everywhere it traveled?
Do not treat encryption as the whole data control. It protects data under defined conditions; it does not decide whether the workflow should have copied the field in the first place.
Test wrong decisions and wrong execution separately
A workflow can choose the wrong action, or execute the right action badly.
Decision errors include choosing the wrong customer, mapping a document to the wrong order, or accepting a value outside policy. Execution errors include doing the same write twice, completing half a multi-step transaction, sending an event out of order, or retrying after a timeout that actually succeeded.
The controls differ. Decision errors may need stronger evidence, a bounded rule, or a reviewer. Execution errors need idempotency, transaction state, reconciliation, and recovery. Combining both under “accuracy” leaves the engineering work unspecified.
For AI-assisted steps, the NIST AI Risk Management Framework is a useful companion. Its Govern, Map, Measure, and Manage functions keep context, measurement, ownership, and response in the same review. It does not replace transaction testing.
Break every dependency on purpose
Make a test list from the workflow’s dependencies: source system, identity provider, network, queue, model, destination API, notification channel, and human review queue.
For each one, simulate unavailable, slow, malformed, and recovered states. Observe the business result, not only the error log. The right outcome may be to preserve the case, block the side effect, alert an owner, and resume from a known checkpoint.
Watch for recovery storms. When a destination returns after an outage, a deep queue can replay faster than the destination or reviewers can handle. Rate and spend limits belong in the recovery plan.
The NIST Cybersecurity Framework 2.0 groups outcomes under Govern, Identify, Protect, Detect, Respond, and Recover. An automation review should not stop at protection. Detection, response, and recovery are what make an unexpected failure survivable.
Treat change as a fresh input
Automations inherit change from every dependency. A source adds a status, an API drops a field, a model version changes, an operator edits a mapping, or the business raises an approval limit.
Record which changes require:
- a schema compatibility check;
- the full regression set;
- a permission review;
- business-owner approval;
- a staged rollout; or
- a new risk decision.
Keep a versioned record of rules, prompts, mappings, connectors, and credentials. “No code changed” does not mean the automation stayed the same.
Make monitoring answer a business question
CPU and queue depth matter, but an operations owner needs to know whether the workflow is doing the intended job.
Useful signals include unmatched cases, duplicate suppression, reviewer overrides, forbidden-action attempts, reconciliation differences, time in queue, cost per completed transaction, and actions by permission level. Set an owner and a response for each alert.
Sample reviews can find errors that aggregate metrics miss. Choose samples by risk: new suppliers, high values, changed templates, rare routes, and cases near an approval boundary. Random sampling alone may spend most of its effort proving that ordinary cases are ordinary.
Set stop conditions before launch
Stop conditions turn risk language into authority. Examples include:
- any attempt to use an excluded action;
- a reconciliation difference above the agreed threshold;
- missing evidence for a consequential decision;
- an unowned alert or review queue;
- a material permission expansion;
- repeated failures outside the tested set; or
- inability to restore or compensate for a side effect.
Assign the person who can pause the system and the person who can authorize restart. They may be different. Practice the pause while the team is calm.
A worked assessment choice
Return to the invoice workflow. It reads documents and purchase orders, prepares a payable draft, and routes it to a reviewer.
The launch can proceed if duplicate prevention is enforced and tested, supplier changes are excluded, the reviewer sees source evidence, every draft is reconciled to the source, dependency failures create no payment, and the accounts-payable owner accepts the documented residual risk.
It stops if the connector requires payment-release authority, if a timeout can create an unknown duplicate, or if nobody owns the exception queue. Those are not future refinements. They are broken boundaries.
Our recommendation
Keep the first assessment short enough to run at a release meeting. Ten precise risks with tests beat sixty generic rows copied from a control library.
Then keep it alive. Reopen the affected rows after a change, a new failure pattern, a permission expansion, or a recovery drill that does not work. The register earns its keep when it changes a release or an operating decision.
If you need to map a workflow from trigger through recovery, bring the transaction and one known exception to an automation scoping session.