The Cyber Academy take
Operational resilience is the ability of an organisation to deliver critical services through disruption, then recover. Three frameworks govern it in Europe: ISO 22301 (BCMS standard, the operational layer), NIS 2 (Article 21 business-continuity obligation for in-scope entities), DORA (Articles 11-12 for financial entities, plus dedicated testing). A single programme can satisfy all three; running them as separate workstreams duplicates work and creates inconsistencies.
TL;DR
- 1ISO 22301 is the operational backbone: BIA, recovery objectives, BCP, runbooks, tabletop exercises, BCMS under management review.
- 2NIS 2 layers in incident reporting (24-hour early warning, 72-hour notification, one-month report) and supply-chain continuity.
- 3DORA layers in financial-entity-specific testing (threat-led penetration testing for significant entities every three years), the ICT third-party register, and ESA-level supervision for critical providers.
- 4Lead Operational Resilience Manager (PECB credential) is built specifically to integrate the three.
- 5Map once, audit thrice: a single 22301-aligned BCMS with NIS 2 and DORA control mappings satisfies all three audits.
Why one programme, not three
The instinct inside most organisations is to treat ISO 22301, NIS 2 and DORA as three separate compliance projects, often owned by three different teams: business continuity, security operations, and a financial-regulation or risk function. That is the most expensive way to do it. You end up with three business impact analyses that disagree on which services are critical, three sets of recovery objectives that nobody reconciles, and three exercise calendars that exhaust the same people. Auditors notice the seams immediately.
The frameworks are not competitors. ISO 22301 gives you the management system: the business impact analysis (BIA), the recovery time and recovery point objectives, the continuity and recovery plans, the exercises, and the management review loop. NIS 2 and DORA do not replace any of that. They add obligations on top of it, mostly around incident reporting, supply-chain assurance, and (for DORA) a specific testing regime. If your BCMS is built well, the regulatory layers bolt onto it rather than duplicating it.
Build the backbone first. The ISO 22301 Lead Implementer course is the one that teaches you to stand up the management system that everything else hangs off; if you only need to understand the structure and vocabulary, start with the ISO 22301 Foundation course.
What each framework actually adds
The honest way to read the three is as one operational core plus two regulatory overlays. ISO 22301 is the core because it is the only one of the three that prescribes how to build and maintain the continuity capability itself. NIS 2 and DORA assume that capability exists and then impose duties on top: who you must tell when something breaks, how fast, and how you must prove the capability works.
| Framework | What it adds on top of the core | Who it applies to |
|---|---|---|
| ISO 22301 | The business continuity management system itself: BIA, RTO/RPO, continuity and recovery plans, runbooks, exercises, management review. The operational backbone the other two assume. | Any organisation, voluntarily. Certifiable but not legally mandated. |
| NIS 2 | Incident reporting timelines (early warning, notification, final report), business-continuity and crisis-management duties, supply-chain security, and management accountability. | Essential and important entities in named sectors across the EU (energy, transport, health, digital infrastructure, public administration and more). |
| DORA | Financial-sector ICT resilience: a digital operational resilience testing programme including threat-led penetration testing for significant entities, the ICT third-party register, and direct oversight of critical ICT providers. | Financial entities in the EU (banks, insurers, investment firms, crypto-asset providers) and their critical ICT third parties. |
Read the table top to bottom and the design becomes obvious. You implement ISO 22301 once. NIS 2 and DORA then tell you what evidence the regulator wants to see from that single system, and DORA adds a testing discipline that goes beyond the tabletop exercises ISO 22301 expects.
How it works in operations
In day-to-day terms, the integration lives in three artefacts, and getting them right is most of the job. The first is a single, authoritative service catalogue and BIA. Decide once which services are critical, what their tolerance for disruption is, and what they depend on. Every framework then reads from that one source. If your NIS 2 scoping and your DORA critical-or-important-function list disagree with your ISO 22301 BIA, you have already lost the audit argument before it starts.
The second is a unified incident pipeline. ISO 22301 wants you to detect, respond, and invoke continuity plans. NIS 2 and DORA want you to report, on the clock, to a competent authority. Build one detection-and-triage process whose output feeds both the internal continuity response and the regulatory notification workflow. The reporting clock starts at awareness, so the bottleneck is rarely the continuity plan; it is the decision of whether an event is reportable and the speed of drafting the early notification. Pre-drafted notification templates and a clear escalation owner are worth more than any tool here.
The third artefact is the test and exercise programme, and this is where DORA pushes hardest. ISO 22301 exercises validate the plans; DORA requires a documented testing programme and, for significant entities, threat-led penetration testing on a multi-year cycle. The DORA Lead Manager course covers the testing regime and the ICT third-party register in the depth the regulation demands, while the Lead Operational Resilience Manager course is the one built specifically to run the three frameworks as a single programme.
The decision: certify, align, or both
A common question is whether you need ISO 22301 certification to satisfy NIS 2 or DORA. You do not. Neither regulation mandates the certificate. But the standard is the most widely recognised blueprint for the capability both regulations assume, so most teams align to ISO 22301 even when they choose not to certify. The decision splits cleanly: align to ISO 22301 to get a coherent, defensible BCMS; certify on top only if a customer, a tender, or a board wants third-party assurance of it.
If you do pursue the certificate, understand the audit perspective from both sides of the table. Implementers build the system; auditors test whether it holds.
To run the certification audit (internal or as a certification body), the ISO 22301 Lead Auditor course teaches the audit methodology and how to assess a BCMS against the standard, which is also the fastest way to learn what evidence your own programme will be judged on.
Where programmes go wrong
The recurring failures are predictable, and almost all of them come from treating the frameworks as separate rather than layered.
- Three disagreeing BIAs. Continuity, security and finance each scope criticality differently. Fix it by mandating one BIA that all three functions sign.
- Plans that pass the exercise but fail the event. Tabletop exercises that walk through a slide deck prove nothing. Test invocation, not narration: actually fail over, actually restore from backup, actually reach the people on the call tree.
- Confusing the continuity, recovery and incident-response functions. Business continuity keeps the service running, disaster recovery restores the technology, and incident response contains the cause. They are distinct disciplines that must hand off cleanly.
- Missing the reporting clock. The continuity plan worked but nobody filed the early warning in time. The regulatory notification is a separate, time-boxed obligation and needs its own owner.
- Treating crisis management as an afterthought. When an incident escalates, decision-making, not technical recovery, is the failure point.
Two of those failures have dedicated remedies. The Lead Disaster Recovery Manager course separates technology recovery from business continuity so the two stop being conflated, and the Certified Lead Crisis Manager course builds the command, communication and decision structure that holds when an incident becomes a crisis.
The audit-room reality
What an assessor for any of the three frameworks is really probing is whether your resilience is real or paper. They will ask for the BIA and then ask who approved it and when it was last reviewed. They will ask for your last exercise and then ask what failed and what you changed as a result, because an exercise with no findings is a red flag, not a clean bill of health. For DORA entities, they will ask for the testing programme and the third-party register and expect both to be current, not reconstructed the week before.
The teams that pass calmly are the ones running a single programme: one BIA, one incident pipeline feeding both internal response and regulatory reporting, one exercise calendar that actually breaks things, and one control mapping that lets them answer three regulators from the same evidence base. Build the ISO 22301 backbone properly, layer NIS 2 and DORA obligations onto it deliberately, and the phrase that should describe your audits is map once, audit thrice.
Frequently asked questions
01Do I need ISO 22301 certification under NIS 2 or DORA?
No. Neither NIS 2 nor DORA mandate ISO 22301 certification. Both require that the organisation operates business-continuity and resilience capabilities that achieve specific outcomes (recover within agreed timeframes, report incidents within deadlines, test the plans). An ISO 22301-compliant BCMS demonstrates those capabilities cleanly to a supervisor.
In practice, financial entities and operators of vital importance often pursue ISO 22301 certification because the audit evidence required by NIS 2 and DORA matches the certification evidence almost one-to-one.
02What is the relationship between BCP, DR, and incident response?
Three overlapping disciplines. Business Continuity Plans (BCPs) cover how the business keeps operating through a disruption, staffing, alternative sites, workarounds, communication. Disaster Recovery (DR) covers the IT-specific restoration of systems and data. Incident Response (IR) covers the detection-to-recovery cycle of security incidents.
A mature programme runs them as one. The same playbook walks from incident detection (IR) to system recovery (DR) to business operation continuation (BCP). Different teams may execute different phases, but the plan is integrated.
03What is threat-led penetration testing under DORA?
TLPT is the regulator-supervised red-team exercise required for significant financial entities under DORA, every three years at minimum. Built on TIBER-EU. Intelligence-driven (separate threat intelligence team produces the attacker profile), targets critical or important functions, supervised by the national authority.
TLPT is multi-month, multi-hundred-thousand-euro work. It is the most rigorous resilience test a financial CISO will face, and the one that exposes the SOC, the detection rules and the incident-response chain for what they really are.
04How do I structure a single resilience programme?
Start with the BCMS (ISO 22301 backbone): scope, BIA, recovery objectives, plans, tests, management review. Layer in NIS 2 incident-reporting procedures and the supply-chain continuity obligations from Article 21. Layer in the DORA-specific testing schedule, ICT third-party register and incident classification for financial entities.
Map the controls in a single mapping document showing which clause of which framework each control satisfies. Auditors recognise the mapping and stop asking duplicate questions.
