They should govern them as exceptions with explicit ownership, documented manual controls, and stronger verification of revocation. If automation is impossible, the control objective shifts to making manual execution auditable, repeatable, and tied to application criticality rather than leaving it informal.
When automation is impossible, what changes in the control model?
The main change is that governance stops being about tool-driven lifecycle enforcement and becomes an exception-control problem. For apps that cannot connect to identity tooling, teams need explicit ownership, a documented manual process, and clear evidence that revoke, review, and access changes still happen on time. The control objective is not perfect automation, it is disciplined compensating control.
That means the application should be treated as a named exception with a known owner, a defined review cadence, and a repeatable operating procedure. If the app sits outside the identity control plane, the team must still be able to show who can approve access, who executes removal, and what proof exists that access was actually removed. A manual process that cannot be evidenced is functionally the same as no control.
This is also where application criticality matters. Low-risk exceptions can tolerate slower manual handling, but higher-impact systems need tighter verification, faster revocation SLAs, and stronger escalation if an entitlement cannot be removed through normal automation. Manual governance should be documented with the same rigor you would expect from an automated workflow, because the absence of automation increases the need for consistency, not less.
What does good exception governance look like in practice?
Good governance starts with scope. Teams should inventory the apps that cannot be automated, classify why they are excluded, and decide whether the blocker is technical, commercial, legacy, or operational. That classification matters because different causes imply different remedies, and some exceptions should be temporary while others are long-lived but tightly controlled.
Once the exception is known, manual controls need to be concrete. The team should define who approves access, who performs changes, how revocation is confirmed, where evidence is stored, and what happens if the normal owner is unavailable. If the control relies on email, tickets, or spreadsheets, those channels need enough structure that the process remains auditable and repeatable under stress.
For lifecycle governance, the most important point is that revocation deserves stronger verification than request approval. Approval says a change was authorised; it does not prove the app stopped granting access. Where automation is missing, teams should require a second-person check, a log review, or a post-change validation step so that removal is confirmed rather than assumed. NHI Lifecycle Management Guide is useful here because it frames lifecycle, rotation, and offboarding as governance outcomes, not just technical events.
At the portfolio level, teams should also look for patterns. If many exceptions point to the same legacy platform, the issue may be architectural rather than operational, and the right response may be an integration project or replacement plan. If exceptions are increasing faster than the team can review them, the organisation is carrying hidden identity debt. IGA Buyer's Guide helps practitioners think about lifecycle, reviews, and disconnected applications as part of platform selection and governance.
Which risks make manual governance brittle?
Manual exception handling becomes risky when ownership is vague, revocation is delayed, or evidence is incomplete. The main exposure is not that the app is manual, it is that manual steps drift, get forgotten, or vary by operator, which creates inconsistent privilege removal and weak auditability. Over time that can leave dormant access, unreviewed privilege, and unclear accountability in place long after the exception was approved.
Failure mechanism: The control fails when teams trust a request closure or an approval record without verifying the downstream system state. In practice, that means access can look removed in tickets while the application still retains it, especially when no connector exists to enforce or confirm the change.
Impact: The result is residual access, slower incident response, and a larger blast radius if an account, credential, or admin path is later abused. It also weakens audit evidence because the organisation cannot prove the manual process is repeatable under pressure.
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 | IA-5 — Authenticator Management | Manual app governance still depends on credential lifecycle and revocation control. |
| AC-2 — Account Management | Exception handling requires explicit ownership, provisioning, and deprovisioning accountability. | |
| Recommendation — Enforce documented revocation and rotation steps for every manually governed application credential. Assign accountable owners and require tracked account creation, review, and removal for each exception app. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Exception governance is fundamentally about controlled access where automation is unavailable. |
| A.5.18 — Access rights | The question centers on review and revocation of rights when tooling cannot enforce them. | |
| Recommendation — Define manual access rules, approval paths, and periodic verification for unsupported applications. Review and revoke exception-app rights on a fixed schedule with evidence of completion. | ||
| CIS Controls v8 | CIS-5 — Account Management | Manual exceptions need disciplined account ownership, provisioning, and removal controls. |
| Recommendation — Inventory exception apps and enforce owner-attested account lifecycle reviews. | ||
Practitioner Guidance
What to prioritise: Prioritise the exceptions that can still create material exposure if access lingers, especially privileged, shared, or production-facing apps. Those deserve the strongest manual verification and the shortest revocation path.
What to verify: Verify that every exception has a named owner, a fallback approver, a documented revoke step, and a validation record showing the access change actually took effect. If any of those are missing, the exception is not yet governable.
Common mistake: Treating an exception as acceptable because the team has a ticket, a spreadsheet, or an email thread. Those artefacts support governance only when they map to a repeatable operating procedure and a proof point for revocation.
Practitioner takeaway: The goal is not to force every app into automation, it is to make every manual path sufficiently owned, evidenced, and verifiable that the exception cannot become a permanent blind spot.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org