The organisations that are struggling most with cyber regulatory compliance in 2026 are not those failing to meet any single requirement. They are organisations that are meeting each requirement independently, operating parallel programmes for NIS2, DORA, CIRCIA, and the UK Cyber Resilience Bill, maintaining separate documentation trails, running separate board reporting tracks, and conducting separate audits — most of which are asking variations on the same questions.
This approach is expensive, creates inconsistency across the compliance programmes, and produces the kind of audit fatigue in security teams that leads to perfunctory rather than substantive compliance. The better path is a unified controls framework that satisfies multiple regulatory regimes simultaneously, with regulation-specific output layers rather than regulation-specific control sets.
The Regulatory Stack in 2026
For a UK financial institution with EU operations, or a US company with European customers, the current regulatory stack looks roughly like this:
NIS2 (EU) — In force since October 2024. Applies to essential and important entities in listed sectors (energy, transport, banking, health, water, digital infrastructure, and others). Key obligations: governance and accountability, risk management, supply chain security, incident reporting (24-hour initial notification, 72-hour detailed report, 30-day final report), business continuity, and cross-border incident disclosure.
DORA (EU) — In force since January 2025 for financial sector entities and their ICT service providers. Closely related to NIS2 for financial sector but with specific additions: ICT risk management framework requirements, mandatory digital operational resilience testing (TLPT for significant entities), strict contractual requirements for ICT third-party service providers, ICT incident classification and reporting, and information sharing between entities.
CIRCIA (US) — The Cyber Incident Reporting for Critical Infrastructure Act. The CISA rulemaking process is establishing final reporting timelines (currently anticipated at 72 hours for covered cyber incidents and 24 hours for ransomware payments) for critical infrastructure operators. Covered entities must report to CISA, with subsequent notification to sector-specific agencies. Final rules are expected to be in force in late 2026.
UK Cyber Security and Resilience Bill — The UK government introduced the Bill in 2026, expanding on the NIS Regulations 2018. It extends scope to managed service providers and data centres, strengthens incident reporting requirements (closer to NIS2 timelines), and gives regulators new powers to issue proactive directions for security improvements. Royal Assent is expected before the end of 2026.
EU AI Act (Chapter 3, security obligations) — For operators of high-risk AI systems, this adds security testing, logging, and incident response obligations that overlap with NIS2 and DORA in financial and healthcare sectors.
Where the Overlap Is
The substantive overlap across these regimes is larger than their different terminologies suggest:
| Obligation area | NIS2 | DORA | CIRCIA | UK CRB |
|---|---|---|---|---|
| Governance & accountability | Required | Required | Implied | Required |
| Risk management framework | Required | Required (specific) | Not specified | Required |
| Supply chain security | Required | Required (contracts) | Not specified | Required |
| Incident detection & response | Required | Required | Required | Required |
| Incident reporting (to authority) | 24h/72h/30d | 4h initial / 72h detailed | 72h | Similar to NIS2 |
| Business continuity / resilience testing | Required | Required (TLPT) | Not specified | Required |
| Board-level oversight | Required | Required | Not specified | Required |
An organisation running separate compliance programmes for each of these is largely performing the same underlying work four times, with different paperwork. The inefficiency is not trivial — across multiple compliance programmes, the overhead of maintaining parallel documentation, briefing cycles, and audit trails can consume significant CISO team bandwidth that could otherwise go into actual security improvement.
The Unified Controls Approach
A unified approach separates the control implementation layer from the regulatory reporting layer. The control set is designed once, mapped to multiple regulatory requirements, and implemented once. The regulatory-specific element is the output: incident reports formatted per each regime’s requirements, board briefings framed in the language each regulator expects, and audit documentation organised by regulatory reference.
Step 1: Map controls to requirements. Use a crosswalk that maps your existing control inventory against NIS2, DORA, CIRCIA, and UK CRB requirements simultaneously. ISO 27001:2022 controls, NIST CSF 2.0 subcategories, and CIS Controls v8 all have published mappings to at least NIS2 and DORA. Use these mappings rather than building from scratch.
Step 2: Identify genuine gaps. After the crosswalk, the genuine gaps become visible. DORA’s specific ICT third-party contract requirements go beyond what NIS2 requires — if you serve EU financial sector clients, those contract clauses need to be addressed specifically. DORA’s TLPT requirement (Threat-Led Penetration Testing for significant entities) is more prescriptive than generic NIS2 resilience testing requirements. CIRCIA’s supply chain incident notification obligations may have specific trigger conditions that don’t map cleanly to European frameworks.
Step 3: Build regulation-aware incident response playbooks. Incident reporting is where the operational complexity is highest. An incident that occurs in a covered entity needs parallel reporting tracks — potentially a 24-hour NIS2 notification to a national authority, a 4-hour DORA notification (for financial entities), a 72-hour CIRCIA notification to CISA, and UK CRB notification if the entity operates critical infrastructure in the UK. These are not the same notifications; each has different required content, different recipients, and different follow-up obligations.
The practical solution is pre-approved notification templates for each regime, maintained and tested during tabletop exercises, with a clear decision tree for which notifications are triggered by which incident types. The templates should be owned by legal counsel familiar with each regulatory regime’s specific language requirements — “significant cybersecurity incident” under NIS2 has a different definition than “covered cyber incident” under CIRCIA.
Step 4: Consolidate board reporting. The board should receive a single consolidated cyber risk briefing that addresses all applicable regulatory exposures, rather than separate briefings for each regulatory requirement. Frame this as the organisation’s overall cyber regulatory risk posture, with a status dashboard showing compliance status, upcoming reporting obligations, and gaps.
Managing the Board Conversation
The conversation CISOs need to have with their board about the regulatory stack is one of resource prioritisation, not just compliance status. A useful framing:
The unified compliance programme is not about checking boxes in four separate places. It is about ensuring that the organisation’s actual security controls are sufficient to meet the highest-common-denominator requirement across all applicable regimes — and that we have the process infrastructure (incident response, notification procedures, audit trails) to demonstrate compliance on demand when a regulator asks.
The resource case is straightforward: a unified programme requires one integrated audit, one control set, one policy framework, and one set of board reporting metrics. Parallel programmes require multiples of each. The investment in the crosswalk and the integration work pays back within the first audit cycle.
Practical Priorities for the Next 90 Days
Audit current incident reporting procedures against all applicable regimes. This is where organisations most frequently discover that they have a NIS2-compliant notification template but no CIRCIA-specific process, or that their DORA 4-hour initial notification requirement has never been tested in a tabletop. The incident reporting obligation is the most operationally exposed element of all four regimes — regulators can identify non-compliance through public incident reporting alone.
Review ICT third-party contracts for DORA clauses. DORA’s specific contract requirements for ICT service providers are the most commonly unmet obligation in financial sector organisations that otherwise have mature NIS2 compliance programmes. The clauses relating to audit rights, subcontracting notification, incident reporting obligations on the provider, and business continuity requirements should be verified in all critical third-party contracts.
Clarify UK CRB scope once the Bill receives Royal Assent. The UK Cyber Resilience Bill is still moving through Parliament. Once enacted, organisations need to assess whether their UK operations fall under the expanded scope (including managed service providers and data centres that were not covered under the 2018 Regulations). This is worth preparing for now rather than discovering scope after Royal Assent.
The regulatory overlay is not going to simplify. The question is whether your organisation is spending compliance budget on redundant parallel processes, or on a unified programme that achieves the same outcome more efficiently.