Why there is so much talk about NIS2 and DORA
Two European texts, two similar objectives: to reduce the impact of digital incidents and make organizations controllable.
NIS2 targets “essential” and “important” sectors (energy, health, transport, water, digital, government, etc.).
DORA targets the financial sector and its critical ICT providers.
In both cases: governance at management level, risk management, incident preparedness, available evidence… and deadlines/notification format for authorities.
NIS2 in brief (what the authority expects from you)
- Who is affected? “Essential” entities with more than 50 employees or more than €10 million in turnover.
- What you need to demonstrate:
- Governance with explicit management responsibility.
- Risk management (including the supply chain).
- Continuity & response: procedures, exercises, evidence.
- Incident notification within specified timeframes (early warning, notification within 72 hours, final report).
- What changes on a daily basis: tracked decisions, formalized supplier requirements, messages ready to report an incident, possible checks by the authority (heavy fines for non-compliance).
DORA at a glance (finance specific)
-
Who is affected? Banks, insurance companies, investment firms, related entities, and certain critical ICT service providers.
-
What needs to be demonstrated:
- ICT governance supported by senior management.
- Incident management with harmonized reporting to financial authorities.
- ICT third parties: register, clauses, monitoring, exit strategy.
- Regular resilience testing (up to advanced scenarios).
- Continuity & crisis communication.
-
What changes on a daily basis: defined reporting formats and channels, contractually regulated supplier relationships, testing and exercise schedule.
NIS2 vs. DORA: same foundations, different emphases
| Theme | NIS2 | DORA |
|---|---|---|
| Nature | “Critical/important sectors” directive | Finance regulation (applicable as is) |
| Management | Explicit role, traceable decisions | Same, + responsibility for ICT governance |
| Incidents | Early warning, notification, final report | Harmonized reporting + short deadlines possible |
| Third parties | Supplier/supply chain requirements | ICT service providers: strong contractualization & exit |
| Tests | Regular exercises (IR/BCP) | Structured resilience tests, including advanced ones |
In practice: a structured ISMS (such as ISO 27001) covers most of the basics; deadlines/reporting and the third-party layer specific to NIS2/DORA are added.
How to prepare intelligently (without multiplying projects)
Status & scope
Check if/what applies, map the activities, entities, and suppliers concerned, identify the competent authority (and its formats).
Governance & evidence
Appoint those responsible, document how decisions are made, keep records, and schedule periodic reviews.
Incidents & communication
Write the user manual: detection, qualification, who alerts whom, message templates, delivery channels, deadlines, training.
Third parties & contracts
Segment suppliers by criticality, define minimum requirements, include clauses (notification, audits, security, exit plan), and establish regular monitoring.
Continuity & testing
Realistic Plan B, exercises, resilience testing (more extensive in DORA), logging of results and decisions made.
Conclusion
NIS2 and DORA require proof rather than promises: transparent governance, incidents managed and reported in a timely manner, third parties under control, continuity tested. With an ISO 27001-type foundation and a focus on deadlines/reporting/third parties, you’ll be ready… even on the day of the audit.
Want a mock NIS2/DORA audit and a prioritized roadmap? Let’s talk.
