When personal data is exposed, Saudi Arabia's Personal Data Protection Law (PDPL) requires the organisation responsible for it to notify the competent authority and, in some cases, the affected individuals. The Implementing Regulation sets a 72-hour deadline. Most of the facts that notification needs come from IT: logs, timelines, system inventories and a record of what was done.
This article summarises the official texts published by SDAIA and turns them into a practical checklist for technical teams. It is educational and is not legal advice; for decisions about a real incident, read the official texts and consult your legal adviser or data protection officer.
The legal basis
Article 20 of the PDPL requires the controller to notify the competent authority upon knowing of any breach, damage or illegal access to personal data, and to notify the data subject where it would cause damage to their data or prejudice their rights and interests, in accordance with the regulations. Article 24 of the Implementing Regulation sets out the details. SDAIA publishes the Arabic texts on its National Data Governance Platform knowledge centre, and Article 24 reads the same in the current Arabic version. The article before it, Article 23, requires the controller to take security measures to limit breach risks and to follow National Cybersecurity Authority controls, or recognised cybersecurity standards where those controls do not apply to it.
What counts as a breach
The Implementing Regulation defines a personal data breach as any incident that leads to the disclosure, destruction or unauthorised access to personal data, whether intentional or accidental, and by any means, automated or manual. That covers a hacked server, but also an exposed backup bucket, a misdirected email with a customer list, or a lost unencrypted laptop.
Who notifies, and when
- The controller notifies the competent authority within no more than 72 hours of becoming aware of the incident, if the incident may harm the personal data or the data subject, or conflict with their rights or interests (Article 24(1)).
- If some information is not available within 72 hours, the controller must provide it as soon as possible, with justification for the delay (Article 24(2)). The clock does not wait for the investigation to finish.
- Processors (for example an IT service provider handling data on the controller's behalf) must be contractually committed to notify the controller of a breach without undue delay (Article 17(1)(d)).
- The data protection officer, where one is appointed, has notifying the competent authority of breach incidents among their listed tasks (Article 32).
- Other reporting duties remain. Article 24(4) states that these provisions do not affect obligations to report to the National Cybersecurity Authority or under other applicable laws.
The notice is filed through SDAIA's Personal Data Breach Notification e-service. Its service page lists a valid registration certificate from the National Data Management Office as a requirement, and the steps: log in to the National Data Governance Platform, open the e-services, choose the breach notification service, complete the form and submit it. Make sure someone in your organisation can log in before an incident happens.
What the notification must contain
Article 24(1) lists the content. Each item maps to something IT has to produce:
| Required in the notice | Where the facts come from |
|---|---|
| Description of the breach, including its time, date and how it happened, and when the controller became aware of it | Detection alerts, system and application logs, an incident timeline |
| Categories and actual or approximate number of affected data subjects, and the type of personal data | Data inventory and records of processing activities, database row counts |
| Risks and actual or potential impact, measures taken to prevent or limit them, and future measures to avoid recurrence | Containment log, root cause analysis, remediation plan |
| Whether data subjects have been or will be notified | Decision record from management and the DPO |
| Contact details of the controller or its DPO, or another official with information on the incident | Incident response plan |
Individuals must be told without undue delay when the breach may cause damage to their data or conflict with their rights or interests, in simple and clear language, with a description of the breach, the likely risks and measures taken, contact details, and advice on how they can protect themselves (Article 24(5)). The controller must keep copies of the reports it submitted and document the corrective measures and supporting evidence (Article 24(3)).
What IT teams should have ready before an incident
- Accurate time. Every timestamp in the notice depends on synchronised clocks. Check with
timedatectl statusthat NTP synchronisation is active on each server. - Logs that go back far enough and survive an attack. Know how long you keep authentication, web server, database and cloud console logs, and send copies to a separate system so an intruder cannot erase them. On a systemd-based server,
journalctl --disk-usageandjournalctl --list-bootsshow how much history is kept locally. - A data inventory. Article 33 of the Implementing Regulation already requires written records of processing activities. Link them to systems: which servers, databases and buckets hold which categories of personal data, and roughly how many records.
- An incident log template. Record when and how the issue was detected, who was informed and when, each containment step (isolating a server, revoking keys, resetting passwords) and the evidence preserved.
- Evidence preservation. Copy relevant logs and, where possible, disk images before rebuilding a compromised server, and record where the copies are kept.
- Contacts and access. Who decides whether the harm threshold is met, who files on the platform, and the processor contacts who must inform you.
An example of pulling SSH login history for a time window on Debian or Ubuntu:
sudo journalctl -u ssh --since "2026-10-30 00:00" --until "2026-10-31 00:00"What you should do
- Read Articles 17, 23, 24, 32 and 33 of the Implementing Regulation with your legal adviser or DPO, and agree who decides and who files.
- Confirm your organisation's registration and access to the National Data Governance Platform before you need it.
- Map the Article 24 notice fields to the logs and inventories that answer them, and fix gaps in time sync and log retention.
- Make sure processor contracts include prompt breach notification to you.
- Rehearse a 72-hour notification with a tabletop exercise at least once a year.
Sources
- sdaia.gov.sa/en/SDAIA/about/Documents/Personal%20Data%20English%20V2-23April2023-%20Rev...
- sdaia.gov.sa/en/SDAIA/about/Documents/ImplementingRegulation.pdf
- dgp.sdaia.gov.sa/wps/wcm/connect/c863ed7e-4bdf-4bb7-b30d-704db0a8b4b9/%D8%A7%D9%84%D9%8...
- dgp.sdaia.gov.sa/wps/wcm/connect/d60cac13-b94f-4e58-9af5-14c4979c376d/%D9%86%D8%B8%D8%A...
- dgp.sdaia.gov.sa/wps/portal/pdp/services/personaldatabreachnotification
- dgp.sdaia.gov.sa/wps/portal/pdp/knowledgecenter
Comments
0 total · 0 threads