Your Escalation Matrix Names a Regulator That No Longer Supervises You

The National Cybersecurity Authority has issued a cybersecurity baseline aimed at private sector entities that are not classified as critical national infrastructure, referenced NCNICC-1:2025. Counsel writing on it describes two categories — broadly, 250 or more full-time employees or annual revenue above SAR 200 million for the larger tier, and six to 249 employees or revenue between SAR 3 million and SAR 200 million for the smaller one — and three components, with a fuller control set for the larger tier and a reduced one for the smaller. I am not going to print a control count. The number in the draft that went out for consultation and the number in the summaries are not the same number, and the only count that will matter to you is the one in whichever text you are actually being assessed against. The component that matters most to this subject is the third: third-party, outsourcing and hosted-environment obligations, which is continuity written in procurement language.

Here is the part being misreported everywhere. The controls set no compliance deadline. That is not a gap you should fill with anxiety, and it is certainly not a reason to buy a program. It changes what a serious response looks like: rather than working backwards from a date, you work forwards from a gap assessment, and you sequence the fixes by what would actually hurt on a bad day. I will also be straight about my own position — I have read counsel's summaries of these controls rather than the control text itself, and the summaries do not agree with each other on the naming of the third component, on the reference code, or on when it was issued. So I use the thresholds and the structure, and I do not quote article numbers I have not read.

What no baseline has ever done is pick your numbers. Recovery time objective and recovery point objective are usually set by whoever wrote the plan, which means IT, which means nobody who will carry the loss has ever agreed to them. They are not technical parameters. Recovery time is how long the business will trade without the system. Recovery point is how much completed work the business will re-enter by hand. Only the person who owns the revenue can answer either, and until they have answered out loud in a room with a record, the numbers in your plan belong to nobody.

The forcing mechanism already exists, and I have rarely seen a technology team reach for it. Under the Saudi Central Bank's Business Continuity Management Framework, the business impact analysis is where recovery time objectives, recovery point objectives and maximum acceptable outage are determined, and the business continuity committee endorses them — not the IT department. Ultimate responsibility for the program sits with the board of directors or a delegated executive member, and the committee is specified to carry the risk, operations, information and information security officers. Read that as an organization chart and you miss what it is. Read it as a signature block and you have your lever: the number is not yours to pick, it is yours to price. So bring options, not a recommendation. Four hours, one hour and fifteen minutes are three architectures with three invoices, and the gap between them is usually a standby environment somebody funds monthly whether or not it is ever used. The rooms I have put that trade-off in front of — a board of directors, an executive committee — turned at the same moment in both, when the number acquired a monthly price.

Circular No. 202200000249, dated 18 May 2022, extended the Saudi Central Bank's Business Continuity Management Framework to insurance and reinsurance companies. It required a gap assessment against the framework, a business plan submitted within ninety working days, quarterly progress reports, and full compliance within a year. Insurers have been operating under that framework ever since. Now open the communication clause inside it and read who you are told to call: all disruptive incidents classified Medium or High go to SAMA "Banking IT Risk Supervision", immediately, in those words.

Read the quoted name again, because one word in it carries the whole point. Banking. An insurance company was brought under a banking framework by circular, and the text of that framework instructs it to notify a banking IT risk supervision desk on its worst operating day. In May 2022 that was coherent, because one institution supervised both sides. The framework itself is older than the circular, and its own scope line covers the banking sector, the finance sector, payment systems and payment service providers, and credit bureaus. Insurers were added to it; they were never written into it. Supervision of insurance has since moved to the Insurance Authority, so the desk named in the text no longer holds the competency the text hands it, while the rules issued under the previous arrangement remain in force until something supersedes them. So the duty is live, the wording is unchanged, and the door it points at is not the one that supervises you.

The clause did not become invalid. It became misaddressed.

There are two recipient strings here rather than one, and they are not the same string. The Business Continuity Management Framework names "Banking IT Risk Supervision" for disruptive incidents. The Cyber Security Framework, at 3.3.15, names "SAMA IT Risk Supervision" for medium and high classified security incidents, and attaches a no-objection requirement before you communicate publicly. Any incident that is both a cyber event and a disruptive one — which is most of what is worth reporting — engages both clauses at the same time, with two named desks and two different triggers. If your escalation matrix carries a single row reading notify SAMA, it has already collapsed two obligations into one line that nobody has read against the source text since the day it was typed.

I went looking for the instruction that re-points either clause for insurers. The Insurance Authority's published regulations, as at August 2026, carry no business continuity, cybersecurity, outsourcing or incident-reporting instrument at all; the list is insurance products, coverage templates and market rules. I have not found a published instruction that re-addresses those clauses, and I will not pretend I have. What I would do, and what I insist on, is putting the question to the supervisor in writing during a quiet week, taking an answer in a form you can file, and pasting it into the runbook beside the clause it corrects. Meeting that ambiguity for the first time during an incident is expensive, because the framework's own word for the deadline is "immediately".

Then run the same check across everything else, because insurance is where I happen to see this and not where it stops. An addressee is the one part of a control that goes stale without anything failing to announce it: no alert fires, no test breaks, and an audit of the control finds nothing wrong with it, because the control still works and only the name on it is wrong. Open the notification section of your own continuity plan, and the escalation matrix inside your ITSM tool, and read the institution named in each against the one that supervises you this month. Do that inside the exercise rather than as a documentation task, because the exercise is the only place where somebody actually tries to use the name and discovers it is wrong while nothing is at stake.

Every continuity plan I have read stops at the first vendor. It names the core platform, the hosting provider, perhaps the connectivity supplier, and there the map ends. The financial-sector framework asks for considerably more. The business impact analysis is to determine internal and external interdependencies and to identify potential internal and external threats including single points of failure. The continuity plan is to ensure that, for all critical activities determined by that analysis, key service providers have a continuity plan in place and that those plans are tested at least yearly. Vendor and supplier capability to hold service levels during a disruptive incident is to be assessed at least once a year. I have never been handed that work completed, because asking a supplier to produce evidence of a tested plan is an uncomfortable procurement conversation, and an uncomfortable conversation is easily replaced with a clause.

The dependencies that actually hurt are the ones you never contracted for at all. The certificate that expires in the middle of an incident. The identity provider, which is frequently not a dependency of the outage but the outage itself. The domain registrar. The license server your platform phones before it will start. The message gateway carrying the one-time password that your own recovery procedure needs somebody to receive. The sector platform you integrate with daily and hold no commercial agreement against, where all you hold is a support address and a polite tone. There is no service level to invoke against any of them and no credit worth collecting. What you have instead is a decision to make in advance: what does this business do, manually, for the hours that dependency is unavailable, and who has been trained to do it.

The new private-sector baseline's third component is about exactly this surface. The obligations counsel describe are contractual: cybersecurity terms embedded in third-party contracts, incident communication procedures, data classification, separation of environments, and return of data in a usable format on termination of the service. That last one is an exit clause, and an exit clause is a recovery control wearing a lawyer's suit. Your recovery from a failed or withdrawn supplier is bounded entirely by whether you can get your data back in a form you can actually load into something else. The Cloud Cybersecurity Controls point the same way and are worth reading if you are a customer rather than a provider: CCC-2:2024 is an extension to the Essential Cybersecurity Controls and binds cloud service tenants, not only cloud service providers. And the principle underneath all of it, stated plainly in counsel's guidance on financial-sector outsourcing, is that accountability cannot be transferred to a vendor. You can outsource the work. You cannot outsource the answer you give afterwards.

The fourth party is the part that is genuinely hard. Your provider's provider. What my suppliers' suppliers have rehearsed is not something I can evidence, because I have not asked them in writing and received an answer I could file. Say that plainly in the governance forum rather than coloring the cell green, because a green cell you cannot defend costs more than an amber one you can. The lever you do control is narrower than people assume: the Essential Cybersecurity Controls require agreements with third parties whose impairment may affect the entity's data or services to include, as a minimum, communication procedures in the event of a cybersecurity incident. Most contracts I have opened have a service level and no such procedure. A service level tells you what you are owed afterwards. A communication procedure tells you which name answers which number. Only one of those is any use while the event is running.

The most common exercise I see is a rehearsal of the answer rather than a test of the question. The scenario is circulated a week in advance. The participants are the people who wrote the plan. The system chosen is the one that was recently invested in. The report says all objectives were met, and it is filed. That is a photograph of the plan, not a test of it. The purpose of an exercise is to produce findings. If yours produced none, either it was designed not to, or your organization is the first in the history of the sector to have got everything right on paper.

The regulator's own deadlines assume findings exist. The Business Continuity Management Framework requires continuity plan testing at least once a year with clearly defined objectives and planned scenarios, with cyber security scenarios expressly to be taken into consideration, and with activation and involvement of the crisis management team; once the individual tests are complete, an integrated test across all critical services and processes is one you are told to consider conducting. Disaster recovery testing runs at least once a year, combined with the continuity test. Then the two deadlines that give the game away: test results are shared with the supervisor within four weeks of the test, and an action plan for the improvements identified is provided within two months of submitting those results. An improvement action plan is not an optional annex. The framework is drafted on the assumption that a real test generates a list, and a submission of nothing is itself a finding about you.

So design for discovery. Do not circulate the scenario. Remove one named person from the room without warning and see whether the plan survives their absence; it is the cheapest thing you can put into an exercise and it costs nothing but nerve. Make the failure the thing your plan quietly depends on: the identity platform, the connectivity, the vendor whose support desk turns out to keep business hours in a different time zone. Give one participant the explicit job of arguing that recovery has not actually been achieved. And score the exercise on the number and quality of findings rather than on completion, because the moment completion becomes the metric you have taught the whole organization to design an easy test.

Withdraw the person and you usually reach the contact register before you reach the gap. Continuity documents get written with names because names are how the author thinks, and the framework asks for contact details of the crisis management team including third parties. That list ages out without anything in the system failing to indicate it. Write roles into the procedure, hold the names in one register that offboarding actually touches, and test the register by dialing it rather than by reading it: a reassigned number looks identical on the page and rings in a stranger's pocket.

Findings are also assurance. The framework requires the program to be reviewed and audited periodically by a qualified independent internal or external party, with the gaps and a roadmap reported to senior management and the committee. A program that has never produced a gap is not reassuring. It is unaudited.

Backup dashboards are green because backup jobs completed, and a completed job is evidence that a file was written and nothing more than that. The Essential Cybersecurity Controls are careful with the wording here: what is required is periodic testing for the effectiveness of backup recovery, alongside the ability to perform quick recovery of data and systems after cybersecurity incidents. Effectiveness, not existence.

A restore is end to end when the application starts, authenticates against an identity service that also had to be recovered, reconnects to its integrations, reconciles, and someone from the business rather than from IT signs that the data is correct to the recovery point that was agreed. Anything short of that is a file copy with good intentions attached. The step that gets dropped is the last one, and it is the only step in the sequence that cannot be performed by the team whose work is being graded.

Then time it. A restore that has never been timed cannot support a recovery time objective, and the conditions you time it under are part of the measurement: the weekend, the reduced team, the change freeze somebody has to break, the approval somebody has to go and find. Report the measured figure beside the committed one, in the same paper, every year. If the two do not match you have either an engineering problem or a pricing conversation, and both are cheaper to hold in March than during the event.

The number you gave the committee without measuring it was a wish with a decimal point.

Know what will be asked before you are asked it. Under the Cyber Security Framework, a medium or high classified security incident is reported to the supervisor immediately upon occurrence and identification, relevant evidence and logs must be protected, sufficient certified forensic capacity must be available, and the post-incident report carries a specific list: incident title, classification, the time the incident occurred and the time it was detected, technical details and affected information assets, root-cause analysis, corrective activities performed and planned, and the impact including estimated costs. The Business Continuity Management Framework says the same about disruptive incidents classified medium or high — immediately, with a report once normal operations resume.

Now read that list again and ask which items can honestly be reconstructed. Root cause, yes, afterwards. Corrective actions, afterwards. But the time of occurrence held separately from the time of detection is not reconstructable three days later out of a group chat, and the interval between those two timestamps is precisely the number that tells a supervisor how good your detection actually is. Neither is the decision record: who authorized the failover, at what time, on what information, and who was informed. And where personal data is in scope, the Personal Data Protection Law's implementing regulations give you seventy-two hours from becoming aware to notify the Saudi Data and Artificial Intelligence Authority where the breach may harm the personal data or the data subjects, with the notification carrying a description of the incident, the categories and estimated number of affected individuals, an assessment of the consequences and the measures taken to contain it. An estimated number of affected individuals, inside seventy-two hours, is a data-model question. You answer it before the incident or you do not answer it at all.

The operational fix is unglamorous, and it is a role rather than a tool. Somebody on the crisis team writes things down while other people fix things, into one timestamped record, and that person carries no technical task. Occurrence time and detection time are captured as two separate fields from the first minute, not merged into "when we noticed". Every decision gets an owner and a timestamp. The seventy-two hour clock starts at awareness rather than at containment, and someone who is not inside the recovery has to be watching it. Rehearse the evidence trail in the exercise exactly the way you rehearse the failover. The worst possible moment to discover that your incident record is an untimestamped chat thread is while a supervisor is waiting for it.

Communication arrives late in most of the plans I have read: scheduled after recovery, and handed to the marketing team. In a regulated financial company it is concurrent, it is constrained, and it carries an approval dependency sitting in the middle of your worst hour. The Business Continuity Management Framework requires coordination with the supervisor when communicating with the media in the event of an incident. The Cyber Security Framework goes further and requires a no objection from the supervisor before public communication. Your holding statement is therefore a regulated act rather than a marketing artifact. If your communications plan does not model the supervisor as an approver with a turnaround time, that plan will manufacture a compliance problem while you are still trying to solve an availability problem.

The framework also places communications inside the crisis team rather than downstream of it. The crisis management team is to include representatives of the critical products, services, functions and processes, explicitly naming the communications department, and the crisis management plan is to carry a communication plan including a media response plan addressing internal and external stakeholders. That placement is the whole point and it is the part organizations quietly skip. A communications function that learns about the incident from the second internal update is a function that will fill the gap with a guess, and the guess becomes the public record.

What holds up operationally is dull and specific. Holding statements drafted and legally cleared in advance, so drafting is never the bottleneck. Commitments to a cadence instead of to a resolution time, because "the next update is at eleven" is a promise you can keep and "back within the hour" is one you cannot. One named voice, and a standing rule that nobody else speaks. A contact-center script released at the same moment as the first internal notification, since the people answering customer calls are the public face of the incident whether or not anyone planned for that. And where personal data is involved, notification to affected individuals without undue delay, which is a legal standard rather than a communications judgment. Deciding to say nothing yet is still a decision. It gets an owner and a timestamp in the incident record, like every other one.