Ownership should sit with a clearly accountable business leader, supported by security, risk, legal, and operations teams. Because the rules require a coordinated view of hazards across multiple domains, responsibility cannot rest with one technical function alone. Board oversight is also essential, since the annual report must be approved at that level and submitted to regulators on schedule.
Why ownership has to sit above the individual risk silos
Critical infrastructure risk management only works when the owner can reconcile cyber, physical, supply chain, and personnel exposure as one operating problem. If ownership is split across technical teams, the organisation usually gets fragmented escalation, inconsistent prioritisation, and weak accountability when a single event crosses domain boundaries.
The practical question is not which function sees the most incidents. It is which leader can accept responsibility for the full risk picture, set the decision threshold, and force trade-offs to be resolved instead of deferred. That owner needs authority over the business outcome, with security, risk, legal, and operations providing the specialist inputs that shape it.
When critical infrastructure depends on suppliers, contractors, facilities, and privileged systems at the same time, the ownership model must reflect the blast radius of failure, not the internal org chart. A CISA Industrial Control Systems context is a good example of why this cannot be treated as a narrow IT issue, because operational impact often depends on both technical and non-technical dependencies.
One useful reference point is the ENISA Threat Landscape, which repeatedly shows that critical services fail through combinations of technical intrusion, supply chain weakness, and operational disruption. Ownership has to be broad enough to connect those failure modes before they become an incident chain.
What accountable ownership looks like in practice
Accountable ownership is not a steering committee and it is not a shared inbox. It is a named business leader who can make decisions about risk acceptance, remediation priority, exception handling, and escalation when cyber, physical, supply chain, and people risks collide. The supporting functions advise and execute, but the owner is the one accountable for the integrated outcome.
The owner should also be close enough to the operating model to understand dependency chains, supplier concentration, site-level constraints, and workforce issues such as access revocation, contractor oversight, and segregation of duties. That matters because a vulnerability in a supplier, a badge-control issue, or a stale privileged account may all become the same business failure if they point to the same asset or service.
For organisations trying to formalise that integrated model, the NHI Lifecycle Management Guide is useful for the governance pattern it illustrates: visibility, ownership, rotation, and offboarding all have to be managed as lifecycle duties, not ad hoc fixes. The same governance logic applies when infrastructure risk spans multiple domains.
The strongest operating model is usually one where the business owner owns the risk decision, while domain specialists own the control design and evidence. That separation avoids the common failure where technical teams are asked to “own” a business risk they cannot actually accept or resolve on their own.
Risk and Threat Considerations
When ownership is unclear, the main risk is not just slower remediation, but unowned failure paths. A supplier issue can become a cyber issue, a personnel issue can become an access issue, and a physical site issue can become an availability issue before any one team recognises the full exposure.
Failure mechanism: Split ownership creates gaps between domain-specific controls, so no single leader is accountable for correlated risk, exception approval, or cross-domain escalation. That gap is where attackers, operational failures, and supplier dependency problems tend to persist.
Impact: The organisation is more likely to miss connected warning signs, delay action, and understate the combined consequence of a single event. In critical infrastructure, that can mean service interruption, regulatory failure, or a loss of trust that is larger than any one domain team expected.
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.RM-01 — Risk Management Strategy | Integrated infrastructure risk needs a named owner and enterprise risk treatment. |
| GV.OV-01 — Organizational Context | Ownership must reflect the business service and its dependencies, not one silo. | |
| GV.SC-01 — Cyber Supply Chain Risk Management Strategy | Supply chain overlap is central to the ownership question. | |
| Recommendation — Assign enterprise ownership and set risk tolerances for cross-domain infrastructure exposure. Define the critical service, its dependencies, and the accountable business owner. Assign governance for supplier risk across procurement, operations, and security. | ||
| NIS2 | Article 20 — Management Body Responsibility | NIS2 places accountability for cyber risk and oversight at management body level. |
| Article 21 — Cybersecurity Risk-Management Measures | Requires coordinated measures across operational and supply chain dependencies. | |
| Recommendation — Ensure senior management owns and oversees the entity's risk posture and decisions. Implement coordinated controls for incidents, suppliers, access, and resilience. | ||
| CIS Controls v8 | CIS 17 — Incident Response Management | Cross-domain overlap needs a clear escalation and response owner. |
| CIS 15 — Service Provider Management | Supplier and third-party risk is part of the ownership problem. | |
| CIS 6 — Access Control Management | Personnel overlap often includes privileged access and joiner-mover-leaver duties. | |
| Recommendation — Define one incident owner and test escalation paths across all affected teams. Inventory service providers and assign accountable oversight for their risk. Centralise access decisions and review privileged access on a defined cadence. | ||
Practitioner Guidance
What to prioritise: Assign one named business owner for the integrated risk decision, then define which teams supply evidence, which teams execute remediation, and which issues require board-level escalation. If nobody can approve the trade-off, the ownership model is not real.
What to verify: Confirm that the owner can see all four risk classes in one view, can force action across departments, and is accountable for documented exceptions. If the operating model only covers cyber controls or only covers site operations, it is too narrow for this problem.
Practitioner takeaway: Cross-domain critical infrastructure risk should be owned by the leader who can resolve trade-offs at the business level, because the danger comes from overlap, not from any single domain in isolation.
Related resources from NHI Mgmt Group
- Who should own supply chain risk management when disruptions hit?
- Who should own AI-era cyber defense hardening when risk spans government, vendors, and critical infrastructure operators?
- How should critical infrastructure operators build a SOCI-aligned risk management program for cyber resilience?
- What is the difference between a Critical Infrastructure Risk Management Program and enhanced cyber security obligations under SOCI?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
