Revenue and market access
Saudi enterprise and government buyers ask suppliers to show how personal data is protected. Clear evidence shortens procurement and protects contracts.
Board and leadership view
Why Saudi PDPL matters to your board
The work is technical. The consequences of getting Saudi PDPL wrong show up in revenue, liability and reputation, which is why we report on it in the language of the boardroom first.
Regulatory exposure and liability
The law carries fines and other sanctions, and accountability sits with the controller. A tested, documented position is easier to defend.
Reputation
A breach of Saudi residents’ data is a public trust problem as well as a legal one. Finding weaknesses first keeps the story in your hands.
Deadlines and ownership
The grace period is over. Leadership needs a named owner, a plan and dates, not a general intention to comply.
Fit
Who needs to pay attention
SaaS and cloud providers serving Saudi customers
Enterprise and government buyers increasingly ask suppliers how Saudi personal data is protected.
Banks, fintechs and insurers
Financial data is among the most sensitive categories and sits alongside sector regulator rules.
Healthcare and life sciences
Health data is classed as sensitive and needs stronger access control and logging.
Foreign companies with Saudi users
The law follows the data subject, so being based outside the Kingdom does not remove the duty.
Scope of work
What Summit delivers for Saudi PDPL
One accountable team takes you from scoping to retest. The people who test your systems are the people who explain the findings to your leadership.
Gap analysis
We map your Saudi PDPL security safeguards against what the law expects and rank the gaps by business impact.
Penetration testing of systems holding personal data
Human-led testing of the applications, APIs, cloud and networks that store or process Saudi personal data, with proof of impact.
Control validation
We check that access control, encryption, logging and retention work as your policies say, not just that they exist.
Evidence pack
Test results, screenshots, scope notes and fix records organised so a regulator, auditor or customer can follow them.
Remediation support and retest
Our engineers explain each fix to your developers, then retest and issue updated results showing what closed.
Board-ready report
A short executive summary in plain English with risk ratings, owners and dates, ahead of the technical detail.
Fixed scope, one team, no hand-offsYou get a named lead, a clear scope document before work starts and a report your leadership, customers and reviewers can read without a translator. We stay with you through your review to answer questions about what we tested and found.
How it works
A realistic Saudi PDPL security roadmap
Timelines are typical ranges, not promises. Yours depends on scope, team size and how much is already in place.
- 1
Map Saudi personal data
Weeks 1 to 3List the systems, vendors and flows that touch Saudi personal data, and flag sensitive categories.
- 2
Gap analysis
Weeks 3 to 5Compare current safeguards with what the law and your customers expect, and rank the gaps.
- 3
Test the systems
Weeks 5 to 9Penetration test applications, APIs and cloud environments holding personal data, with validation of core controls.
- 4
Fix and retest
Weeks 9 to 14Close findings with developer support, then retest so the results show what is resolved.
- 5
Board report and evidence pack
Week 14 onwardsHand leadership a plain-English report and an organised evidence pack to reuse with regulators and buyers.
Deliverables
What your leadership team receives
Every engagement ends with material written for two audiences: a plain-language view for executives and the board, and full technical detail for the engineers who fix things.
One-page executive summary
Where personal data is most exposed, what it could cost the business and what to fix first.
Risk-ranked findings
Every issue rated by severity and business impact, with a named owner and a target date.
Evidence you can show
A tidy pack of testing evidence for regulators, customers, insurers and your own auditors.
Verified fixes
A retest report confirming which issues are closed, so leadership is not relying on a developer saying so.
A clear next 90 days
A prioritised plan with effort and ownership, ready to take into a board or audit committee meeting.
The detail
What the Saudi PDPL actually is
The Personal Data Protection Law was issued by Royal Decree M/19 in 2021 and amended in 2023. Its implementing regulations and a cross-border transfer regulation followed, and the law took effect on 14 September 2023. A one-year grace period ended on 14 September 2024, so it is now fully enforceable. The regulator is SDAIA, the Saudi Data and AI Authority.
The law applies to any organisation that handles the personal data of people in Saudi Arabia, including companies based abroad. It sets duties on purpose limitation, consent and notice, individual rights, record keeping, breach notification and cross-border transfers. Sensitive data such as health, financial and biometric data carries stricter handling.
Security is a core duty: controllers must put technical and organisational measures in place to protect personal data. Regulators and customers judge that by evidence. Penetration testing and control validation are the clearest evidence a technical team can produce. This guide is educational and is not legal advice.
Key terms in plain English
- Controller
- The organisation that decides why and how personal data is processed. It carries the main legal duties.
- Sensitive data
- Categories such as health, genetic, financial and biometric data, with stricter rules for use and protection.
- Record of processing
- A written record of processing activities that must be kept and shown to SDAIA on request.
- Cross-border transfer
- Sending personal data outside Saudi Arabia. It needs a lawful basis and appropriate safeguards under the transfer regulation.
Requirements
The duties that have a technical side
Much of the PDPL is legal and procedural. These are the parts where your engineering team has to produce evidence, and where a testing programme helps most.
1
Protect personal data with appropriate security measures
Controllers must apply technical and organisational measures proportionate to the risk. For systems with a lot of personal data, regulators and customers expect proof the measures work, not only a policy that describes them.
What it looks like in practice
- Access to personal data is limited by role and reviewed
- Data is encrypted in transit and at rest where sensible
- Systems holding personal data are penetration tested and fixes are retested
- Logs show who viewed or exported personal data
2
Detect and report personal data breaches
In qualifying cases, SDAIA expects notice within 72 hours of becoming aware, and affected people may need to be told too. You cannot report what you cannot detect, so monitoring and an exercised response plan matter.
What it looks like in practice
- Alerting that catches unusual access or data export
- A named incident owner with contact points for SDAIA
- A tested plan with decision rules for notification
3
Know what you hold and keep records
You need to know what personal data you process, where it lives, who can reach it and why. Records of processing must be kept and made available to SDAIA when asked.
What it looks like in practice
- A data inventory that matches real systems
- Retention periods that are actually enforced
- Named owners for each system holding personal data
4
Control data leaving the Kingdom
Transfers abroad need a lawful basis and safeguards under SDAIA’s transfer regulation. An adequacy list was still unpublished in the sources we reviewed, so many teams rely on contractual safeguards. Technically, you must know where data flows.
What it looks like in practice
- A map of every system and vendor that receives Saudi personal data
- Encryption and access limits on outbound transfers
- Contracts with processors that reflect your security duties
5
Hold suppliers to the same standard
Controllers stay responsible when a vendor processes data on their behalf. Buyers will ask how you assess and test the suppliers and platforms in your data path.
What it looks like in practice
- A vendor register covering personal data flows
- Security terms and testing evidence from critical vendors
- Offboarding steps that remove or return data
Where testing fits
How penetration testing supports Saudi PDPL
The PDPL does not name a penetration test as a stand-alone requirement. It does require appropriate security for personal data, and a human-led test with a retest is the strongest practical evidence that your safeguards hold up against a real attacker.
Security duty
Protecting personal data
Testing shows whether the measures you describe hold up against realistic attacks on live systems.
Breach readiness
Detection and response
A test shows whether your monitoring would notice an intruder reaching personal data, and how quickly.
Accountability
Evidence on request
Dated reports with scope, findings and retest results are easy to produce if SDAIA or a customer asks.
Vendors
Supplier assurance
Testing the integrations and APIs that pass personal data to vendors exposes weak links in the chain.
Avoid these
Common Saudi PDPL mistakes, and how to avoid them
!
Treating the PDPL as only a legal project
Privacy notices matter, but the duty to protect data is technical. Without testing evidence, security claims are unsupported.
!
Assuming being foreign means exempt
The law follows the data of people in Saudi Arabia, so overseas companies with Saudi users should assess exposure.
!
Relying on a scanner report
Automated scans miss business-logic and access-control flaws, which are the ones that expose personal data.
!
Ignoring where data flows
Without a map of transfers and vendors, you cannot show safeguards or answer questions about cross-border movement.
FAQ
Saudi PDPL questions, answered
Is the Saudi PDPL in force?
Yes. It took effect on 14 September 2023 and a one-year grace period ended on 14 September 2024, so it is now enforceable. SDAIA is the regulator.
Does it apply to companies outside Saudi Arabia?
It applies to organisations that process personal data of individuals in Saudi Arabia, including those based abroad. Your legal adviser can confirm how it applies to your situation.
Does the PDPL require penetration testing?
It does not use those words. It does require appropriate security for personal data, and testing is a widely used way to evidence that your safeguards work.
What are the penalties?
The law lists penalties including a headline maximum fine of SAR 5 million for some offences, and other sanctions are possible. We did not find a verified public list of fines issued, so treat exposure as real but case specific.
How quickly must a breach be reported?
In qualifying cases SDAIA expects notice within 72 hours of becoming aware. Rules vary by risk level, so confirm the exact trigger with your legal adviser.
Does a Summit assessment give us legal clearance?
No testing firm can grant legal status. Summit delivers gap analysis, penetration testing, control validation and a board-ready report, so you can show your technical safeguards are in place and tested.
How long does a first assessment take?
A focused scope often takes four to six weeks for assessment and testing, then fixes and a retest. Scope and the number of systems drive the timeline.
Related frameworks
Often assessed alongside Saudi PDPL
Saudi ArabiaNCA ECCThe Saudi National Cybersecurity Authority baseline: four domains, what assessors look for, and the testing evidence that backs each control.Privacy lawUAE PDPLThe UAE federal data protection law in plain language, with honest notes on its implementation status and how it sits beside DIFC and ADGM.Privacy lawGDPRSeven principles, six lawful bases and the 72-hour breach clock. See how Article 32 security testing fits your obligations.
Browse all 23 security and compliance frameworks or see our penetration testing services.
Helpful resources
ChecklistPre-launch security checklistKeep reading on the Summit resources hub.ReportSample VAPT reportKeep reading on the Summit resources hub.GuideAPI security guideKeep reading on the Summit resources hub.
Last reviewed October 2026. Requirements change; confirm current texts and dates before you commit to a plan.