Treat the system as a governed exception, assign a named owner, document the manual evidence path and define a remediation plan to reduce the dependency. If the application stays out of automation indefinitely, the organisation should assume audit friction and residual access risk remain.
When an application cannot support automated review, what does governance need to replace it?
Automation is useful only when the application can expose the right entitlement, ownership and review data in a reliable way. When it cannot, the organisation should not pretend the control exists. The practical response is to run an exception process that preserves accountability, evidence and a clear path to eventual remediation rather than leaving the system as a blind spot.
That usually means treating the application as an approved manual-control dependency, with a named owner who can explain who reviews access, what evidence proves the review happened, and when the system will be brought back into scope.
What should the manual control model include?
The manual path needs to be precise enough that auditors and operators can follow it without guessing. A useful minimum is: define the review population, set a cadence, name the reviewer, record the evidence source, and track any exceptions or unresolved entitlements. If the application has privileged, shared or non-expiring access, the manual process should be stricter, not looser.
Where possible, the manual process should mirror the same decision logic as automated review, especially around ownership, least privilege and recertification. That keeps the exception from becoming a parallel governance model that slowly drifts away from the rest of the access programme. The goal is not to replace automation with a lighter ritual, but to preserve control quality in a less capable system.
For teams building a durable fallback, the access-review discipline in Access Reviews and Certification Guide is the closest match for turning review intent into a repeatable process. When the application is part of a broader lifecycle programme, IAM and IGA Basics helps anchor the manual review in governance rather than ad hoc operations.
How should organisations reduce the exception over time?
An unsupported review capability should be treated as a remediation problem, not a permanent operating model. The remediation plan should identify whether the blocker is a missing connector, poor entitlement structure, weak application design, or ownership gaps. That distinction matters because some systems need integration work, while others need governance redesign before automation is realistic.
Remediation should also be time bound. If the organisation leaves the exception open indefinitely, the manual process tends to weaken under volume and becomes vulnerable to stale entitlements, reviewer fatigue and inconsistent evidence. A named owner, target date and periodic progress review are what keep the exception from becoming institutionalised risk.
Where the application’s access model is the real issue, the role model and entitlement structure may need cleanup before automation can succeed. In practice, that is why Role Mining and Role Design Guide is relevant, because role sprawl and unclear ownership often block review automation long before tooling does.
Risk and Threat Considerations
When access review stays manual for long periods, the main risk is not just administrative friction. The organisation can lose visibility over who still needs access, who approved it, and whether dormant or excessive entitlements are accumulating. That creates a residual exposure even if the manual review is technically “done.”
Failure mechanism: the control depends on human follow-through, but the application does not provide enough structure or evidence to make review consistently repeatable. Over time, review quality degrades, exceptions multiply, and access that should have been removed remains in place.
Impact: audit evidence becomes harder to defend, access creep becomes more likely, and the organisation inherits a standing exception that can hide privilege or ownership problems until a review failure or incident forces attention.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CA-7 — Continuous Monitoring | Manual review exceptions need ongoing monitoring and evidence of control effectiveness. |
| AC-6 — Least Privilege | Access review exceptions must still enforce and validate minimal necessary access. | |
| Recommendation — Monitor the exception until automation or a compensating control is in place. Limit entitlements while the application remains outside automation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question concerns governed access review and control over application access. |
| A.5.18 — Access rights | Manual recertification and exception handling are access-rights governance activities. | |
| Recommendation — Document and operate access control for the manual-review exception. Review and record access rights until the application can be automated. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is how to manage access when automated certification is unavailable. |
| Recommendation — Use a documented manual access-control process with named ownership. | ||
Practitioner Guidance
What to prioritise: assign one accountable owner for the exception, then define the exact manual evidence required so the review is provable, not just claimed. If the evidence cannot show who reviewed what and when, the control is too weak to trust.
Decision rule: if the application can only be reviewed manually, treat any long-lived exception as temporary and time-boxed, with a remediation milestone attached. If the exception has no expiry or roadmap, it is no longer an exception, it is a control gap.
What to measure: track the number of unsupported applications, the age of each exception, and the percentage of access reviews completed with verifiable evidence. Those signals show whether the manual path is controlled or simply tolerated.
Practitioner takeaway: a non-automatable application should still be governable, but only if the organisation is explicit about ownership, evidence and exit criteria; otherwise the review process becomes a documentation exercise that leaves real access risk untouched.
Related resources from NHI Mgmt Group
- When should organizations review access controls?
- Should organisations support AI agent access on devices where the main VPN client cannot be installed?
- What breaks when access review and account recovery workflows cannot be fully automated?
- What breaks when organisations cannot provision and review access across all of their applications?