If you already run a certified ISO 22301 business continuity management system, you are most of the way to satisfying the NCA ECC resilience domain. The gap is narrower than vendors selling a separate "cyber resilience programme" would like you to believe — but it is real, and it is specific.
Here is what carries over, what doesn't, and how to structure the evidence once.
What the two are actually for
They are different kinds of document, which is why the comparison confuses people.
ISO 22301 is a management system standard. It specifies how to build, operate and continually improve a BCMS: context, leadership, planning, support, operation, evaluation, improvement. It is scenario-agnostic by design — the standard does not care whether the disruption is a flood, a strike or a ransomware event.
NCA ECC is a cybersecurity control framework. Continuity appears inside it as one domain among five, and its interest in continuity is entirely conditioned on cyber threat. It cares very much what the scenario is.
ISO 22301 tells you how to build a continuity capability. NCA ECC tells you what that capability must survive.
That framing predicts the whole mapping: ISO gives you the machinery, ECC constrains the scenarios the machinery must handle.
Where they align
Most of the programme, in practice:
| Capability | ISO 22301 | ECC resilience domain |
|---|---|---|
| Business impact analysis | Clause 8.2 | Expected as the basis for recovery objectives |
| Recovery objectives (RTO / RPO) | Clause 8.2 | Expected, with cyber scenarios represented |
| Continuity strategy and solutions | Clause 8.3 | Expected |
| Continuity plans and procedures | Clause 8.4 | Expected, with cyber-specific recovery paths |
| Exercising and testing | Clause 8.5 | Expected, with cyber scenarios |
| Performance evaluation | Clause 9 | Supports the governance domain |
| Management review | Clause 9.3 | Supports the governance domain |
| Corrective action / improvement | Clause 10 | Expected as a closed-loop register |
If those artefacts exist and are current, you are not starting from zero on ECC. You are re-scoping.
Where ECC asks for more
Four places, all of them scenario-driven rather than structural.
Cyber scenarios inside the BIA. ISO 22301 requires you to assess impact over time for prioritised activities. It does not require any particular disruption cause. ECC's interest means your BIA needs to reflect what recovery looks like when the cause is compromise — which usually lengthens the realistic RTO once containment and clean-rebuild time are counted.
Backup integrity as a continuity control. ISO 22301 treats backup and replication as continuity solutions under clause 8.3. ECC's cyber framing raises a question ISO does not force: what if the backups are themselves the target? Immutability, offline copies and tested restoration from a known-clean set become continuity evidence, not just IT hygiene.
Recovery-environment assurance. Failover under ISO 22301 is complete when the service is running at the alternate site. Under ECC framing it is complete when the service is running at a site you have reason to believe is clean. That inserts a verification step most DR runbooks do not have.
The incident-response handoff. ISO 22301 has incident response inside the BCMS. ECC has cybersecurity incident management as its own set of expectations adjacent to continuity. The junction between them — declaration thresholds, who owns the event at which stage — is where reviewers probe, and where most organisations have a documented gap.
Building the evidence once
The mistake is to treat ECC as a second programme. It isn't — it is an additional lens on the same artefacts. Practical sequence:
- 1
Keep ISO 22301 as the operating structure
The BCMS stays as-is. Do not fork it. Every ECC resilience expectation maps onto an artefact the BCMS already produces.
- 2
Add cyber scenarios to the existing BIA
Not a separate cyber BIA. The same critical services, assessed for a compromise-driven outage alongside the physical ones, with recovery objectives that account for containment and clean rebuild.
- 3
Extend plans rather than duplicating them
Add the ransomware and clean-recovery paths as named procedures inside existing continuity and DR plans. One plan set, more scenarios.
- 4
Put a cyber scenario into the exercise calendar
The existing ISO 22301 exercise programme absorbs this. Same lifecycle, same findings process, one scenario changed.
- 5
Document the declaration threshold
Write down where security incident handling hands off to continuity invocation, and who decides. This is usually the only genuinely new document.
- 6
Map the evidence, don't copy it
Maintain a mapping from ECC resilience expectations to the BCMS artefact that satisfies each. A mapping table beats a duplicated document set that drifts out of sync within a quarter.
Step six is the one that saves the most work over time. Duplicated evidence is not just extra effort at creation — it is a permanent reconciliation burden, and reviewers notice when two versions of the same artefact disagree.
If you're certifying to both
Sequencing matters if you're doing this from a standing start rather than retrofitting. Build the ISO 22301 BCMS first, with cyber scenarios included from the beginning rather than bolted on. A BCMS designed with compromise as a first-class scenario satisfies ECC resilience almost incidentally; one designed around physical disruption and later extended always shows the seam.
For the KSA-specific implementation mechanics, how to implement ISO 22301 in Saudi Arabia covers the local context. If a financial regulator is also in the picture, NCA ECC vs SAMA BCM covers the dual-supervision case.
The NCA ECC resilience controls page shows which resilience-domain expectations a BCM platform covers natively and which belong to your security stack.
Frequently asked questions
Does ISO 22301 certification satisfy NCA ECC?
Not automatically. It satisfies most of the structural expectations of the resilience domain, but ECC's cyber framing adds requirements around backup integrity, clean recovery and the incident-response handoff that a scenario-agnostic BCMS may not evidence. The gap is usually weeks of work, not a new programme.
Which should we do first?
ISO 22301, with cyber scenarios built in from the start. It gives you the management-system machinery that ECC resilience evidence depends on. Building ECC-shaped continuity artefacts without an underlying BCMS produces documents with no process to keep them current.
Do we need separate cyber and business continuity plans?
No, and separate plans tend to fail together — they drift apart and contradict each other under pressure. One plan set with cyber-specific recovery paths named inside it is easier to maintain and easier to evidence.