Accountability sits with the governance process that allowed the access trail to fragment. If approver authority, policy version, or exception ownership is not preserved, no reviewer can reliably determine whether the access remains valid. That is a governance design failure, not just an administrative miss.
Why accountability shifts when approval context changes
Accountability is no longer tied to the original approval moment once the conditions that justified access have changed. The real question is whether the organisation can still prove why the access remains valid, under which policy, and who owns the exception if it does. When that chain breaks, the problem moves from approval hygiene to governance accountability.
The access decision has a lifecycle, not a single point in time. If the approver’s authority expires, the policy is updated, or an exception is created without durable ownership, the approval trail can no longer answer a basic audit question: who is responsible for the continued grant? That is why access governance must preserve decision context, not just the fact that someone clicked approve.
In practice, this is where identity governance, entitlement review, and exception management intersect. IAM and IGA Basics is useful here because it frames approval as part of a broader control model, where provisioning, review, and recertification must stay aligned as conditions change.
What gets lost when the access trail fragments
When approval context is not preserved, the access record can still look complete while the underlying decision becomes meaningless. A stale approver, an outdated policy, or an undocumented exception means the reviewer cannot tell whether access was intentionally retained, accidentally left open, or silently inherited from a prior state. The system may show permission, but it no longer shows legitimate authority.
This is especially visible in organisations that treat approvals as one-time workflow events instead of governed authorisations with retained evidence. Access Reviews and Certification Guide is relevant because it focuses on closing that loop, not just collecting signatures, and on making review outcomes traceable to removal, renewal, or exception handling.
Where the access is tied to cloud or workload access paths, the same issue can appear in service accounts, roles, or federated identities rather than human user accounts. Cloud Workload Identity Guide helps illustrate how access can persist through technical bindings even after the original approval rationale has gone stale.
Who should own the decision to keep or revoke access?
The accountable party is the governance function that owns the access control process, not the individual reviewer after the fact. If the organisation cannot tell whether approval authority, policy version, or exception ownership was current at the time of decision, then accountability sits with the process design that allowed those facts to be lost.
NIST Cybersecurity Framework 2.0 supports this view because governance and access control are not separate concerns, they are linked obligations. The same is true in control-driven programmes that need durable evidence of who approved what, under which rules, and for how long.
That also means ownership must be explicit for exceptions, not just for standard access requests. If the exception is open-ended or the approver’s mandate has changed, someone still has to own the decision to keep the access in place, or to retire it. Without that ownership, the organisation has created access without accountable authority.
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, 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 CSF 2.0 | GV.OC-01 — Organisational Context | Accountability depends on defined governance context for access decisions. |
| GV.OV-01 — Oversight of Cybersecurity Risk Strategy | Ongoing review is needed when approval context changes and access persists. | |
| Recommendation — Define decision ownership for access approvals and exceptions. Require periodic oversight of active access against current policy and authority. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Account management must preserve valid authorization and revocation decisions over time. |
| AC-6 — Least Privilege | Stale access after a context change often leaves privileges broader than justified. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Auditability is essential to prove why access remains valid after changes. | |
| Recommendation — Track, review, and revoke accounts when approval authority changes. Reduce permissions to the minimum still justified by current authority. Retain evidence that links each access grant to current approval context. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control requires current authority, not just a historic approval event. |
| A.5.16 — Identity management | Identity records must reflect who currently has authority to approve or own access. | |
| A.5.18 — Access rights | Access rights need periodic review when the approval basis changes. | |
| Recommendation — Enforce access rules that reflect current business need and authority. Keep approver and owner records current when roles change. Review and adjust access rights when the approval context changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account governance needs to remove or revalidate access when approvals age out. |
| Recommendation — Review active access and remove permissions that no longer have valid justification. | ||
Practitioner Guidance
What to verify: Confirm that every active access grant can be traced to a current policy version, a valid approver authority, and a named owner for any exception. If any one of those three is missing, treat the access as governance-degraded even if the permission technically still works.
Decision rule: If the approval context has changed and no durable authority record exists, do not assume the access is still valid. Escalate for recertification or revocation based on the remaining evidence, not on workflow history alone.
What practitioners underestimate: The hardest failure is not excess access itself, but the inability to explain why it was allowed to persist. That is what turns a review issue into an accountability issue.
Practitioner takeaway: Access ownership must survive policy change, role change, and exception change, otherwise the organisation can no longer defend the decision to keep the access alive.
Related resources from NHI Mgmt Group
- Who is accountable when an application keeps access after a user leaves the directory?
- Who is accountable when a leaver still has SaaS access after offboarding?
- Who is accountable when user access remains active after offboarding?
- Who is accountable when a former employee still has access after offboarding?