The first 72 hours after a personal data breach under the PDPL

The call comes in at 02:00 on a Thursday. A database that should not have been reachable from the public internet was, a researcher found it, and nobody in the room yet knows how long it was exposed or who else reached it. Somewhere in the next few minutes, before most of the people on the bridge realize it, a 72-hour clock starts running.

Saudi Arabia’s Personal Data Protection Law and its Implementing Regulations came into force on 14 September 2023, with a one-year grace period that ended on 14 September 2024, after which the Saudi Data and Artificial Intelligence Authority, SDAIA, expects full compliance (Clyde & Co; Latham & Watkins). One of the duties that comes with that is a tight breach-notification window, and the organizations that handle it well are the ones that decided who does what long before the 02:00 call.

The clock starts at “became aware”

The single most expensive misunderstanding is treating the deadline as 72 hours from the end of your investigation. Per published analyses of the Implementing Regulations, a controller must notify SDAIA within 72 hours of becoming aware of a personal data breach where it may cause harm to data subjects or their rights or interests (Clyde & Co). Awareness is the trigger. The safe reading, and the one we plan against, is that the clock is live from the moment a responsible person in your organization has good reason to believe personal data has been breached, even though you know almost nothing yet.

Awareness is organizational, not personal, and that creates a trap. If a support engineer notices something odd on Tuesday and mentions it in a channel, and it is only escalated and understood as a breach on Thursday, a regulator may reasonably ask why the clock did not start on Tuesday. Train the people who see the early signals to escalate a suspected breach at once rather than sitting on a hunch, and decide in advance who has the authority to declare awareness, so the start of the clock is a decision someone makes rather than an accident of who read which message when.

That is deliberately uncomfortable, because it forces you to work on two tracks at once: find out what happened, and prepare to report it, in parallel, not in sequence. Here is the shape of the three days.

1. 01Hour 0a responsible person becomes aware; the clock starts here, not at the first raw alert
2. 02Hours 0 to 4convene responders, contain the incident, preserve evidence before any cleanup
3. 03Hours 4 to 24scope which data and which individuals are affected; run and record the harm assessment
4. 04Hours 24 to 72draft and file the SDAIA notification against the required content list; begin notifying individuals where harm is likely
5. 05After 72 hourssupply any detail you could not confirm in time, with an explanation for the delay

The first four hours: contain without destroying the evidence

The first job is to stop the bleeding without erasing the record of how it happened. These two goals fight each other, and the technical responder’s instinct, to wipe and rebuild the affected host, is exactly what will leave you unable to answer SDAIA’s questions three days later.

Convene the responders fast and name an incident lead who owns the timeline. Contain the incident with reversible moves where you can: isolate the host from the network rather than powering it off, rotate the exposed credentials, revoke the leaked token, close the open port. Before anyone cleans up, capture what the later report will need, because it is gone once the box is reimaged. That means disk and memory images of the affected systems where feasible, copies of the relevant logs pulled to separate storage, and a note of the system clocks so your timeline is coherent.

Start the decision log in the same hour. Every significant action and the time it happened, every decision and who made it. This is not bureaucracy for its own sake. When you file, SDAIA wants to know when you became aware and what you did, and a timestamped log written as events happen is far more credible than a reconstruction assembled on day three from memory and chat scrollback.

Hours 4 to 24: scope the data and the people

With the incident contained, the question becomes what was actually exposed, and this is where a data inventory you built in peacetime pays for itself. You need to answer two things with evidence: which categories of personal data were in the affected system, and roughly how many individuals they belong to.

Resist the pull toward a single dramatic number. The notification asks for the categories of data and the actual or approximate number of affected individuals, so an honest range with a basis beats a precise figure you cannot defend. “Approximately 40,000 to 60,000 customer records, each containing name, national ID or iqama number, mobile number and account balance” is a scoping statement you can stand behind. “Around 50,000 records” with no breakdown of what was in them is not.

Pay particular attention to high-risk categories, because they raise the likelihood of harm and therefore shape both the SDAIA notification and whether you must tell individuals. For a Saudi organization that usually means national ID and iqama numbers, health data, financial account details, and children’s data. (The PDPL also defines “sensitive data” as a legal category of its own; check which of your fields fall under it, because that definition carries its own obligations.) A breach of marketing email addresses and one of national ID numbers plus account balances are different incidents, and the harm assessment is where that difference gets recorded.

The harm assessment, and the decision log

The harm assessment is the pivot of the whole process, because the duty to notify individuals turns on whether harm to them is likely, and the duty to notify SDAIA turns on whether the breach may harm data subjects or their rights or interests. Get this reasoning onto paper while you do it.

Assess against concrete consequences rather than a vague sense of severity. Could the exposed data enable identity theft or financial fraud? Could it be used to open accounts, authorize payments or take over logins? Does it reveal something about a person that exposes them to discrimination or distress? Factor in what protected the data, because encryption or strong pseudonymization that the attacker did not get the keys to genuinely lowers the likelihood of harm, and that is a legitimate and documentable input to the decision.

Write the assessment as a short reasoned record: the data involved, the plausible ways it could be misused, the factors that raise or lower the risk, and the conclusion that follows. A regulator reviewing your file later is judging whether your decision was reasonable on what you knew at the time, so the reasoning is the thing that protects you, more than the conclusion itself. A documented “we assessed harm as unlikely because the data was encrypted and the keys were never exposed, see assessment attached” is defensible. An undocumented judgment call is not.

Hours 24 to 72: the SDAIA notification

By now you are drafting the notification itself, and the content it must cover is spelled out. Draft directly against the list rather than writing prose and hoping it is complete.

• A description of the incident: what happened, when and how, and when the organization became aware of it.
• The categories of personal data involved and the types of data.
• The actual or approximate number of affected individuals.
• The risks and the actual or potential consequences of the breach.
• The measures taken or proposed to contain it and to prevent recurrence.
• Whether the affected individuals have been notified.
• Contact details of the controller and its data protection officer or another responsible person.

Two points of mechanics matter here. First, information that is not available within 72 hours can be supplied as soon as possible afterward, with an explanation for the delay (Clyde & Co). A still-unknown root cause is a reason to file what you have and follow up, never a reason to let the deadline pass. Second, the “measures taken or proposed” line is where your careful first four hours become an asset: isolating the host, rotating credentials and preserving evidence are all measures you can describe, and they show a controller acting rather than freezing.

Notifying individuals, in Arabic and English

Where harm to individuals is likely, you must also notify them without undue delay, and this is a different craft from the regulator filing. The notice to a person has to be understandable to a non-specialist and, for a Saudi customer base, it has to exist in Arabic and English, with the Arabic treated as the primary version and not a rushed machine translation of the English.

Say plainly what happened, what data about them was involved, what they should do now, and how to reach you. If the exposed data includes national ID numbers or financial details, give concrete protective steps rather than reassurance: watch for unexpected account activity, be alert to targeted phishing that references real details, and contact a named channel if they see something. Draft these notices in advance as templates with blanks, because writing calm, accurate, bilingual customer communication for the first time at hour 60 of an incident is how errors and overclaims get out the door.

NCA and SAMA, and the amendment on the horizon

PDPL notification does not happen in isolation. A regulated organization usually has an incident process that also faces the National Cybersecurity Authority, and a financial institution has supervisory expectations from SAMA on top. Treat these as parallel obligations with one underlying set of facts, so the timeline, scope and containment story you assemble for SDAIA feed the others rather than being rebuilt three times. Map which authorities you report to, and on what triggers, before an incident, because the overlap and the specific timing for NCA-facing and SAMA-facing processes depend on your sector and your own undertakings and sit outside the PDPL window discussed here.

Keep one eye on what is coming. In October 2026, SDAIA published draft amendments to the Implementing Regulations that would require notifying SDAIA within 72 hours regardless of whether harm is likely, while notification to individuals would remain subject to a harm test (Clyde & Co). These are proposals and not adopted rules, so you plan against today’s harm-based trigger for the SDAIA filing. But the direction of travel is clear enough that an organization building its playbook now would be wise to design for a world where almost every breach gets reported to the regulator.

What to prepare before anything happens

Almost everything that goes wrong in the first 72 hours was decided weeks earlier by what you did or did not prepare. The work that cannot be done under pressure is the work to do now.

Role	Who holds it	What they decide or do
Incident lead	Named on-call owner	Declares the incident, runs the clock, owns the timeline
Data protection officer	DPO or appointed responsible person	Owns the harm assessment and the SDAIA notification
Technical lead	Security or platform engineer	Contains the incident, preserves evidence, scopes affected data
Legal and compliance	In-house or external counsel	Reviews the filing, advises on NCA and SAMA overlap
Communications	Comms or customer lead	Produces the Arabic and English individual notices
Executive sponsor	CISO or equivalent	Authorizes notification and any external statement

Alongside the contact tree, keep three artifacts current. A data inventory that tells you, per system, which categories of personal data live there and roughly how many people they concern, so scoping is a lookup rather than an investigation. Pre-approved notification templates for both SDAIA and individuals, bilingual, with the content list already built in. And a decision-log format your responders know how to fill, because a log started at hour 0 is worth more than any policy document.

One dependency deserves naming in advance, because most breaches now involve a third party. If the system that was exposed is run by a cloud provider, a SaaS vendor or a payment processor, you are still the controller in SDAIA’s eyes, and your 72 hours can start when the processor tells you, or arguably when they should have. Check what your contracts actually require of those vendors: how fast they must notify you of a breach and what detail they must give you. A clause that lets a processor take a comfortable week to tell you has eaten most of your window before you even know there is a clock running.

Run the playbook before you need it. Take a realistic scenario, an exposed database or a lost unencrypted laptop, and walk a cross-functional group through it against the clock. The first time a team does this, the gaps surface immediately: nobody is sure who declares the incident, the data inventory is two years stale, there is no Arabic template. Far better to find those on a quiet afternoon than at 02:00 with a regulator’s deadline already running.

Sources

1. Saudi Arabia issues Implementing Regulations to the PDPL, Clyde & Co, 2023.
2. Saudi Arabia’s data protection law enters into force, Latham & Watkins, 2023.
3. Countdown to compliance with Saudi Arabia’s PDPL, Clyde & Co, 2024.
4. SDAIA publishes draft amendments to the PDPL, Clyde & Co, 2026.