Accountability sits with the operators that own the environment, even when outside vendors, integrators, or security partners are involved. For critical infrastructure, leadership must ensure resilience planning, containment controls, and recovery procedures are funded, tested, and maintained. Security teams can advise on architecture, but operational responsibility remains with the organisation running the facilities and services.
Why This Matters for Security Teams
In critical infrastructure, accountability for cyber risk cannot be outsourced to vendors, managed service providers, or system integrators. The operator that runs the facility or service owns the safety, availability, and recovery outcomes, even when technology stacks are assembled by third parties. That is why leadership needs clear governance for asset ownership, escalation paths, and recovery objectives, not just contractual assurances. The NIST Cybersecurity Framework 2.0 is useful here because it frames risk management as an enterprise responsibility, not a tooling exercise.
Practitioners often get this wrong by treating cyber risk as a compliance task delegated to IT or a quarterly audit item. In reality, critical services fail when operational leaders cannot explain who approves risk acceptance, who funds remediation, and who can trigger containment during an incident. That accountability gap becomes more severe when control systems, cloud dependencies, and remote access paths intersect across business units and suppliers. In practice, many security teams encounter this only after a disruption has already exposed unclear ownership, rather than through intentional governance design.
How It Works in Practice
Accountability should be mapped to the organisation’s operating model, not to the location of the technology. For utilities, transport, energy, healthcare, and water systems, the board and executive leadership set risk appetite, while operational owners translate that appetite into control implementation, testing, and recovery planning. Security, engineering, and operations each contribute, but one accountable executive must own the decision trail for residual risk and service continuity.
Effective programmes usually separate three questions: who owns the asset, who operates the control, and who is accountable for the business outcome. That distinction matters when suppliers provide monitoring, cloud hosting, OT support, or incident response. External parties can perform tasks, but they should not become the primary accountability point for cyber risk decisions. Guidance from CISA cyber threat advisories and control mappings in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for monitored safeguards, tested response procedures, and traceable ownership.
- Assign one accountable executive for cyber risk in each critical service line.
- Document which controls are run by the operator and which are delegated to suppliers.
- Test containment, failover, and manual fallback procedures on a recurring basis.
- Track exceptions, compensating controls, and risk acceptance in a formal register.
- Include identity, remote access, and privileged session controls in resilience reviews.
Where AI-assisted monitoring or autonomous response tools are used, accountability still remains with the operator. The tool may accelerate detection, but it does not replace human responsibility for policy, escalation, and recovery decisions. These controls tend to break down when legacy OT environments, multi-layer outsourcing, and weak asset inventory processes make it impossible to prove who can act during a live incident.
Common Variations and Edge Cases
Tighter accountability often increases governance overhead, requiring organisations to balance faster decision-making against more formal risk ownership. That tradeoff becomes visible in multi-tenant environments, public-private partnerships, and highly regulated sectors where operational control is shared but liability is not always obvious.
There is no universal standard for every supply chain structure, but current guidance suggests that shared-service models still need a clearly named accountable owner inside the operating organisation. In some cases, legal liability may sit with different parties under contract, yet cyber accountability for resilience remains with the entity that delivers the service to the public or to regulated customers. This is especially important where national reporting obligations apply, including the EU NIS2 Directive, which places explicit expectations on managed risk and executive oversight.
AI-enabled threats add another layer of complexity. If defenders use agentic tools for triage, or attackers use autonomous systems to accelerate reconnaissance, the operator still owns the cyber risk decision. Resources such as the MITRE ATLAS adversarial AI threat matrix and the Anthropic report on an AI-orchestrated cyber espionage campaign show why governance must extend to automation, not just traditional infrastructure. The same applies to emerging operational experiments such as Anthropic Project Glasswing, where accountability for outcomes cannot be delegated to the model itself.
For NHI and privileged access governance, the practical takeaway is simple: if a system, service, or agent can take action in a critical environment, someone inside the operating organisation must own the risk, the control, and the recovery decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF, NIST SP 800-53 Rev 5 and EU-NIS2 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 cyber risk decisions in critical services. |
| NIST AI RMF | GOVERN | AI-assisted operations still need accountability, policy, and human oversight. |
| MITRE ATLAS | T1589 | Adversarial AI threats expand the attack surface for critical infrastructure defenders. |
| NIST SP 800-53 Rev 5 | PM-9 | Risk management requires defined roles, responsibilities, and authority. |
| EU-NIS2 | NIS2 places executive responsibility on essential and important entities. |
Assign human owners for AI use in operations and document approval, escalation, and review paths.
Related resources from NHI Mgmt Group
- Why do manual access processes create risk in critical infrastructure environments?
- Who is accountable when cyber incident reporting timelines tighten for critical infrastructure and federal programmes?
- Who is accountable when machine identity controls fail in critical infrastructure?
- How can DevSecOps prove that infrastructure as code is reducing risk?
