Who is accountable when cyber resilience controls fail under NIS2 and DORA?

Why This Matters for Security Teams

Under NIS2 and DORA, resilience failures are not treated as a purely technical event. They expose whether leadership has assigned ownership for access decisions, incident escalation, supplier risk, and evidence retention. That means accountability must be traceable before a control fails, not assigned after an audit or outage. The regulatory pressure is reinforced by practical lessons from NHI incidents, including patterns documented in the 52 NHI breaches Report and the regulatory framing in Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

Security teams often assume “the platform team owns it” or “the SOC will catch it,” but NIS2 and DORA expect clearer lines of responsibility. The organisation must be able to show who approved privilege, who monitored it, who could revoke it, and who escalated when telemetry showed drift. That expectation aligns with the operational focus of the EU Digital Operational Resilience Act (DORA) and the legal obligations in the EU NIS2 Directive. In practice, many security teams encounter ownership gaps only after an outage, when no one can prove who accepted the risk or who had authority to act.

How It Works in Practice

Accountability under these regimes is operational, not symbolic. A board or executive sponsor may carry ultimate responsibility, but day-to-day accountability must be delegated to named control owners with measurable duties. For privileged access, that typically means the identity team owns issuance and review, the platform or application owner owns business justification, and incident response owns containment when abuse is detected. Current guidance suggests this should be supported by evidence, not by policy statements alone.

In practice, teams should define control ownership around the full lifecycle of access and resilience:

• Who approves standing or elevated access, and on what basis.
• Who validates that controls are tested, not just designed.
• Who receives alerts when access or supplier risk drifts outside policy.
• Who can revoke credentials, isolate systems, and preserve evidence.
• Who reports failures to leadership and regulators when thresholds are crossed.

This becomes especially important where secrets, tokens, and service credentials are involved. NHIMG’s research shows how fast exposure can turn into misuse, and why access decisions need tighter governance than conventional user IAM. The pattern is echoed in The State of Secrets in AppSec, where remediation time lags behind confidence in control maturity, and in the broader threat landscape covered by CISA cyber threat advisories.

Good practice is to maintain a control register that maps each resilience control to one accountable owner, one backup owner, one evidence source, and one escalation path. These controls tend to break down when access is shared across cloud, DevOps, and third parties because no single team has end-to-end authority over the failure domain.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance rapid response against formal approval chains. That tradeoff becomes sharper in outsourced operations, shared-service environments, and group structures where local teams run the platform but central governance owns policy. Best practice is evolving, but there is no universal standard for whether accountability sits with the business service owner, the CISO function, or the legal entity in every case.

Three edge cases create recurring confusion. First, supplier-managed controls: the vendor may operate the system, but the regulated organisation still needs a named internal owner who can challenge evidence and trigger action. Second, cross-border operations: a global control may be technically consistent, but accountability must still be mapped to the entity that reports under NIS2 or DORA. Third, shared privilege models: when multiple teams can mint, approve, or revoke secrets, accountability becomes diluted unless one role is explicitly accountable for the control outcome.

Where organisations get into trouble is treating “responsibility” as a committee and “accountability” as a document. The practical standard is simpler: if the organisation cannot show who could have prevented the failure, who noticed it, and who had authority to act, then the control ownership model is not resilient enough for regulatory scrutiny. That is the same lesson reflected in Top 10 NHI Issues and the breach patterns in 52 NHI Breaches Analysis.

Related resources from NHI Mgmt Group

• Who is accountable when identity controls fail under NIS2?
• Who is accountable when identity controls fail under DORA?
• Who is accountable when identity controls fail under NYDFS?
• Who is accountable when VPN-based access controls fail under the Online Safety Act?