They should prioritise the area where manual effort most directly causes policy failure. If the immediate problem is repetitive governance work, automation can stabilise execution quickly. If the deeper problem is fragmented systems and broken handoffs, platform replacement may be necessary first so automation does not simply accelerate a flawed process.
How to choose between automation and platform replacement
Public institutions should start with the point of failure, not the trend that sounds more modern. If the bottleneck is repetitive approvals, reconciliations, or case handling, automation can reduce delay and inconsistency quickly. If the bottleneck is structural, such as broken handoffs, duplicate records, or systems that cannot share trustworthy data, replacing the platform may be the only path that prevents automation from hardening a bad process.
The practical distinction is between accelerating work and repairing the system that produces the work. Automation is usually the faster intervention, but it assumes the underlying process is stable enough to codify. Platform replacement is slower and heavier, but it changes the operating model when manual work exists because the current architecture cannot support reliable execution.
That means the first question is not “which is cheaper?” but “what would still fail if every manual step were removed?” If the same failure would remain, the institution is dealing with a systems problem, not an effort problem. If the failure disappears once staff are relieved of repetitive coordination, automation is likely the right first move.
When automation should come first
Automation should lead when the institution already knows the process it wants, but the process is too slow, inconsistent, or labor intensive to run manually. Examples include routing requests, enforcing approvals, generating standard notices, or checking simple policy conditions. In those cases, automation improves throughput and control without forcing a major platform migration.
Done well, automation also creates useful visibility. It standardises the steps that were previously informal, which makes exceptions measurable and reveals where human intervention still adds value. That is often the best first investment when leaders need near-term operational relief and the existing platform can still support the intended workflow.
Automation becomes risky when it is used to compensate for fragmented records, inconsistent rules, or brittle integrations. If staff spend most of their time compensating for missing data or re-keying between systems, automation will only move the failure faster. In that situation, the organisation should treat automation as a temporary stabiliser, not the final answer.
When platform replacement has to come first
Platform replacement should come first when the core problem is not workflow volume but platform design. If the institution relies on disconnected systems, duplicated sources of truth, or manual workarounds to make basic transactions succeed, then automation may simply encode those weaknesses. Replacing the platform can be necessary to create a process that is coherent enough to automate safely later.
This is especially important where policy execution depends on consistent data, traceability, and handoff integrity. A new platform can consolidate records, reduce reconciliation effort, and remove duplicate control points that create delay and error. In those environments, automation before replacement can leave the institution with faster exceptions but no real control improvement.
Platform replacement also matters when the current system creates governance debt. If no one can reliably answer who changed what, when, or on what basis, then the institution has a control architecture problem. Automation may improve speed, but it cannot restore trust in processes that the underlying system cannot represent accurately.
Risk and Threat Considerations
The main risk is automating a broken process or preserving a broken platform for too long. Either choice can create policy failure, but the failure mode differs: automation can scale errors and exceptions rapidly, while delayed replacement can keep staff trapped in manual workarounds that are opaque and hard to audit.
Failure mechanism: If the institution automates a workflow built on inconsistent data, unclear ownership, or fragile handoffs, it can make incorrect decisions faster and at greater scale. If it keeps an obsolete platform in place too long, staff will continue to bypass controls and rely on informal fixes that weaken governance.
Impact: The result is slower service, weaker accountability, higher operational cost, and greater chance of policy non-compliance. In public settings, that can also damage trust because citizens experience the failure as inconsistency, delay, or unexplained denial.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Choosing automation vs replacement is a risk-based prioritisation decision. |
| Recommendation — Use a risk strategy to decide whether process automation or platform change reduces exposure fastest. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Platform replacement often addresses brittle, misconfigured, or unmanageable systems. |
| Recommendation — Standardise and harden the target platform before automating dependent workflows. | ||
| ISO/IEC 27001:2022 | A.5.37 — Documented Operating Procedures | The question turns on whether the current process is stable enough to codify and run consistently. |
| Recommendation — Document the workflow before automating so controls reflect the real process. | ||
Practitioner Guidance
What to verify: Test whether the process is stable enough to automate by checking if the inputs, decision rules, and exception paths are already understood. If the institution cannot describe the handoffs cleanly, treat platform replacement as the stronger candidate.
Decision rule: If the dominant pain is repetitive execution of a sound process, automate first. If the dominant pain is fragmented systems that distort the process itself, replace the platform first and defer deeper automation until the new operating model is in place.
What practitioners underestimate: The cheapest option is not always the lowest-risk option. Automation can deliver quick relief, but only platform replacement can remove structural defects that keep reappearing across teams, channels, and transactions.
Practitioner takeaway: Start with the failure mode, not the project category, because the right sequence is the one that fixes the root cause without locking the institution into a faster version of the same dysfunction.