When a personal data breach occurs at a Saudi data controller, the immediate focus falls on the 72-hour notification deadline established by the Saudi Data and Artificial Intelligence Authority under the Personal Data Protection Law. Yet SDAIA inspectors do not begin their review by checking the timestamp on your submission. They verify whether you made—and documented—four specific decisions before the report left your organization. These decisions form the foundation of any defensible PDPL breach notification procedure, and their absence is the most common reason controllers face follow-up enforcement action even when they meet the 72-hour deadline.
This article describes the four documented decisions SDAIA expects, the evidence format that satisfies regulatory scrutiny, and the internal workflow that produces this documentation under time pressure.
Why Documentation Precedes Notification
The Personal Data Protection Law requires controllers to notify SDAIA of breaches that pose a risk to the rights and freedoms of natural persons. The regulation does not treat notification as a mechanical reporting exercise. SDAIA expects controllers to assess the breach, determine its scope, implement containment measures, and decide whether notification is necessary—all before submitting the 72-hour report.
Inspectors verify this sequence because it demonstrates that the controller exercised judgment rather than forwarding raw incident data. A notification submitted without supporting decision records suggests the controller lacks a functioning breach-response procedure, which is itself a compliance gap under the law.
Controllers often discover this expectation during post-breach audits, when SDAIA requests the decision log, risk assessment, and containment records that should accompany the notification. Producing these documents weeks after the event is both difficult and unconvincing.
The Four Documented Decisions
1. Breach Classification
The first decision is whether the incident constitutes a personal data breach under PDPL. Not every security event qualifies. SDAIA defines a breach as unauthorized or unlawful processing of personal data, or accidental loss, destruction, or damage. The controller must document why the incident meets this definition.
The decision record should state:
- The nature of the incident (unauthorized access, accidental disclosure, ransomware encryption, physical theft, misconfigured system)
- The personal data categories involved (national ID numbers, financial records, health information, employment data)
- Whether the data was accessed, disclosed, altered, or destroyed
- The legal basis for classifying the event as a breach
This is not a narrative incident report. It is a structured determination that maps the facts to the regulatory definition. Inspectors look for evidence that a qualified person—typically a data protection officer or legal counsel—reviewed the incident against the PDPL criteria before escalation.
2. Affected-Individual Count
The second decision is the number of individuals whose personal data was compromised. This count drives both the notification obligation and the risk assessment. SDAIA expects controllers to document the methodology used to arrive at the number, not just the final figure.
The decision record should include:
- The data systems or repositories involved
- The date range of the affected records
- The method used to identify unique individuals (database queries, log analysis, file inventories)
- Any assumptions or limitations in the count (e.g., "logs retained for 90 days only; earlier exposure cannot be confirmed")
Precision matters less than transparency. If the breach involves a backup tape containing three years of customer records, the count may be an estimate. SDAIA accepts this, provided the controller documents the estimation method and explains why a precise count is unavailable. What inspectors reject is a round number with no supporting calculation.
3. Containment Measures
The third decision concerns the steps taken to contain the breach and prevent recurrence. SDAIA expects evidence that the controller acted to limit harm before submitting the notification. This decision record serves two purposes: it demonstrates that the controller fulfilled its duty to mitigate risk, and it provides SDAIA with assurance that the breach is not ongoing.
The decision record should describe:
- Immediate actions taken (system isolation, password resets, access revocation, physical security changes)
- The individual or team responsible for each action
- The date and time each measure was implemented
- Verification that the containment was effective (e.g., "unauthorized access ceased at 14:22 on [date] following credential rotation")
Controllers sometimes delay containment documentation until after the 72-hour notification, treating it as a separate workstream. This creates risk. If SDAIA requests evidence that the breach was contained before notification, the controller must produce timestamped records—change logs, ticket systems, email instructions—that prove the sequence of events.
4. Notification Necessity
The fourth decision is whether the breach must be reported to SDAIA and whether affected individuals must be notified directly. Not all breaches require both. SDAIA expects controllers to apply a risk-based test and document the outcome.
For SDAIA notification, the controller must determine whether the breach is likely to result in a risk to the rights and freedoms of natural persons. Factors include the sensitivity of the data, the number of individuals affected, the ease of identifying individuals, and the potential consequences (identity theft, financial loss, reputational harm, discrimination).
For individual notification, the controller must assess whether the breach is likely to result in a high risk. If technical or organizational measures render the data unintelligible (e.g., encryption with keys held separately), individual notification may not be required.
The decision record should state:
- The risk level assigned (low, medium, high)
- The factors considered in the risk assessment
- The conclusion (notify SDAIA only, notify SDAIA and individuals, or no notification required)
- The legal or technical justification for the conclusion
This record is the most scrutinized. If the controller decides not to notify individuals, SDAIA will verify that the risk assessment was rigorous and that mitigating factors are genuine. A claim that data was encrypted must be supported by evidence of the encryption method, key management, and confirmation that keys were not compromised.
The Internal Workflow That Produces These Decisions
Documentation does not happen automatically. It requires a workflow designed to capture decisions as they are made, not reconstruct them later. The most effective breach-response procedures assign clear roles and embed documentation checkpoints into the response sequence.
A typical workflow includes:
Incident detection and triage. The security or IT team identifies a potential breach and escalates to the data protection officer or legal counsel. The escalation includes a preliminary description of the incident and the data involved.
Breach classification. The data protection officer reviews the incident against the PDPL definition and documents the classification decision. If the incident does not qualify as a breach, the workflow stops here, and the decision is recorded for audit purposes.
Scope determination. The data protection officer, working with IT and business units, determines the affected-individual count and documents the methodology. This step often requires database queries, log reviews, or file analysis, and the results are saved as evidence.
Containment execution. The security team implements containment measures and records each action in the incident-management system. The data protection officer verifies that containment is complete before proceeding.
Risk assessment. The data protection officer conducts the risk assessment, applies the notification criteria, and documents the decision. If notification is required, the officer prepares the SDAIA report and, if necessary, the individual notification.
Approval and submission. Senior management or legal counsel reviews the decision records and approves the notification. The report is submitted to SDAIA within 72 hours of breach discovery, and the supporting documentation is retained.
This workflow ensures that each decision is made by the appropriate person, at the right time, with the necessary evidence. It also creates an audit trail that SDAIA can verify.
Evidence Formats SDAIA Accepts
SDAIA does not prescribe a specific format for decision records, but inspectors expect consistency and clarity. Acceptable formats include:
- Structured decision logs with fields for incident ID, decision type, decision maker, date, rationale, and supporting evidence
- Incident-management system records with timestamped entries for each decision point
- Email chains or meeting notes that capture the decision process, provided they are organized and indexed
- Risk-assessment templates completed for each breach
The format matters less than the content. Each decision record must answer three questions: What decision was made? Who made it? What evidence supported it?
Controllers should avoid relying solely on narrative incident reports. A ten-page chronology of the breach response may contain the necessary information, but inspectors will not extract it. Decision records should be discrete, indexed, and easy to locate.
When to Build This Capability
Controllers need a documented breach-response procedure before a breach occurs. Building the workflow, decision templates, and role assignments during an incident is not feasible. The 72-hour clock does not pause while the organization designs a process.
The time to establish this capability is during the initial PDPL compliance program. Controllers should develop breach-response procedures alongside data-mapping, records of processing, and data-subject rights procedures. These elements form a single compliance framework, and each depends on the others.
Signs that a controller needs to formalize its breach-response procedure include:
- No documented process for classifying incidents as personal data breaches
- Uncertainty about who has authority to notify SDAIA or affected individuals
- Lack of templates or checklists for breach risk assessment
- No integration between incident-management systems and data-protection workflows
- Previous breaches handled inconsistently or without clear decision records
A good outcome is a breach-response procedure that produces the four documented decisions automatically, under time pressure, with minimal senior-management intervention. The procedure should be tested through tabletop exercises that simulate different breach scenarios and verify that the workflow produces the required documentation within the 72-hour window.
How the Firm Supports Breach-Response Readiness
CISO Consulting delivers breach response procedures as part of its Personal Data Protection (PDPL) compliance program. The engagement produces data-subject rights and breach response procedures that integrate with the controller's existing security program. The procedures are designed to generate the documented decisions SDAIA expects, in the evidence formats inspectors accept, within the required timeframe.
The program also includes a staff awareness session that trains the individuals responsible for executing the breach-response workflow. The session covers the four decision points, the evidence requirements, and the escalation process.
The engagement runs over 6–8 weeks and produces a complete set of PDPL compliance deliverables, including the personal data inventory and data-flow maps, records of processing activities, privacy notices and consent approach, and the breach-response procedures. Controllers receive controls integrated with their security program and breach notification ready within the required timeframe.
For controllers preparing for PDPL compliance or seeking to formalize their breach-response capability, the firm's Personal Data Protection service provides the procedures, templates, and training necessary to meet SDAIA's expectations. The engagement is structured to deliver practical, operational documentation that functions under the pressure of a live incident.
