NCA ECC Business Continuity Requirements: The Resilience Domain in Practice

Most business continuity programmes in Saudi Arabia were built to answer a business question: what happens when we lose a building, a supplier, a system. The National Cybersecurity Authority's Essential Cybersecurity Controls (ECC) ask a narrower and sharper one: what happens when the thing that breaks you is an attacker.

That difference is why organisations with a mature ISO 22301 programme still fail ECC resilience reviews. The artefacts exist. They just answer the wrong scenario.

This guide covers what the Cybersecurity Resilience domain expects in practice, who is in scope, the evidence that satisfies a review, and how to run one continuity programme that serves both your business and the NCA rather than maintaining two. For control-level text, always work from the NCA's own published document — this is the operational companion, not a substitute.

What the ECC is, briefly

The Essential Cybersecurity Controls are the NCA's baseline cybersecurity framework for the Kingdom, first published in 2018 and updated periodically since. The structure is five domains covering roughly 114 controls:

Domain 3 is where a continuity programme lives. Domains 2 and 5 are not BCM territory in any honest reading, and a continuity team that claims coverage there will lose credibility on the rest of its evidence.

Who has to comply

Three populations, with very different pressure levels:

• Saudi government bodies — ministries, agencies and public-sector entities. Mandatory, with NCA supervisory review.
• Critical National Infrastructure operators — energy, telecommunications, transport, healthcare, water, and financial services where the entity also meets CNI criteria. Mandatory.
• Everyone else — private-sector organisations that adopt ECC voluntarily because it has become the recognised KSA cybersecurity benchmark, and because customers, insurers and prime contractors increasingly ask for it.

That third group is growing fastest, and it is the group most likely to be caught out. Voluntary adoption still means a real review against real controls.

Why a good BCP still fails an ECC review

The Cybersecurity Resilience domain is not asking whether you have continuity plans. It is asking whether your continuity capability survives a cyber event. Four gaps show up repeatedly.

1. The backup assumption

Conventional BCM treats backups as the recovery mechanism of last resort and stops there. A ransomware scenario inverts that: the backups are the target. A reviewer will ask whether your backups are immutable or offline, whether restoration has been tested from a known-clean copy, and what your recovery position is if the most recent backups are encrypted.

If your BIA declares a four-hour RTO for a critical service, and your only recovery path is a backup set an attacker could reach with the same credentials that compromised production, that RTO is fiction.

2. Recovery into a compromised environment

Traditional DR fails over to a warm site and declares success. Cyber recovery cannot, because failing over may simply carry the compromise with you. Sequencing matters: containment, forensic preservation, clean-environment rebuild, then restore — and each of those steps consumes time your RTO has to absorb.

3. Crisis communication when the channel is the casualty

Your crisis-communication plan probably assumes email and the corporate directory work. In a domain-compromise scenario they may be unavailable, untrusted, or actively monitored by the attacker. ECC resilience expects an out-of-band path: an offline contact roster, a pre-agreed alternative channel, and a decision on when to stop using primary systems for incident coordination.

4. Continuity and incident response as separate programmes

In most organisations the security team owns incident response and a separate BCM function owns continuity, and the two plans reference each other vaguely. ECC treats them as one continuum, because for a cyber event they are. The reviewer's version of this question is: who declares, at what threshold, and how does declaration hand control between the two teams?

The evidence that satisfies the resilience domain

Reviewers work from artefacts, not intentions. A defensible ECC resilience position rests on these:

1. 1

   A BIA that includes cyber scenarios

   Recovery objectives derived for cyber-driven loss, not only physical loss. Same critical services, different failure mode — and often a materially different RTO once clean-rebuild time is included.

2. 2

   Continuity and DR plans with cyber-specific paths

   Plans that name the ransomware path, the clean-recovery sequence and the isolated-restore procedure explicitly, rather than a generic "invoke DR" step.

3. 3

   Tested restoration from clean backup

   Evidence of an actual restoration test — date, scope, who ran it, what the measured recovery time was, and what failed. An untested backup is an assumption.

4. 4

   A cyber-scenario exercise with findings

   At least one exercise per cycle built on a cyber scenario, with participants, injects, observations and — critically — actions raised and closed. Exercises with no findings read as theatre.

5. 5

   An incident-response-to-continuity handoff

   A documented declaration threshold and escalation path connecting security incident handling to continuity invocation, with named roles on both sides.

6. 6

   A closed-loop improvement register

   Findings from exercises, incidents and reviews tracked to closure with owners and dates. This is where governance-domain expectations and the resilience domain meet.

The pattern across all six: dated, owned, and closed. An artefact with no author, no date and no follow-through is treated as a draft regardless of how good its contents are.

Running one programme, not two

The efficient path is to operate a single BCMS to ISO 22301 structure and map its outputs to ECC resilience expectations, rather than building a parallel cyber-continuity programme. The BIA, the plans, the exercise cycle and the improvement register are the same artefacts — ECC just demands that cyber scenarios are represented in each of them, and that the evidence is retrievable on request.

Two companion pieces go deeper on the mechanics:

• NCA ECC vs ISO 22301 — where the two frameworks align, where ECC asks for more, and how to reuse one evidence set across both.
• NCA ECC vs SAMA BCM — for financial institutions that may answer to both the NCA and the Saudi Central Bank.

And when you are assembling the evidence pack itself, the ECC evidence checklist covers what to have ready and in what order.

Where BCM tooling fits

A platform earns its place here by making evidence retrievable rather than reconstructable. The realistic division of labour: BCM tooling covers the resilience domain end-to-end — BIA, plans, exercises, crisis handling, improvement actions — and integrates with the security stack that owns the Defence and ICS domains.

The NCA ECC resilience controls page maps each resilience-domain expectation to the module that satisfies it, and is explicit about the domains a BCM platform does not and should not claim to cover.

Frequently asked questions