Meeting SDAIA PDPL Requirements with Picus Platform

What Is the Personal Data Protection Law (PDPL) in Saudi Arabia?

The Personal Data Protection Law (PDPL) is Saudi Arabia's national data protection law, enacted to protect the privacy of Personal Data, govern how it is shared, and prevent its misuse. Its Implementing Regulation sets the operative controls and documentation duties. The Saudi Data and Artificial Intelligence Authority (SDAIA) is the Competent Authority under Article 30.

Article 23 of the Regulation puts the information security obligation on the Controller, the party that determines why and how Personal Data is processed, and routes it through National Cybersecurity Authority controls. This is not a law a privacy office can satisfy alone.

Who Does the PDPL Apply To?

The PDPL applies to any Controller processing Personal Data in Saudi Arabia, and, under Article 2, to parties outside the Kingdom processing data on individuals residing in it.

Article 1 defines a Controller as any Public Entity, natural person, or private legal person that specifies the purpose and manner of Processing, whether it processes the data itself or through a Processor. There is no small-entity exemption.

Because Article 1 defines Personal Data as any data that may directly or indirectly identify an individual, few production systems fall outside scope. Sensitive Data, including Health Data, carries heightened obligations.

PDPL Controller vs Processor: What Is the Difference?

Under the PDPL, the Controller specifies why and how Personal Data is processed while the Processor acts on the Controller's behalf, and the Controller remains accountable for both.

Article 8 of the Law requires the Controller to select only Processors offering the necessary guarantees and to monitor their compliance, without prejudice to its own responsibilities toward the Data Subject and the Competent Authority.

Article 17, paragraph 4 of the Regulation goes further, treating a Processor that violates the Controller's instructions as a Controller itself. Outsourcing Processing transfers execution, not answerability.

What Are the PDPL Security Requirements?

The PDPL requires the Controller, under Article 19 of the Law, to implement all necessary organizational, administrative, and technical measures to protect Personal Data, including during Transfer.

Article 23 of the Implementing Regulation requires those measures to limit security risks related to a Personal Data Breach, and mandates adoption of National Cybersecurity Authority (NCA) controls, or recognized best practices where the Controller is not bound by them.

What Are the Penalties for PDPL Non-Compliance?

PDPL fines reach five million Riyals under Article 36 of the Law, doubling on repeat.

Article 30 lets the Competent Authority demand the records behind a violation, and Article 36 of the Regulation aims audits at whether Personal Data is properly protected. 48 decisions followed by early 2026.

How Picus Supports PDPL Compliance

The PDPL asks the Controller to prove that its protective measures are adequate to the risk. Read in effectiveness terms, that means the Controller needs a standing answer to three questions: which exposures in its estate can actually be used to reach Personal Data, whether the deployed control stack prevents and detects the techniques an attacker would use to reach it, and how quickly a Personal Data Breach would become visible so that the 72-hour notification clock in Article 24 can be met.

The Picus Platform produces these answers continuously, drawing on three validation techniques delivered as one loop. Picus Breach and Attack Simulation (BAS) proves what the live control stack (EDR, SIEM, firewall, WAF, email security) blocks, detects, and misses, and ships the vendor-specific and vendor-neutral fix when a control fails. Picus Autonomous Penetration Testing safely fires real exploit chains against reachable assets, showing whether an attacker can reach crown-jewel assets. Picus Exposure Validation proves exploitability without firing a live exploit, delivering a defensible verdict on the day a vulnerability is disclosed and reaching the restricted, production-critical, and air-gapped assets no live test can safely touch.

This guide covers the PDPL provisions where validation produces useful evidence:

• PDPL Article 19 and Implementing Regulation Article 23(b): Necessary Measures and National Cybersecurity Authority Controls
• Implementing Regulation Article 23(a): Limiting Security Risks Related to Personal Data Breach
• PDPL Article 22 and Implementing Regulation Article 25: Impact Assessment
• PDPL Article 30 and Implementing Regulation Article 36: Auditing and Controlling

PDPL Article 19 and Implementing Regulation Article 23(b): Necessary Measures and National Cybersecurity Authority Controls

Article 23(b) resolves what necessary means by pointing outward, requiring adoption of the controls, standards, and rules issued by the National Cybersecurity Authority.

How does Picus support PDPL Article 19 and Implementing Regulation Article 23(b)?

Picus Breach and Attack Simulation validates the deployed control stack against a threat library of 7500+ threat scenarios, mapped to MITRE ATT&CK at sub-technique level, so a Controller's National Cybersecurity Authority control mapping can be re-expressed as measured prevention and detection rates rather than only implementation status. Because the simulations run continuously and safely in production, the resulting figure tracks the estate as it changes rather than as it stood at the last assessment.

Figure 1. Picus Threat Library, Endpoint Attacks Module

When a control fails, the platform does not stop at the finding. Picus supplies both vendor-specific and vendor-neutral mitigation. So a Controller can close a validated gap rapidly. Re-running the same simulation afterwards confirms the gap is closed.

Figure 2. Picus Mitigation Library, Vendor-Specific Mitigation Signatures

The National Cybersecurity Authority's control set also requires penetration testing and vulnerability management as controls in their own right. Picus Autonomous Penetration Testing covers the first by safely running real exploit chains network-wide, and Picus Exposure Validation covers the second by proving which vulnerabilities are exploitable against the deployed controls.

Because Article 23(b) points directly at the National Cybersecurity Authority's own frameworks, the control-by-control detail is covered in a separate blog. For more detail, you can read here.

Implementing Regulation Article 23(a): Limiting Security Risks Related to Personal Data Breach

The key verb is limit, which implies prioritization. Severity is not exposure, because a 9.8 says nothing about whether the vulnerable service is reachable here, whether the deployed controls would break the exploit chain, or whether the affected asset sits anywhere near a store of Personal Data.

Ranked by CVSS alone, thousands of findings look equally urgent, so remediation effort drains into noise while the few exposures that actually reach Personal Data stay open and risk does not fall.

How does Picus support Implementing Regulation Article 23(a)?

Picus Exposure Validation resolves each exposure into a decision (Patch, Mitigate, Monitor, or Accept with Evidence) by decomposing the vulnerability into the exploit primitives an attacker would have to execute and walking that chain against the Controller's real control stack, per asset.

Where an asset is safely testable live, Picus Autonomous Penetration Testing fires the real exploit chain and cross-references that proof directly onto the exposure.

Where it is not, TTP-Chain Validation supplies a verdict without firing an exploit. That covers restricted systems, production crown jewels, and air-gapped segments, which together account for the majority of a typical estate.

Figure 3. Illustration of TTP-Chain Validation

What was a severity score becomes a dated, per-asset finding recording either that the exposure was exploited on that machine or which control stopped it, and that verdict feeds the Picus Exposure Score, which blends CVSS, EPSS, validation results, and asset density instead of severity alone.

Figure 4. Picus Exposure Score

PDPL Article 22 and Implementing Regulation Article 25: Impact Assessment

Three of the elements Article 25 makes mandatory turn on how controls actually behave:

• Paragraph 2(f) requires the likelihood of a negative impact on Data Subjects, not only its severity.
• Paragraph 2(g) requires the measures to be taken to prevent or mitigate risks.
• Paragraph 2(h) requires their suitability.

Paragraph 4 then requires the assessment to be re-conducted where it shows harm.

How does Picus support PDPL Article 22 and Implementing Regulation Article 25?

Picus supplies the measured input that turns a suitability judgement into a substantiated one. For each measure an impact assessment relies on, Picus BAS can report current prevention and detection rates, and Picus Exposure Validation can report whether the exposures the assessment identified as risks are exploitable against the controls as deployed.

Because validation runs continuously rather than as a scheduled exercise, the measures an assessment relies on are re-tested as the environment changes. Configuration drift, a control quietly dropping off, a new asset appearing, or a newly disclosed vulnerability in the in-scope systems each shows up as a changed verdict instead of waiting for the next review. That is what makes the re-assessment Article 25, paragraph 4 requires practical rather than theoretical, because the Controller learns the basis has shifted while there is still time to act on it.

The Picus Report Center turns that into an attachment for the assessment itself, exporting a dated record of which measures were tested, against which techniques, and with what result, rather than leaving suitability asserted in prose.

PDPL Article 30 and Implementing Regulation Article 36: Auditing and Controlling

Article 30 lets the Competent Authority request documents and specify how compliance is monitored.

Notice what Article 36 points the audit at. It is not the policy set, but whether the entity is properly protecting Personal Data.

How does Picus support PDPL Article 30 and Implementing Regulation Article 36?

Validation changes the Controller's posture going into an Article 36 review from reconstruction to retrieval. Because the Picus Platform runs continuously, the Controller arrives with a history rather than a snapshot, showing which techniques were tested, on which dates, against which controls, with which verdicts; which exposures were resolved to Patch, Mitigate, Monitor, or Accept with Evidence, and on what basis; which failures were found, what fix was deployed, and what the re-test showed.

The same body of evidence serves the Competent Authority's document requests, and it accumulates without additional preparation effort, because it is a by-product of running the validation loop rather than a separate compliance exercise.

For a Controller, this is the record an auditor finds hardest to argue with, because it shows not only that the measures were adequate on the day of the review, but that they have been repeatedly tested, repeatedly found wanting in specific places, and repeatedly corrected.

Making PDPL Compliance Resilient with Validation

PDPL compliance is not a single filing. Article 19 asks for measures that are necessary, Article 23(a) of the Regulation that the risk be limited, Article 25 whether planned measures are suitable, and Article 36 of the Regulation whether Personal Data is properly protected. Every one of those words describes an outcome, not a document. A policy library shows that a measure exists; it cannot show that it works. Control presence is not control effectiveness.

Picus tests those measures rather than describing them. Picus BAS reports what the deployed stack prevented and detected, Picus Autonomous Penetration Testing shows what an attacker can reach, and Picus Exposure Validation turns each exposure into a defensible decision. Because the loop runs continuously, a control that quietly stops working surfaces as a changed verdict rather than an audit finding, and what accumulates is a dated record of what was tested, what failed, and what the re-test showed.

Get your demo to see how Picus helps Controllers prove, not assert, that their measures satisfy the Saudi Personal Data Protection Law.

References

• Saudi Data and Artificial Intelligence Authority (SDAIA), "Personal Data Protection Law," Royal Decree No. M/19 of 9/2/1443H, as amended by Royal Decree No. M/148 of 5/9/1444H, Riyadh, Saudi Arabia, ver. 2, Apr. 23, 2023. [Online]. Available: https://sdaia.gov.sa/en/SDAIA/about/Documents/Personal%20Data%20English%20V2-23April2023-%20Reviewed-.pdf. [Accessed: Aug. 4, 2026].
• Saudi Data and Artificial Intelligence Authority (SDAIA), "The Implementing Regulation of the Personal Data Protection Law," Riyadh, Saudi Arabia, Sep. 7, 2023. [Online]. Available: https://sdaia.gov.sa/en/SDAIA/about/Documents/ImplementingRegulationPersonalDataProtectionLaw.pdf. [Accessed: Aug. 4, 2026].