Organisations should prioritise the framework that has direct legal precedence and the most immediate applicability to their business model. For financial firms, DORA generally comes first because it is a regulation and takes precedence over NIS2. Teams should then map how local transposition changes obligations, so compliance work is sequenced against the correct legal authority and not against a generic European timeline.
Why NIS2 may not be the first EU resilience obligation to tackle
NIS2 is often treated as the default European cyber-resilience baseline, but organisations should sequence work by legal precedence, sector-specific obligations, and the business lines actually in scope. For many financial entities, DORA will dominate the compliance roadmap because it is the more specific instrument. That sequencing question matters most where teams have limited regulatory, control, and audit capacity.
How to decide which EU requirement takes precedence
The practical test is not which rule is newer or more visible, but which rule most directly governs the entity, activity, or service. If the organisation is a financial firm, the operational resilience and ICT risk requirements under EU Digital Operational Resilience Act (DORA) typically drive the first wave of remediation. NIS2 then becomes part of the broader mapping exercise, especially where local transposition expands or narrows obligations.
That same logic applies to other EU instruments that can overlap with resilience, incident reporting, supplier assurance, or governance. Organisations should identify the highest-precedence legal duty, then cascade the supporting control work into a single plan rather than running parallel compliance tracks that duplicate testing, evidence collection, and policy updates.
What organisations should map before they set the compliance sequence
Before prioritising one regime over another, teams should map three things: which legal regime directly applies, which legal entity and services are in scope, and whether national implementation has created additional requirements. This is particularly important for groups operating across multiple EU jurisdictions, where the same service may be captured differently depending on local transposition and sector supervision.
For cyber-resilience obligations, the relevant question is usually whether the rule is the primary regulator of the entity type or a general horizontal obligation that fills gaps around it. NIS2 is broad and important, but it should not be used as a generic compliance calendar when a sector-specific rule already governs the same operational area.
Risk and Threat Considerations
Compliance sequencing creates real exposure when teams spend time on the wrong legal driver and leave the actual supervisory requirement under-implemented. The main risk is not abstract non-compliance, but missed control coverage, inconsistent evidence, and avoidable duplication that slows remediation in the systems regulators will actually inspect.
Failure mechanism: Organisations apply a one-size-fits-all EU compliance programme, then discover that the more specific sector rule, local transposition, or supervisory expectation had different scope, deadlines, or control emphasis. That can leave high-priority ICT, incident, or third-party obligations under-addressed while teams document the wrong framework.
Impact: The result can be regulatory breach, weak audit readiness, delayed control uplift, and misallocated security effort. In practice, that often means the control gap is not lack of activity, but activity aimed at the wrong authoritative requirement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while DORA, NIS2 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Digital Operational Resilience Act | Directly governs financial entities' ICT risk and resilience obligations. |
| Recommendation — Use DORA as the primary sequencing anchor for regulated financial services. | ||
| NIS2 | NIS2 Directive | Sets broader EU cyber-risk duties that may apply alongside sector rules. |
| Recommendation — Map NIS2 obligations after confirming local transposition and sector precedence. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Supports determining which legal obligations take priority in compliance planning. |
| A.5.36 — Compliance with policies, rules and standards for information security | Supports maintaining evidence that chosen controls satisfy applicable requirements. | |
| Recommendation — Document the applicable legal hierarchy before building your control roadmap. Track evidence against the specific rule set that actually applies to the entity. | ||
| NIST CSF 2.0 | GV.OC-03 — Legal and regulatory requirements are understood and managed | Matches the need to identify the authoritative regulatory driver before sequencing work. |
| GV.SC-01 — Cybersecurity supply chain risk management strategy is established, communicated, and implemented | Relevant where DORA and NIS2 sequencing depends on third-party and ICT supply-chain duties. | |
| Recommendation — Identify the governing legal obligation before prioritising remediation tasks. Align third-party control work to the regime that imposes the stronger obligation. | ||
Practitioner Guidance
What to prioritise: Start with the regime that has direct legal precedence for the entity and service, then map NIS2 only where it adds obligations not already covered by the sector-specific rule. For financial organisations, treat DORA as the sequencing anchor and use NIS2 as an overlay where it still applies.
What to verify: Confirm the exact legal entity, regulated activity, and jurisdictional transposition before committing workstreams. If the answer depends on “the EU generally,” the scope is probably too loose for compliant sequencing.
Practitioner takeaway: The right order is usually the most specific enforceable obligation first, then the broader resilience regime, because compliance maturity depends more on legal applicability than on which framework is most familiar.
Related resources from NHI Mgmt Group
- When should organisations prioritise compliance work over other security initiatives?
- When should organisations prioritise NIST CSF work over other compliance frameworks?
- When should organisations prioritise Quebec Law 25 compliance work over other privacy initiatives?
- Should organisations prioritise external exposure or internal credential governance first?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
