Notifications
Clear all
Topic starter
20/08/2026 5:48 pm
TL;DR: DORA and NIS2 are now active across EU financial and critical infrastructure sectors, and Expel’s analysis shows that incident reporting, third-party oversight, and resilience testing are now governance obligations rather than optional hygiene. The practical challenge is not understanding the rules, but proving operational readiness before regulators test it.
NHIMG editorial — based on content published by Expel: DORA and NIS2 compliance guidance for regulated organisations
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
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
👉 Read Expel's analysis of DORA and NIS2 compliance obligations →
DORA and NIS2 compliance gaps teams are still underestimating?
Explore further
20/08/2026 6:28 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: DORA and NIS2 raise the bar for cyber resilience and reporting
