Accountability usually sits with the organisation’s control owners, not the technology stack. For critical infrastructure, that means IAM, physical security, OT operations, and compliance teams must share clear ownership for review, approval, and revocation outcomes. If no one owns the full path, the gap becomes a recurring reliability risk.
Why This Matters for Security Teams
When a missing access review affects grid reliability, the issue is not just an IAM hygiene problem. It becomes a control ownership problem across operations, safety, compliance, and identity governance. In critical infrastructure, delayed recertification can leave stale privileges in place, weaken segregation of duties, and make it harder to prove that access decisions were timely and authorised. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a control accountability issue, not a tooling issue.
For utilities and adjacent operators, the real risk is that access reviews are often treated as a periodic checkbox instead of a reliability safeguard. If engineers, contractors, service accounts, and Non-Human Identities are all in scope, then the review process must cover human and machine access consistently. That is especially important where privileged access can touch OT consoles, remote maintenance paths, or safety-relevant systems. Current guidance suggests that accountability must be assigned to the control owner who can act, not merely observe.
In practice, many security teams encounter the failure only after a stale entitlement is used during an outage or maintenance window, rather than through intentional review discipline.
How It Works in Practice
Operational accountability should be defined before the review cycle begins. A clear model usually assigns the business risk to the asset or system owner, the process execution to IAM or PAM teams, and the technical validation to OT operations or engineering leads. Compliance may attest to completion, but it should not become the de facto owner unless it can also approve or revoke access. That separation matters because review findings often require operational judgment, not just policy checking.
Strong practice also includes evidence capture. Reviewers need to see who approved access, when it was last used, whether it is tied to a current work order, and whether the entitlement still matches job function. For privileged or service access, the control set should include session monitoring, break-glass handling, and timely revocation. Where automation or service accounts are involved, the OWASP Non-Human Identity Top 10 is useful for identifying why machine credentials are often missed in standard access review workflows.
- Define one accountable control owner for the full review path, including exceptions.
- Separate review execution from approval authority where segregation of duties is required.
- Include human, contractor, and Non-Human Identity access in the same review scope.
- Track revocation closure, not just review completion, because unresolved findings create residual risk.
- Align evidence to audit and incident response needs so reliability teams can show decision lineage.
Use the control baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls to map access review, account management, and accountability requirements to named owners. These controls tend to break down when access spans IT, OT, and third-party maintenance environments because no single team can see the full entitlement lifecycle.
Common Variations and Edge Cases
Tighter access review governance often increases operational overhead, requiring organisations to balance reliability protection against review fatigue and change velocity. That tradeoff becomes sharper in grid environments where access may be time-bound, vendor-managed, or tied to emergency response. Best practice is evolving here, and there is no universal standard for how to assign accountability across mixed IT and OT estates, especially when external operators or managed service providers hold part of the administrative chain.
One common edge case is the emergency override. If break-glass access is not reviewed promptly after use, the organisation may technically satisfy uptime goals while quietly expanding privileged exposure. Another is inherited access in shared operational platforms, where a team owns the system but not the identity source feeding it. In those cases, accountability should follow the ability to approve, revoke, and evidence the decision. That distinction is especially important when a missing review involves service accounts or agentic systems that continue operating after the business owner has changed.
For resilience and assurance purposes, the question should always be: who can actually close the gap, and who can prove that it was closed? Without that answer, access review becomes a reporting exercise instead of a reliability control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight define who owns control outcomes for reliability-impacting access reviews. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management governs review, approval, and revocation of user and system access. |
| OWASP Non-Human Identity Top 10 | Machine identities are often missed in access reviews but can affect grid operations. |
Include service accounts, tokens, and automation identities in the same review and revocation process.
