Cyber Incident Management: SAMA, NCA & PDPL Notification

When a cyber incident strikes a Saudi-regulated organisation, the first sixty minutes are not primarily a technical problem. They are a governance problem. The CSIRT is triaging. The CISO is on the phone. Someone is trying to decide whether this is a P1 or a P2. And somewhere in that chaos, three separate regulatory notification clocks are running — one for SAMA, one for NCA, and one for SDAIA under the Personal Data Protection Law — each with a different deadline, a different channel, and a different set of consequences for missing it.

Most Saudi organisations discover this patchwork at the worst possible moment: during a real incident. The SAMA notification window has closed before anyone decided who was responsible for sending it. The PDPL 72-hour clock started at discovery, not at breach confirmation, and it is now hour 68. The NCA expects a technical summary the organisation has not drafted.

This is an incident management problem, and it is one of the most consequential gaps in the Saudi GRC landscape. This post is the practitioner's guide to building the capability before you need it.

The regulatory patchwork: three obligations, one incident

Saudi Arabia has three primary regulatory bodies with mandatory cyber incident notification requirements, and they do not always fire at the same time or in the same direction.

SAMA supervises every bank, insurer, finance company, payment service provider, money exchanger and credit bureau in the Kingdom. Under the SAMA Cyber Security Framework, member organisations are required to notify SAMA of significant cyber incidents within defined timeframes. Under the SAMA BCM Framework, parallel notification applies when an incident triggers business continuity implications. These are not the same obligation — a ransomware event that encrypts production systems simultaneously triggers both a CSF notification (cyber incident) and a BCM notification (continuity event), with the BCM Framework imposing its own timelines.

NCA supervises government entities and critical national infrastructure (CNI) operators under the NCA Essential Cybersecurity Controls. When a cyber incident affects national security, government systems or CNI, the NCA expects notification through its reporting platform. Private-sector organisations that are dual-regulated — banks that also operate critical payment infrastructure, for example — may face simultaneous obligations to both SAMA and NCA.

SDAIA enforces the Personal Data Protection Law. Any organisation that processes personal data of Saudi residents — regardless of sector, size or whether they are supervised by SAMA or NCA — must notify SDAIA within 72 hours of discovering a breach that is likely to harm the rights or interests of individuals. This is a data protection obligation, not a cybersecurity one, and it runs independently of whether the incident has been classified under SAMA CSF or NCA ECC.

The practical consequence: a bank that suffers a ransomware attack that encrypts customer records is simultaneously running three notification processes — SAMA (cyber), SAMA (BCM), and SDAIA (PDPL) — plus internal escalation to the board, crisis committee and communications team, plus third-party supplier notifications, plus customer notification if SDAIA determines individual impact is high. Organisations that have not pre-defined the decision trees and responsibilities for each of these streams before an incident discover them the hard way.

Incident classification: the foundation of every decision downstream

The most consequential decision in the first fifteen minutes of an incident is the severity classification. Every downstream decision — who gets called, when regulators are notified, how much resource is allocated, when the board is briefed — flows from it. Teams that classify poorly (too low to avoid escalation, too high and unable to sustain the response) produce worse outcomes than teams with fewer technical resources but a consistent classification discipline.

A Saudi-aligned incident severity framework maps to four tiers. The tier is assigned by the Incident Commander or CSIRT Lead at the point of initial triage, confirmed within thirty minutes, and can only be downgraded — never upgraded — without a fresh command decision.

Three classification pitfalls appear consistently in Saudi post-incident reviews.

Classifying by symptom, not impact. A ransomware detection alert is not automatically P1. If the malware was contained in a sandboxed segment with no production access, it may be P2 or P3. Conversely, a single compromised credential can be P1 if that credential has privileged access to the payment switch. Impact drives classification, not the name of the threat.

Under-classifying to avoid escalation. This is the most dangerous failure mode. When the team classifies a breach as P3 to avoid waking the CISO or triggering the board process, the regulatory notification window runs without anyone authorised to sign off the notification. SAMA and NCA both look at incident timelines in post-event reviews, and an incident classified as P3 that turns out to have been P1 will attract harder scrutiny than one that was correctly escalated.

Failing to re-classify upward. Incidents evolve. An initial P3 that begins as a phishing investigation can escalate to P1 when forensics reveals lateral movement to the core banking environment. The IRP must define the re-classification trigger explicitly and give the Incident Commander authority to escalate without waiting for a management decision.

Notification timelines: the windows that close whether you are ready or not

The critical practical fact about regulatory notification in Saudi Arabia is that the clocks start at detection, not confirmation. The 72-hour PDPL window begins from the moment the organisation becomes aware of the breach, not the moment a forensics team confirms it. The SAMA window begins from the moment the incident is assessed as significant, not the moment all facts are known.

This is deliberate. Regulators are not asking for complete information on first notification — they are asking for timely notification with what is known so far, followed by updates as the picture develops.

SAMA notification in practice. SAMA CSF control 3.3.15.5 requires significant cyber incidents to be reported to SAMA immediately. The public framework does not codify a specific hour-bound deadline — practical timeframes (commonly 2 hours for critical, 24 hours for high severity) are set in SAMA supervisory letters issued to each member organisation, and the exact deadline applicable to your bank is in your member correspondence. The notification does not need to be a complete incident report. It needs to state: what happened (as understood at the time), which systems and data are affected, what containment actions have been taken, and who the SAMA contact within the organisation is. A follow-up update is expected as the picture develops, and a final incident closure report within an agreed period after the incident is resolved. The SAMA CSF self-assessment includes incident notification in the maturity scoring — organisations that cannot show a notification log with timestamps will be rated accordingly.

NCA notification in practice. NCA ECC control 2-14 (Cybersecurity Incidents and Threats Management) requires entities to report cybersecurity incidents to the NCA via the national incident reporting service. Specific hour-bound timeframes are issued through sector-specific NCA guidance rather than the public ECC document. For incidents with national security or CNI implications, mature practice mirrors SAMA's "immediate for critical, without delay for high" cadence. The NCA expects technical detail alongside the impact narrative — attack vector, indicators of compromise (IOCs), affected systems, and containment status. Government entities that delay notification because the technical picture is still developing will receive a harder inspection review than those that notify promptly with partial information and provide updates.

SDAIA / PDPL notification in practice. The 72-hour window is the hardest deadline to hit because PDPL breach notification is often the last thing on the mind of a team managing an active ransomware event. The obligation is triggered by the discovery of a breach of personal data — not by the resolution of the incident. If customer records were accessed at T+0 and the incident is still being managed at T+48, the SDAIA notification is due in 24 hours whether or not the incident is contained. The notification must include: the nature of the breach, the categories and approximate number of individuals affected, the likely consequences, and the measures taken or proposed. If notification to individual data subjects is required (because the risk to their rights is high), SDAIA must be informed of that plan simultaneously.

The incident response runbook: what it must contain

The majority of Saudi organisations that fail regulatory notification windows do not fail because they lacked technical capability. They fail because the notification decision — who decides, at what threshold, through what channel — was never codified in a runbook that the people managing the incident can actually reach during a crisis.

A Saudi-compliant incident response runbook has seven mandatory components.

Component 1 — Severity classification criteria. Explicit definitions for P1 through P4, with worked examples relevant to the organisation's business (payment system outage, core banking system breach, customer data exposure, insider theft). The classification decision must be reachable in under five minutes.

Component 2 — Notification decision tree. A literal flowchart that answers: Is this a SAMA-notifiable incident? Is this an NCA-notifiable incident? Is personal data involved? If yes — who sends the notification, to which channel, within what window? The tree must be laminated and available offline, because ransomware attacks frequently take down the intranet.

Component 3 — Regulator contact list. The name, title, email and phone number for the designated SAMA contact, the NCA incident reporting channel, and the SDAIA portal URL. Updated quarterly. Available on paper, not just in the email client.

Component 4 — Pre-drafted notification templates. Partially pre-completed notification messages for each regulator, with blank fields for incident-specific information. Pre-drafting the boilerplate under calm conditions means that during a P1 at 03:00, the notification can be completed in minutes rather than written from scratch while also managing an active incident.

Component 5 — Internal escalation paths. Who is called first (SOC/CSIRT), then who (CISO/CRO), then who (CEO/Board Chair), at each severity tier, with mobile numbers current and tested. The list needs a deputy for every role.

Component 6 — Evidence preservation protocol. Forensic evidence collected in the first hours of an incident can be crucial for regulator investigations and insurance claims. The runbook should specify: what to preserve (log files, memory images, system snapshots), who is authorised to collect it, and where it is stored.

Component 7 — Post-incident reporting obligations. The timeline for the final incident report to each regulator, the format expected, and who within the organisation is responsible for drafting and submitting it.

The six-phase IRP lifecycle

Saudi cyber incidents that are managed well follow a structured lifecycle. The phases are not linear — contain and eradicate can overlap; recover may restart if a new threat is discovered — but the structure provides decision checkpoints that prevent teams from skipping steps under pressure.

Two cross-phase observations from Saudi post-incident reviews.

The evidence chain breaks at phase transitions. The most common forensic failure in Saudi incidents is not the absence of logs — it is logs that exist but cannot be attributed because the chain of custody was not maintained across the handoff from Detect to Contain. Each phase handoff should include a written evidence summary.

The regulatory notification sits in Recover, not in Contain. Teams under pressure to contain an active ransomware attack often defer the regulatory notification to "when we have the full picture." By the time the full picture is available, the SAMA window has closed. Notification belongs in the timeline at a defined elapsed time, regardless of whether containment is complete.

The escalation ladder: who is notified when

The most common failure mode in Saudi incident management is not the absence of a process — it is the process existing on paper but not being followed because roles were ambiguous, contacts were out of date, or the severity threshold for escalation was not agreed in advance. The escalation ladder eliminates ambiguity by specifying who is notified at each elapsed time point, for each severity tier.

The escalation ladder must be tested. A tabletop exercise that runs the team through a P1 ransomware scenario — including the moment where someone has to actually pick up the phone and say "I am calling to inform you that we have a significant cyber incident" — reveals gaps that no amount of policy review finds. Saudi teams that run realistic escalation tests (surprise timing, degraded communications, leadership unavailability) produce materially better outcomes in real events than those that do not.

PDPL breach notification: the 72-hour discipline

The PDPL breach notification obligation under SDAIA is the most operationally demanding of the three regulatory streams for a simple reason: it involves the most unknowns at the time the clock starts. When ransomware encrypts production systems, the organisation may not know for several hours whether customer personal data was accessed or merely encrypted in place. But the PDPL clock runs from discovery of the breach, not confirmation of the scope of personal data impact.

The practical response is a two-stage harm assessment that runs in parallel with technical containment.

Stage 1 — Data exposure screening (T+0 to T+4 hours). While the technical team is triaging, the Privacy Officer or DPO runs an immediate assessment: which systems were affected, what categories of personal data they contain, and the likely exposure scenario. This does not require forensic confirmation — it requires knowing what data lives where, which is information the organisation's Records of Processing Activity (RoPA) should provide.

Stage 2 — Impact and notification decision (T+4 to T+24 hours). Based on the initial screening, the DPO makes a documented decision: is this a PDPL-notifiable breach? What is the likely harm to individuals? Is individual notification required? This decision, and the reasoning, must be recorded regardless of the outcome. If the decision is that notification is not required, the documentation of that decision is itself the compliance evidence.

SDAIA's enforcement posture — 48 formal decisions in the first year of enforcement, with fines up to SAR 5 million — has been applied most aggressively where organisations failed to notify at all, or notified materially late without a documented justification for the delay. Organisations that notify promptly with partial information and submit complete information subsequently have received more proportionate treatment than those that waited for certainty.

The 72-hour clock is not a deadline to have all the answers. It is a deadline to have a documented decision, a notification on record, and a plan. SDAIA is far more interested in whether you were timely than whether your first notification was complete.

When incident becomes continuity event: the BCM intersection

Not every cyber incident triggers the BCM Framework. A P3 phishing investigation does not. A P1 ransomware event that takes down production systems and payment services does — and at that point, two parallel response tracks are running simultaneously: the CSIRT-led incident response (forensics, containment, eradication) and the BCM-led continuity response (workarounds, customer communications, regulator notification under the BCM Framework).

The SAMA BCM Framework imposes its own notification obligations for significant continuity events, separate from the CSF cyber incident notification. These run on similar timelines to the CSF obligation for critical events, but they involve different organisational functions — the BCM team and the business continuity coordinator, not just the CSIRT — and different SAMA contacts.

The organisations that handle cyber-BCM incidents best have a single incident log that both teams work from, with clear separation of roles: the CSIRT owns the technical response track; the BCM team owns the continuity response track; the Incident Commander coordinates between them and owns the regulatory notification across both streams. Without this co-ordination structure, the two teams work from separate logs and produce contradictory evidence — a failure that is particularly visible at inspection.

For banks and financial institutions, the intersection with the SAMA Outsourcing Regulations adds a third layer: if a critical outsourced service is involved in the incident (cloud provider compromise, managed SOC failure, core banking vendor breach), the bank's BCM obligations extend to that third party's recovery capability, and the bank is still on the hook for the regulatory notification even if the root cause is in the supplier's environment.

Evidence the regulator actually asks for

Saudi GRC teams preparing for inspection often focus on policy documentation and framework coverage. The evidence SAMA and NCA inspectors ask for in the incident management domain is different — it is operational evidence that the process worked when it was needed.

The five most commonly requested artefacts are:

1. The incident register. A log of every incident in the last twelve to twenty-four months, classified by severity, with timestamps showing when each was detected, escalated, notified to regulators (if applicable), contained, resolved and closed. Gaps in the register, or a register that shows only P4 incidents (suggesting P1–P3 events are going unrecorded), are red flags.

2. The notification log. For every P1 and P2 incident, a record of the regulatory notification — when it was sent, to which regulator, through which channel, by whom, and what it said. Inspectors calculate elapsed time from the incident timestamp to the notification timestamp. Missing or late notifications that cannot be explained are findings.

3. The most recent tabletop exercise report. The scenario, the participants, the issues identified, the lessons learned, and — critically — evidence that the lessons were acted upon before the next exercise.

4. Post-incident review reports. For any real P1 or P2 incident in the period, a written post-incident review with root cause analysis, contributing factors, control failures, and the improvement actions taken. An incident that had no post-incident review is a process gap.

5. The runbook and its version history. Inspectors want to see that the runbook is a living document, updated after incidents and exercises, not a policy written in 2022 and untouched since. The version history and the reviewer list tell them this story quickly.

Building the programme: practical sequencing

For organisations that are starting from scratch or recognise their current programme is not inspection-ready, the sequencing that works in practice is as follows.

First: establish the CSIRT structure. Name the Incident Commander role, assign the CSIRT members, define the on-call rota, and test that the on-call contacts are reachable. This takes two weeks and is the foundation everything else depends on.

Second: write the classification criteria and get them approved. The P1–P4 definitions, worked examples, and the authority matrix (who can classify at each tier) should be approved by the CISO and the Risk Committee. This takes another two weeks and is the decision-making foundation.

Third: write the notification decision tree. Map every regulatory obligation to a decision point: trigger, threshold, channel, deadline, owner. This is a one-page document that lives in the physical runbook. It requires the Legal and Regulatory team to confirm the current notification channels and contacts for each regulator.

Fourth: run the first tabletop. A four-hour exercise using a realistic scenario (ransomware in the payments environment, customer data confirmed breached at hour two). Record the issues. Fix them.

Fifth: connect the programme to the GRC platform. Move the incident log, the regulatory notification tracker, the action register and the post-incident review process into the same platform that manages the SAMA CSF control library and the risk register. The connection between a control failure, the incident it enabled, and the risk register entry that should have flagged it is the evidence chain inspectors are increasingly asking to see end-to-end.

How GRC Vantage supports incident management and notification compliance

GRC Vantage's incident management module provides a connected incident register pre-mapped to SAMA CSF, NCA ECC and PDPL obligations. The severity classification workflow builds in the P1–P4 taxonomy, the escalation ladder fires automatically against the configured notification tree, and the regulatory notification log records timestamps, channels and submission evidence against each incident for inspection purposes.

The PDPL 72-hour notification clock runs from the moment the incident is classified as involving personal data, with escalating alerts to the assigned DPO as deadlines approach. Post-incident reviews are linked to the incident record and feed directly into the risk register, closing the loop between operational response and strategic risk management.

The platform is deployed inside Saudi Arabia to satisfy data residency requirements under PDPL and SAMA Outsourcing Regulations, and the Riyadh and Dammam delivery teams provide the notification templates and decision trees pre-populated for the Saudi regulatory landscape.

For the full picture of SAMA's framework obligations — including CSF, BCM, IT Governance and Outsourcing — read our SAMA frameworks pillar guide. For the NCA framework family including the OT-specific OTCC and the Data Cybersecurity Controls that intersect with PDPL, read our NCA frameworks pillar guide. And if you are preparing for an inspection or building your incident management programme from scratch, book a session with our team and we will walk through how Saudi organisations use GRC Vantage to run notification-ready incident management from day one.