A common mistake is splitting ownership between security, compliance, procurement, and operational resilience teams without a shared control map. That leads to duplicated assessments, inconsistent incident thresholds, and gaps in third-party oversight. Teams also underestimate the effort needed for testing and audit evidence. A unified framework with clear control ownership is usually more efficient and easier to defend during review.
Why Separate NIS 2 and DORA Programmes Usually Fail the Same Way
Organisations often start from the legal texts and end up with two parallel governance tracks, but NIS 2 and dora both depend on the same control primitives: asset and dependency visibility, access control, incident handling, resilience testing, third-party oversight, and audit evidence. Treating them as separate programmes usually creates duplicated policy work without improving the underlying control posture.
The more important question is not which regulation “wins”, but whether the organisation can express one control set in a way that satisfies both obligations. If the answer is no, the failure is usually in operating model design, not in the regulations themselves.
Where the split-programme model breaks down operationally
The first problem is ownership drift. Security, compliance, procurement, resilience, and vendor-management teams often each hold a fragment of the same control, so nobody owns the end-to-end outcome. That produces inconsistent definitions for what must be assessed, what evidence is acceptable, and when a supplier or system becomes a reportable issue.
The second problem is duplication without consistency. Teams run separate control inventories, separate questionnaires, separate incident playbooks, and separate testing cycles, even when the evidence needed is largely the same. That wastes effort and also makes it easier for control gaps to hide between programme boundaries.
The third problem is that third-party oversight gets split between procurement and security in a way that weakens accountability. Both NIS 2 and DORA push organisations toward clearer supplier risk governance, but a split programme can leave no single team responsible for mapping critical vendors, validating contract clauses, or tracking remediation through to closure.
For a practitioner, the key failure mode is not “too much compliance work”, it is inconsistent control interpretation. When one programme defines an incident one way and another uses a different threshold, the organisation may under-report, over-escalate, or miss the moment when a resilience issue should be treated as a regulatory event.
What a unified control map changes
A unified control map turns two regulatory programmes into one operating model with multiple reporting lenses. That means common control domains for incident reporting, resilience testing, third-party risk, access governance, logging, and evidence retention, with regulatory-specific overlays only where the obligations truly differ.
It also lets organisations reuse the same testing artefacts for both regimes. A single control owner can evidence how incidents are triaged, how critical services are recovered, how suppliers are reviewed, and how management oversight is recorded, then present that evidence through the NIS 2 or DORA lens as needed.
This is where authoritative control references help. NIS 2 and DORA both reward the same fundamentals described in EU NIS2 Directive and the EU Digital Operational Resilience Act (DORA), especially around supply chain security, incident reporting, and operational resilience testing. For control design, broad governance can be anchored in NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0, which help teams express one control structure across multiple regulatory obligations.
Why auditability and evidence become the real cost centre
The biggest underestimation is not policy drafting, it is evidence production. A dual programme usually means two versions of the same control narrative, two sets of reviewers, and repeated requests for the same logs, tickets, test results, and supplier documents. That creates friction during audit and obscures whether the control is actually operating, or merely being documented twice.
Evidence also needs to be comparable across time. If incident thresholds, supplier review criteria, or resilience-test scope change from one programme to another, the organisation cannot easily show trend, maturity, or remediation progress. In practice, regulators and auditors care less about programme labels than about whether controls are repeatable, traceable, and owned.
For implementation, it is often better to centralise the evidence model and let reporting diverge at the last mile. That avoids rebuilding the same proof package for each regime and makes it easier to demonstrate that the control exists once, operates once, and satisfies multiple obligations.
Risk and Threat Considerations
Splitting NIS 2 and DORA into separate programmes increases the chance of blind spots, especially where suppliers, shared services, and incident escalation paths cross organisational boundaries. The risk is not just inefficiency, it is that a control failure can be missed because each programme assumes the other owns the issue.
Failure mechanism: fragmented ownership produces inconsistent thresholds, duplicated assessments, and weak third-party oversight, which allows the same control gap to be interpreted differently across teams and remain unresolved.
Impact: organisations can miss regulatory reporting triggers, fail to evidence resilience testing properly, or discover too late that a critical supplier or service dependency was never governed end to end.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 — Internal and External Context | NIS 2 and DORA need one shared operating model and control context. |
| GV.RM-01 — Risk Management Strategy | The question is about how to avoid split governance and duplicated risk treatment. | |
| GV.OV-01 — Oversight of the Cybersecurity Risk Management Strategy | Separate programmes fail when oversight is split across teams and evidence chains. | |
| Recommendation — Define one control context that both regulatory programmes map to. Set a single risk strategy that governs both NIS 2 and DORA controls. Assign one oversight model for control ownership and regulatory evidence. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Both regimes stress third-party oversight and supplier governance. |
| Recommendation — Centralise supplier governance and reuse it for both regulatory obligations. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | A shared control map must cover access governance consistently across programmes. |
| A.5.19 — Information security in supplier relationships | The split-programme problem often appears in third-party oversight and contracts. | |
| A.5.24 — Information security incident management planning and preparation | Both regimes depend on aligned incident definitions and escalation paths. | |
| Recommendation — Use one access-control baseline across both compliance tracks. Apply one supplier-risk process to all critical vendors and services. Standardise incident planning so reportable events are classified once. | ||
| SOC 2 (AICPA) | CC3.2 — Communication of internal control deficiencies | A unified evidence model needs clear ownership and escalation of control gaps. |
| Recommendation — Track control deficiencies in one register with one remediation owner. | ||
Practitioner Guidance
What to prioritise: build one control inventory first, then map each control to NIS 2 and DORA obligations rather than running two separate programme backlogs. The inventory should name a single owner for each control, a single evidence source, and a single escalation path.
What to verify: confirm that incident criteria, supplier criticality, testing scope, and evidence retention rules are identical wherever the underlying control is the same. If they differ, require a documented reason, not a historical accident.
Practitioner takeaway: the right operating model is not two compliance programmes with shared inputs, but one control architecture with two regulatory outputs.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they try to comply with DORA, NIS 2, and the EU AI Act at the same time?
- What do organisations get wrong when they try to manage tenant access and custom roles across multiple CIAM vendors?
- What do organisations get wrong when they try to manage shadow data after a migration or development copy is created?
- What do organisations get wrong when they try to manage financial controls with too few accountants?
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
