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.
Accountability for Access Reviews in Grid Operations
Missing access review become an accountability problem before they become a technical one. In grid and other critical infrastructure settings, the question is not simply who administers accounts, but who is responsible for proving that access remains appropriate as operating conditions change. That responsibility typically spans IAM, OT operations, physical security, and compliance, because each controls a different part of the access lifecycle. The most common failure is not a lack of tooling, but a blurred ownership boundary between systems that affect reliability and systems that affect permissioning. For a control perspective on review discipline, NIST SP 800-53 Rev 5 Security and Privacy Controls is the most directly relevant authority among the supplied links. In practice, many organisations discover the ownership gap only after an access exception has already outlived the operational need that created it.
How Missing Reviews Turn into Reliability Exposure
An access review is not just an audit task. In a grid environment, it is a recurring control that confirms whether privileged users, vendors, operators, and support paths still match current duty, location, and system criticality. When the review is skipped or deferred, stale access can persist across shift changes, maintenance windows, incident response periods, or vendor support arrangements. That creates a reliability issue because dormant or excessive access raises the chance of unsafe change, delayed revocation, or uncontrolled exception handling.
The accountability chain should be explicit. Control owners define who approves access, who certifies it, who can revoke it, and who verifies the outcome. IAM may run the process, but it usually cannot decide whether a control-room engineer, contractor, or third-party maintainer still needs access to a particular asset. OT operations normally validate operational necessity, while physical security may govern site access and escort requirements. Compliance then checks whether the process happened and whether evidence exists.
- If ownership is split, define one accountable owner for the end-to-end review outcome.
- If access touches both cyber and physical environments, review both permission sets together.
- If a revocation cannot be completed quickly, treat the exception as an operational risk, not a paperwork delay.
Where this guidance breaks down is in emergency access, where temporary elevation may be justified but must be time-bound and reconciled after the event.
When the Standard Ownership Model Needs Adjustment
Tighter access governance often increases coordination overhead, requiring organisations to balance speed against assurance. That tradeoff becomes especially visible in grid settings where urgent restoration work can conflict with normal approval cycles. The general rule is clear, but guidance-vs-consensus matters here: there is broad agreement that critical access should be reviewed regularly, yet organisations differ on how much of the certification burden should sit with central IAM versus asset-owning operations teams.
One edge case is vendor or integrator access during outage response. The access may be legitimate, but the review obligation does not disappear just because the work is urgent. Another is shared operational accounts, which can obscure accountability by making it hard to tell who actually used access and whether the reviewer understood the risk. A third edge case is cross-domain access, where a single person may need both remote logical access and physical entry rights. In those cases, treating the review as a single combined decision is often safer than certifying each layer in isolation.
For readers who want the control-language context behind review, approval, and revocation expectations, the supplied NIST control catalogue remains the best fit. For identity-bound machine access that sits behind automation rather than human operators, the OWASP Non-Human Identity Top 10 is relevant, but this question is primarily about human accountability for operational access decisions, not machine identity design.
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 and CIS Controls v8 set the technical controls, while NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Grid access reviews must align to critical-operations ownership and impact. |
| GV.RM-01 — Risk Management Strategy | Missing reviews create recurring operational risk that needs explicit acceptance or treatment. | |
| Recommendation — Define who owns review outcomes for access that can affect grid reliability. Treat missed access reviews as a managed reliability risk, not an admin miss. | ||
| CIS Controls v8 | 6.3 — Access Rights Review | This directly covers recurring review of accounts and privileges. |
| 5.4 — Account Audit and Control | Accountability depends on knowing who can approve, revoke, and attest access. | |
| Recommendation — Schedule and evidence regular access-rights reviews for critical operators and vendors. Maintain clear account ownership and audit trails for privileged access decisions. | ||
| NIS2 | Article 21 — Cybersecurity risk-management measures | Critical infrastructure operators need governance over access control measures impacting resilience. |
| Recommendation — Assign governance for access-control measures that protect service continuity. | ||
Practitioner Guidance
What to prioritise: Assign a single accountable owner for the review outcome, even if IAM, OT, and physical security each execute part of the workflow. If no one owns the final revocation decision, stale access will survive process handoffs.
What to verify: Confirm that each review produces evidence of approval, rejection, revocation, and exception handling, not just a completed checklist. For reliability-sensitive environments, the question is whether the control actually changed access state when needed.
Decision rule: If access supports live operations, treat missed certification as an operational exposure with reliability consequences, not a deferred administrative task. Escalate unresolved exceptions through the same governance path used for other material control failures.
Practitioner takeaway: In critical infrastructure, accountability fails when access review ownership is split across functions but never made executable at the point of revocation.
