Accountability sits with the leadership body that approves and oversees the risk measures, not only with technical teams. NIS2 makes that explicit by tying governance, oversight, and liability together, so boards and executives must be able to explain how resilience decisions were made before the incident and how containment was managed during it.
Why This Matters for Security Teams
NIS2 does not treat breach readiness as a narrow security-engineering issue. It links governance, oversight, and operational resilience, so the accountable body is the leadership body that approves the risk measures and can demonstrate that those measures were monitored, tested, and updated. That matters because regulators will look for evidence of informed oversight, not just the existence of controls.
For security teams, the practical challenge is that readiness failures often come from gaps between policy, funding, and execution. If incident response plans are stale, backups are untested, logging is incomplete, or escalation paths are unclear, the organisation may still face accountability even when technical teams acted in good faith. The NIS2 Directive makes this governance link explicit, and that is why board visibility matters as much as SOC capability.
Practitioners should also note that cyber incidents increasingly involve automation, identity abuse, and cross-domain dependency chains. When leadership treats readiness as a one-time compliance exercise, it misses the operational reality that the attack surface changes faster than annual reviews. In practice, many security teams encounter accountability questions only after containment has already failed, rather than through intentional resilience governance.
How It Works in Practice
Under NIS2, accountability typically sits with the management body or equivalent leadership layer, because that group is expected to approve risk-management measures and oversee their implementation. The security function, IT operations, and incident response teams still carry operational responsibility, but they are not the final point of accountability for governance failures. Current guidance suggests this distinction matters most where an organisation can show controls existed on paper but were not exercised, resourced, or measured effectively.
In practice, this means leadership must be able to evidence that readiness decisions were made deliberately. That usually includes risk acceptance, incident-response testing, supplier oversight, vulnerability remediation prioritisation, backup validation, and crisis communications planning. A useful benchmark is NIST SP 800-53 Rev 5 Security and Privacy Controls, which helps organisations translate governance expectations into implementable controls and review points.
Security teams should build an accountability chain that is visible before an incident, not improvised afterward:
- define who approves resilience risk and who signs off exceptions;
- map incident response ownership across legal, IT, security, and business continuity;
- test escalation paths and board reporting with realistic scenarios;
- track remediation deadlines and unresolved risk decisions;
- retain evidence of tabletop exercises, post-incident reviews, and corrective actions.
Where threat intelligence is mature, boards should also be briefed on emerging attack patterns, including identity-led and AI-assisted intrusion methods documented in the ENISA Threat Landscape and similar advisory material. These controls tend to break down when multi-entity environments have unclear ownership because no single leadership body can verify end-to-end readiness.
Common Variations and Edge Cases
Tighter governance often increases reporting overhead, requiring organisations to balance faster decision-making against the need for documented accountability. That tradeoff becomes sharper in groups with subsidiaries, outsourced IT, or shared service models, where legal responsibility and operational control may sit in different places. There is no universal standard for this yet, so organisations should treat local legal advice as part of the control design.
One edge case is the managed service arrangement. A provider may operate the tools, but the regulated entity usually still retains accountability for readiness outcomes if the leadership body approved the risk posture without verifying whether service levels, logging, recovery, and escalation were actually adequate. Another edge case is crisis conditions involving AI-assisted attacker activity. The Anthropic report on first AI-orchestrated cyber espionage campaign shows why preparedness now has to include faster detection, decision support, and human escalation, not just static policy documents.
The main exception is where local national transposition introduces more specific liability rules or sectoral supervision. In those cases, the broad NIS2 principle still applies, but the exact accountable party and sanction pathway may differ. Organisations should confirm whether internal committees, executive officers, or board-level bodies need named responsibilities in their governance records.
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 set the technical controls, while NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | Article 20 | Article 20 assigns management-body accountability for cybersecurity measures. |
| NIST CSF 2.0 | GV.RR | Governance roles and responsibilities define who owns resilience outcomes. |
Give the leadership body named oversight of readiness, approvals, and remediation tracking.
