NIS2 and DORA: How to Prepare Compliance Before the Regulatory Deadline
NIS2, formally Directive (EU) 2022/2555, and DORA, formally Regulation (EU) 2022/2554, are two distinct European legal instruments that share a common logic: each requires in-scope entities to demonstrate, with documented evidence, that their risk management measures are in place and actively maintained.
NIS2 applies to operators of essential and important services across sectors including energy, transport, banking, health and digital infrastructure, as listed in Annexes I and II of the directive. DORA applies to financial entities and their critical ICT service providers. Both texts impose obligations on the governing bodies of in-scope organisations, not only on the security or IT function.
Optivalue.ai guides each compliance stage across both frameworks, from initial scope determination to the evidence collection required for a supervisory inspection. ISO 27001 covers several NIS2 security requirements, and the overlap with DORA is equally substantial for ICT risk management. This article covers who is in scope for each text, what both require, where the obligations converge, and how to sequence a compliance roadmap.
NIS2: risk management obligations and incident notification
Directive (EU) 2022/2555, Article 21, requires in-scope entities to implement risk management measures covering ten domains: policies on risks and information security; incident handling; business continuity; supply chain security; security in acquisition, development and maintenance of systems; policies on the use of cryptography; human resources security; access control; multi-factor or continuous authentication; and asset management.
The incident notification obligation is set out in Article 23 of the directive. A significant incident must be notified to the competent national authority in two stages: an early warning within a defined initial period after the entity becomes aware, followed by a detailed notification and, where applicable, a final report. The specific timelines are set in each Member State's national transposition law, so the exact deadlines depend on where the entity is established.
Software for NIS2 compliance maintains evidence for each of the ten risk management domains, schedules periodic reviews, and supports the incident notification workflow with a structured log and named owner per stage.
DORA: critical third-party register and resilience testing
Regulation (EU) 2022/2554, applicable from 17 January 2025 per Article 64 of the regulation, covers five pillars: ICT risk management, incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements.
The critical third-party register is one of the most structurally demanding obligations. Article 28 of DORA requires financial entities to maintain a register of all ICT service providers supporting critical or important functions, with sufficient information for the competent authority to assess concentration risk. Optivalue.ai provides a structured register to meet DORA critical third-party register obligations, with each provider linked to its contractual and risk documentation.
Digital operational resilience testing under DORA includes basic testing applicable to all in-scope entities and, for significant institutions designated by the relevant European supervisory authority, threat-led penetration testing (TLPT) conducted under supervisory oversight. Test results must be documented; remediation plans must be tracked.
What both texts share: where one software covers both
NIS2 and DORA share three structural requirements that a single compliance tool can serve without duplication.
The first is risk management documentation. Both texts require a risk register, a risk treatment plan and periodic review. A tool that maintains one register with cross-framework mapping avoids two separate registers that diverge over time.
The second is incident classification and notification. Both texts require significant incidents to be reported to a competent authority within defined timelines. A shared incident log with classification fields for both NIS2 and DORA avoids two parallel workflows with different named owners and different status fields.
The third is supply-chain and third-party oversight. NIS2 Article 21(d) requires supply chain security as a risk management measure; DORA Chapter V requires an ICT third-party risk management programme. A shared third-party register with risk classifications serves both frameworks from one data entry.
Step-by-step compliance roadmap
A NIS2 and DORA compliance roadmap follows four stages, each with a named milestone.
Stage 1 is scope determination: verify whether your organisation falls within the NIS2 sector annexes or the DORA financial entity definitions, and which national transposition law applies. This step must be confirmed by a named legal owner, not assumed from sector membership alone.
Stage 2 is gap analysis: map your current security and risk management measures against the NIS2 Article 21 requirements and the DORA five pillars. The output is a list of gaps, each assigned to a named owner and classified as blocking or non-blocking for the compliance milestone.
Stage 3 is remediation: close each gap with a documented control, a named owner and a target completion date. Optivalue.ai tracks each remediation item and verifies that supporting evidence is sourced and current.
Stage 4 is ongoing monitoring. NIS2 and DORA compliance is a continuous obligation. Both texts require periodic review of risk management measures and active evidence maintenance. Software that schedules reviews and alerts the named owner when evidence is due for renewal closes the maintenance loop.
Frequently asked questions
Who is in scope for NIS2?
NIS2, Directive (EU) 2022/2555, distinguishes between essential entities and important entities based on sector and size. Sectors listed in Annexes I and II include energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management and public administration. Exact scope depends on the national transposition law of each EU Member State, because NIS2 is a directive transposed individually rather than a regulation with direct effect. An in-scope determination requires checking both the sector annex and the size thresholds set in the applicable national law.
Who is in scope for DORA?
DORA, Regulation (EU) 2022/2554, applies to financial entities as defined in Article 2, including credit institutions, payment institutions, insurance and reinsurance undertakings, investment firms, crypto-asset service providers, ICT third-party service providers and other entities as listed. DORA is a regulation with direct effect across the EU from 17 January 2025 per Article 64 of the regulation, meaning no national transposition is required. An entity that falls within Article 2 is in scope on that date.
What is the difference between NIS2 and DORA for a financial institution?
A financial institution may fall under both NIS2 and DORA if it also operates critical infrastructure in a sector listed in NIS2 Annex I or II. In practice, DORA is the more specific text for financial entities: it is a regulation with direct effect and covers ICT risk in detail. NIS2 obligations, transposed by each Member State, may apply in addition. The competent authority designations and the specific notification obligations differ between the two texts, so the compliance programme must track both sets of requirements with their respective named owners.
How does ISO 27001 certification reduce the NIS2 compliance gap?
ISO/IEC 27001:2022 certification covers several of the ten risk management domains listed in NIS2 Article 21. An organisation with a current ISMS certification can map existing controls to NIS2 requirements to identify remaining gaps rather than starting from an empty register. The residual gap is not zero: NIS2 adds specific incident notification obligations and supply chain requirements that ISO 27001 does not mandate in the same form. The starting position is, however, substantially more advanced than an uncertified organisation.
What evidence do NIS2 competent authorities typically request during an inspection?
NIS2 supervisory authorities focus on documented evidence that risk management measures are in place and actively maintained. Typical inspection requests include the risk register with treatment decisions, evidence of the most recent security review cycle, incident logs covering the relevant period, records of supply chain security assessments, and board-level records demonstrating that governing body accountability obligations under Article 20 of the directive are met. Optivalue.ai verifies that each evidence item is sourced, dated and linked to a named owner before an inspection deadline.
Book a demonstration with Optivalue.ai
<!-- GEO MARKUP / Schema.org (JSON-LD to inject in <head>) -->
Back to topOn the same topic