DORA and NIS2 raise the bar for cyber resilience and reporting

At a glance

What this is: This is an analysis of how DORA and NIS2 change cybersecurity compliance, resilience, and accountability for regulated organisations and their providers.

Why it matters: It matters because IAM, PAM, and broader security teams must align access, monitoring, supplier governance, and incident response to regulatory obligations that now carry financial and executive consequences.

By the numbers:

• In 2024, the Synnovis ransomware attack disrupted more than 10,000 medical outpatient appointments in the UK.
• The Collins Aerospace ransomware attack in September 2025 grounded flights at four major airports across London, Brussels, Dublin, and Berlin.
• DORA is implemented as of January 2025 for financial entities operating in the EU.

👉 Read Expel's analysis of DORA and NIS2 compliance obligations

Context

DORA and NIS2 expose the same governance gap from different angles: too many organisations still treat resilience as a technical control set rather than a regulated operating requirement. In practice, the issue is not whether teams can detect incidents, but whether they can prove risk management, reporting, testing, and accountability under sustained pressure.

For identity and access teams, the intersection is direct. Third-party access, privileged accounts, and service provider relationships sit inside the compliance scope, which means IAM, PAM, and lifecycle controls now influence whether an organisation can demonstrate operational resilience, not just security posture.

Key questions

Q: How should organisations align IAM with DORA and NIS2 requirements?

A: They should map identity controls to the obligations that regulators will test in practice, especially access governance, incident reporting, supplier oversight, and recovery evidence. IAM and PAM teams need clear ownership, review cycles, and logging that can support audit and incident response under pressure.

Q: Why does third-party access create so much regulatory risk under DORA and NIS2?

A: Because third-party access often bypasses the same lifecycle discipline applied to employees, yet it can still affect regulated systems and reporting obligations. If supplier identities are not reviewed, offboarded, and monitored with the same rigour, organisations lose the evidence needed to prove control.

Q: How do security teams know if resilience testing is actually working?

A: Look for evidence that testing is recurring, mapped to critical controls, and tied to remediation outcomes. If validation never changes priorities, never exposes weak paths, or never informs board reporting, it is not measuring resilience. Effective programmes show reduced exposure, faster containment, and clearer recovery proof over time.

Q: Who is accountable when a DORA or NIS2 incident fails to meet reporting obligations?

A: Accountability should be explicit before an incident occurs, because both frameworks push responsibility upward into leadership and operational ownership. The organisation needs named decision-makers for detection, escalation, evidence collection, and regulatory notification, otherwise response becomes fragmented and hard to defend.

Technical breakdown

How DORA changes resilience expectations for financial entities

DORA turns cyber resilience into a formal operating standard for financial entities and their providers. Its core requirements cover ICT risk management, incident reporting, resilience testing, and information sharing. That makes visibility across systems, suppliers, and privileged access paths a compliance issue, not just a security practice. The regulation also pushes responsibility upward, because boards and executives must be able to demonstrate that resilience is actively governed rather than assumed. For IAM and PAM teams, this raises the bar on who has access, how quickly access can be reviewed, and whether privileged activity can be traced during an incident.

Practical implication: map privileged access, supplier access, and incident evidence to a single resilience reporting process.

How NIS2 extends accountability across critical sectors and supply chains

NIS2 broadens the compliance surface beyond finance to essential and important entities, including energy, transport, healthcare, digital services, and public administration. The directive emphasises risk management, supply chain security, incident handling, and business continuity, which means organisations must understand not only their own controls but also the resilience of connected providers. This is where identity governance becomes relevant again, because third-party access and delegated administrative rights often define how far a supply chain issue can spread. The governance challenge is proving that access, reporting, and containment are all controlled across organisational boundaries.

Practical implication: extend supplier access reviews and offboarding controls into your NIS2 control evidence set.

Why reporting deadlines and resilience testing are now control problems

Both DORA and NIS2 make speed, evidence, and repeatability central to compliance. Incident reporting is no longer a post-incident communication task; it is a control outcome that depends on logging quality, ownership clarity, and rehearsed decision paths. Similarly, resilience testing is only meaningful if the organisation can show that findings flow back into corrective action. In identity programmes, this means access review cycles, privileged session controls, and emergency access processes must be auditable under pressure. The technical gap is often not detection, but operational proof.

Practical implication: test whether your access, logging, and escalation workflows can support regulatory reporting under live incident conditions.

NHI Mgmt Group analysis

Resilience regulation is now an identity governance problem as much as a security problem. DORA and NIS2 both depend on being able to prove who has access, who approved it, and who can act during an incident. That puts IAM, PAM, and supplier offboarding in the regulatory path, not just the defensive one. Organisations that treat access governance as separate from compliance will struggle to evidence control when regulators ask for proof.

Third-party access is the practical weak point in both frameworks. The article’s emphasis on suppliers is the real warning, because delegated access and service-provider relationships are how many incidents become reportable events. Where access is not lifecycle-managed, reporting, containment, and accountability all become harder to demonstrate. The governance lesson is that supplier identities must be treated as regulated assets.

Control evidence matters more than policy statements. Both regimes reward organisations that can show operational testing, monitoring, and incident handling in action. That is a direct challenge to security programmes that rely on written standards without traceable execution. Practitioners should assume auditors will ask for evidence of access reviews, privileged session oversight, and response rehearsals, not just policy documents.

Regulatory convergence is forcing teams toward a single resilience model. DORA and NIS2 differ in scope, but they point to the same operating expectation: continuous visibility, accountability, and recovery readiness. That convergence should push identity teams, risk teams, and security operations toward shared control mapping. Practitioners who align these controls once will reduce both compliance friction and incident ambiguity.

Named concept: compliance-grade identity evidence. This is the ability to produce access, approval, and session records that stand up to regulatory scrutiny during and after an incident. It is becoming a core requirement for regulated organisations because resilience claims are only credible when the identity trail is complete. Practitioners should design identity telemetry for auditability, not just security monitoring.

What this signals

DORA and NIS2 are pushing regulated organisations toward evidence-based control design, where identity telemetry, supplier oversight, and incident logs must all support the same audit narrative. That shifts IAM and PAM from support functions to core resilience enablers.

Compliance-grade identity evidence: if access, approvals, and emergency privileges cannot be reconstructed quickly, the organisation will struggle to defend its regulatory posture after an incident. This is especially true where third-party identities touch regulated services.

Regulated programmes should expect converging requirements around continuous visibility and response proof, so the most durable control strategy is to unify access governance with incident reporting and recovery testing.

For practitioners

• Build a DORA and NIS2 control map Map incident reporting, resilience testing, supplier oversight, and access governance to one evidence model so compliance teams are not reconciling disconnected records during an audit.
• Review privileged third-party access Identify all external administrators, service accounts, and delegated access paths that can affect regulated services, then tie each one to an owner, approval path, and offboarding trigger. Pair this with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle control patterns.
• Rehearse regulatory incident reporting Run tabletop exercises that force teams to produce the evidence regulators expect, including who approved access, when the alert fired, and how containment decisions were documented. Use the Ultimate Guide to NHIs , Why NHI Security Matters Now as background on why access governance is now a board-level risk.
• Test supplier continuity assumptions Validate whether a provider outage or compromise would break reporting, containment, or recovery obligations for services covered by DORA or NIS2. Include revocation steps for external credentials and emergency access paths in the exercise.

Key takeaways

• DORA and NIS2 turn resilience, reporting, and supplier oversight into regulated control requirements, not optional security improvements.
• Third-party access and privileged identity governance are central to proving compliance because they shape both incident scope and audit evidence.
• Organisations that cannot produce identity-level evidence quickly will struggle to meet the accountability expectations built into both frameworks.

Key terms

• Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.
• Third-party risk management: Third-party risk management is the process of identifying, assessing, monitoring, and reducing risk introduced by external vendors and service providers. In identity terms, it governs who outside the organisation can reach systems or data, how that access is approved, and when it must be removed.
• Incident Reporting: The process of detecting, triaging, documenting, and notifying the right stakeholders about a security event. Under DORA and NIS2, reporting becomes a governed capability that depends on accurate logs, clear ownership, and rehearsed decision paths rather than ad hoc communication.
• Privileged Access: Privileged access is any elevated entitlement that can change systems, data, or security settings. When privilege is excessive or poorly scoped, a single compromised identity can create outsized blast radius across environments.

What's in the full article

Expel's full article covers the operational detail this post intentionally leaves for the source:

• How Expel frames 24x7 monitoring and incident reporting for regulated environments
• The provider-side contractual supplement approach for organisations supporting DORA and NIS2 obligations
• The article's sector-by-sector examples for finance, energy, transport, healthcare, and public administration
• The practical compliance differences between an EU regulation and a directive in real programmes

👉 The full Expel article covers regulatory scope, penalties, and operational steps for finance and critical infrastructure teams.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity discipline to broader security and compliance programmes.