A programme has likely stalled at digitisation when paper forms become online forms, but the underlying workflow remains unchanged. Common signs include repeated manual approvals, redundant checker roles, and no use of built-in validation to block incomplete submissions. In that state, the organisation has modernised the interface but not improved the business process.
Where digitisation ends and transformation begins
Digitisation changes the channel; transformation changes the operating model. A government programme has usually stalled when citizens can submit a form online, but staff still re-key data, chase signatures, and route cases through the same approval chain that existed on paper. The key question is whether the service has been redesigned around the transaction, or merely wrapped in a digital front end.
That distinction matters because many public-sector failures are not technology failures at all. They are design failures that leave duplicate work, poor data quality, slow decisions, and inconsistent service outcomes in place. The NIST Cybersecurity Framework 2.0 is useful here only as a reminder that governance and process discipline have to be explicit, not implied by the presence of an online system. In practice, many government teams discover they have digitised forms, not transformed services, only after users and frontline staff start working around the new system to get the old process completed.
How the pattern shows up in live services
Stalled programmes usually reveal themselves in the flow of work, not in the project charter. If a service still depends on manual review for every routine request, the digital channel is only the intake layer. If staff validate information after submission instead of preventing bad data at the point of capture, the programme has not changed the control model. If the same case is touched by multiple teams for reasons nobody can clearly justify, the process has been translated into software without being rethought.
Other indicators are more subtle. A transformation effort should reduce friction for both citizens and employees, but digitisation-only programmes often replace visible paper delays with less visible queueing inside back-office worklists. They may also preserve old policy assumptions, such as requiring approvals that no longer add value or insisting on attachments that can be derived from authoritative data sources. When that happens, the organisation pays for software while still carrying the cost of the old process.
- Look for workflows that still depend on humans to route, reconcile, or re-enter information that the system already has.
- Check whether validation happens before submission or only after an analyst opens the case.
- Test whether exception handling is a genuine edge case or the de facto normal path.
- Compare the original paper process with the digital version and ask what has actually been removed.
The guidance breaks down when legal or policy constraints genuinely require manual review, because not every approval can be automated without changing the underlying accountability model.
Common variations and boundary cases
Tighter control over public services often increases implementation effort, so organisations need to balance faster delivery against legitimate assurance and fairness requirements. That tradeoff is especially important in government, where some manual checks exist for defensible reasons rather than because the workflow has failed.
There is also a difference between a service that is still being sequenced toward transformation and one that has genuinely stopped. Early programmes may digitise first to stabilise demand, standardise data, or reduce processing risk before redesigning the end-to-end service. That is a valid phased approach. The warning sign is persistence: if the same manual steps, duplicate checks, and paper-era approvals remain after the system has been in production long enough to learn from actual usage, the programme is probably not on a transformation path.
Guidance is not fully consensus-based on whether every government service should aim for full automation. The practical test is narrower: does the digital service reduce the number of handoffs, improve data quality at source, and remove work that no longer adds value? If the answer is no, the programme may still be delivering convenience, but it is not changing the service model.
Risk and Threat Considerations
When a modernisation programme stops at digitisation, the main risk is not just inefficiency. The organisation can inherit faster intake with the same weak controls, which means errors, fraud opportunities, and backlog pressure move into a digital queue instead of being removed from the process. That creates exposure where the interface looks modern but the control environment still depends on human workarounds.
Failure mechanism: The programme preserves paper-era approval logic, duplicate checking, and late-stage validation, so bad data, unnecessary exceptions, and manual bypasses continue to accumulate. In adversarial terms, that kind of design makes it easier for abuse to hide inside routine exceptions or overloaded review queues.
Impact: Service quality stays inconsistent, operational cost remains high, and decision integrity weakens because staff spend time reconciling avoidable exceptions instead of handling genuinely complex cases.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Modernisation scope should reflect service outcomes, not just channel changes. |
| GV.RM-02 — Risk Management Strategy | Stalled digitisation leaves legacy process risk and control gaps in place. | |
| Recommendation — Define target service outcomes so process redesign is measured against business value, not digitised throughput. Use risk strategy reviews to challenge duplicated approvals and late-stage manual controls that no longer add value. | ||
| CIS Controls v8 | 17 — Incident Response Management | Operational workarounds and queue overloads can mask control failure in digital services. |
| 4 — Secure Configuration of Enterprise Assets and Software | Transformation requires workflow and validation logic to be configured, not only the user interface. | |
| Recommendation — Monitor exception-heavy workflows so recurring bypass patterns are escalated before they become normal operation. Harden workflow rules and field validation so incomplete or incorrect submissions are blocked at source. | ||
| MITRE ATT&CK | T1204 — User Execution | Users and staff may revert to workarounds when digital processes do not fit the real workflow. |
| Recommendation — Hunt for repeated manual workarounds that indicate the new system is being bypassed in practice. | ||
Practitioner Guidance
What to verify: Test the service end to end, not just the front door. A real transformation should remove at least one meaningful handoff, one recurring manual check, or one category of preventable rework; if it does not, the programme is likely only digitising the old process.
Decision rule: If the digital journey still depends on routine human intervention to complete normal cases, treat that as evidence of incomplete redesign, not as an implementation detail to be tolerated indefinitely. If human review is still required, require a clear policy reason and a measurable exception rate.
Practitioner takeaway: The most reliable sign of transformation is not a web form, but the disappearance of work that existed only because the old paper process was never challenged.
Related resources from NHI Mgmt Group
- When does AI transformation become an IAM problem instead of a business programme?
- How should organisations govern access across many APIs in a digital transformation programme?
- Who should own PKI modernisation decisions in an enterprise identity programme?
- Who is accountable for access when a vendor supports a transformation programme?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
