PDPL Compliance Checklist: Website and App Security in Saudi Arabia
A practical checklist for Saudi companies running websites and apps: what the PDPL expects, the technical controls that protect customer data, and how to verify them.
خلاصة المقال
- 01Start with a data inventory: you cannot protect personal data if you do not know where it is collected, stored and who can reach it.
- 02Enforce multi-factor authentication on every admin account, encrypt data in transit and at rest, and move secrets out of the code.
- 03Prepare an incident response plan before you need it, since the implementing regulations require notifying SDAIA within 72 hours of learning of a harmful breach.
- 04Do not launch a new product before an independent penetration test and fixing every critical and high finding.
PDPL compliance checklist: what does the law mean for your website or app?
In short: if your website or app collects personal data about individuals in Saudi Arabia, such as names, mobile numbers, addresses and order history, the Personal Data Protection Law (PDPL) applies to you. In practice that means collecting only what you need for a clear purpose, informing users and obtaining consent where required, protecting the data technically, and being ready to report a breach within a short deadline.
This guide brings both sides together: what the law expects at a high level, and a practical website and app security checklist your team can start on this week, with a table showing how to verify each control.
Important: this article is guidance, not legal advice. Detailed requirements are set by the law, its implementing regulations and updates from the competent authority, so check the official texts and consult legal counsel before making any compliance decision.
The Saudi Personal Data Protection Law at a glance
The PDPL came into force in September 2023, with a one-year transition period that ended in September 2024. The competent authority overseeing it is the Saudi Data and Artificial Intelligence Authority (SDAIA). The main areas it governs:
- Collection and processing: processing needs a lawful basis, data should in principle be collected directly from the individual, and only to the extent necessary.
- Consent: consent is a central basis for processing, alongside other cases defined in the law, and individuals can withdraw it.
- Purpose limitation: data is used for the purpose it was collected for, not repurposed without a basis.
- Data-subject rights: such as the right to be informed, to access their data, to obtain a copy, to have it corrected and to request its destruction.
- Breach notification: the implementing regulations require notifying SDAIA within 72 hours of becoming aware of a breach that may harm the data or the individuals concerned, and informing affected individuals without undue delay where harm is likely.
- Cross-border transfer: transferring personal data outside the Kingdom is restricted to conditions set by the law and a dedicated transfer regulation, which directly affects your choice of hosting and cloud providers.
Since where your data lives is part of that decision, our guide to cloud hosting vs dedicated servers may help.
Where do NCA cybersecurity controls fit?
The National Cybersecurity Authority (NCA) has issued the Essential Cybersecurity Controls (ECC), which are mandatory for government entities and for organisations that own or operate critical national infrastructure, including private-sector ones. It has also issued more specialised controls, among them the Cloud Cybersecurity Controls (CCC). If your company is outside the mandatory scope, these controls are still an excellent reference for building a structured security programme, and government or enterprise clients may ask about them when contracting. Confirm whether they apply to you on the NCA’s official website.
The website and app security checklist
- A full inventory of personal data: what we collect, why, where it is stored, who can access it and when it is deleted.
- Data minimisation: remove unnecessary fields from forms, databases and logs.
- A clear privacy notice in Arabic, available before collection, and explicit consent where required.
- A working process to receive and answer data-subject requests (access, correction, destruction).
- Least-privilege access and multi-factor authentication (MFA) on every admin account.
- Encryption in transit (TLS) on every interface, and encryption at rest for databases and backups.
- Secrets management: no API keys or passwords in code or repositories.
- Secure coding and code review against the OWASP Top 10.
- Regular, scheduled updates for libraries, plugins and operating systems.
- Encrypted backups and a documented restore test every quarter.
- Centralised logging, monitoring and alerts on security events.
- An incident response plan that includes the 72-hour path to notify SDAIA.
- Clear contracts with processors and vendors that set out data-protection obligations.
- An independent penetration test before launch and after every major change.
Data and privacy controls: where to start
Data inventory and minimisation
Start with a simple spreadsheet: every form on the site, every screen in the app and every integration (payment gateway, SMS provider, analytics tool, WhatsApp Business), and which personal data flows through it. This inventory underpins everything that follows and supports the records of processing the law expects you to keep. A pattern we see often: forms asking for date of birth or national ID with no real need. Every field you do not collect is a risk you do not have to protect.
Privacy notice and consent
Write the privacy policy in language your customers understand, Arabic first, explaining what you collect, why, who you share it with, how long you keep it and how people can exercise their rights. Keep marketing consent separate, unticked by default and easy to withdraw.
Core technical controls for website and app security
Access control and MFA
One account per person, permissions by role, and a quarterly review to remove access for leavers and people who changed roles. Turn on MFA for the admin panel, hosting, email, code repository and DNS provider; these are the most targeted doors.
Encryption in transit and at rest
HTTPS is mandatory on every page and API, with modern TLS settings. At rest, encrypt databases, disks and backups, and hash passwords with algorithms designed for the job rather than reversible encryption.
Secrets management
Keys for payment gateways, messaging services and databases belong in a secrets vault or protected environment variables, not in configuration files inside the repository. If a key leaks even once, rotate it immediately; deleting it from the code is not enough.
Secure coding and the OWASP Top 10
The OWASP Top 10 is the global reference for the most common web application risks, with categories such as broken access control, injection, security misconfiguration and vulnerable or outdated components. Make it part of code review and acceptance criteria, and add automated code and dependency scanning to the deployment pipeline.
Dependency updates
A large share of the vulnerabilities we come across starts with an outdated plugin or an unpatched library. Set a monthly update window, and handle critical security patches within days, not months.
Practical tip: never try updates directly in production. A matching staging environment and basic automated tests turn regular patching into a safe habit instead of a risk the team keeps postponing.
Resilience and incident readiness
Backups and restore tests
Follow the 3-2-1 rule, keep one isolated copy that cannot be modified, and test full restores regularly. A backup that has never been restored is a promise, not a guarantee.
Logging and monitoring
Log sign-ins, permission changes, access to sensitive data and unusual errors, and collect them centrally where an attacker cannot easily wipe them. Keep personal data and passwords out of the logs themselves.
Incident response and breach notification readiness
A 72-hour window is very short if you only start thinking after the incident. Decide in advance who leads the response, who determines whether an event is a notifiable breach, who contacts SDAIA and customers, the message templates and the containment steps. Then rehearse at least one scenario a year.
Security is not a project that ends at launch; it is an operating habit: regular patching, alert monitoring and tested restores.
Vendors, processors and penetration testing before launch
Every provider that touches your customers’ data, from hosting to messaging tools and customer-service platforms, extends your responsibility. Ask for contracts that define the purpose of processing, where the data is stored, security obligations, how quickly they must tell you about an incident, and deletion of data when the contract ends.
Before launching any new website or app, commission software testing that includes an independent penetration test, close every critical and high finding before go-live, and retest after major changes. If your data needs stronger isolation or in-Kingdom hosting, consider private servers configured for your compliance requirements.
How do you verify each control?
| Control | What it protects | How to verify |
|---|---|---|
| Data inventory and minimisation | Limits the damage of any breach | An up-to-date register of every form and integration, with a six-monthly field review |
| Privacy notice and consent | Data-subject rights and the lawful basis for processing | Review the page and forms, and actually test withdrawing consent |
| MFA and least privilege | Admin accounts against takeover and misuse | A report of accounts without MFA and a quarterly access review |
| Encryption | Data in transit and at rest | Scan TLS settings and confirm databases and backups are encrypted |
| Secrets management | Payment and service keys against leaks | Automated repository scanning for exposed secrets |
| Secure coding and dependency updates | The application against known vulnerabilities | Dependency scanning in the pipeline and code review before merge |
| Backups | Business continuity after failure or ransomware | A restore-test record with the real time taken |
| Logging and monitoring | Your ability to detect an incident early | A test alert that reaches the owner within minutes |
| Incident response plan | Meeting the notification deadline and limiting harm | An annual tabletop exercise and a plan update afterwards |
| Penetration testing | The product before attackers get to it | An independent report, fixes closed and a retest |
You do not need to do everything in a week. Start with three: MFA on every admin account, a tested backup restore and a data inventory. Then work through the rest over a quarter. At True Ventures, our server management team handles patching, monitoring, backups and hardening on an ongoing basis, and we can review your current setup against this checklist. Get in touch to start with a practical assessment of your website or app.
أسئلة وأجوبة
01Does the PDPL apply to small businesses?
Yes. The law does not exempt companies by size; any organisation processing personal data of individuals in Saudi Arabia is covered, even a small online store collecting names, mobile numbers and addresses. Some detailed obligations may vary with the nature and scale of processing, so check the official text and your legal adviser to confirm what applies to you.
02What is the PDPL breach notification deadline?
The PDPL implementing regulations require notifying SDAIA within 72 hours of becoming aware of a breach that may harm the data or the individuals concerned, and informing affected individuals without undue delay where harm is likely. Because the window is short, your response plan, roles and message templates need to be ready before anything happens.
03Can customer data be hosted outside Saudi Arabia?
Transferring personal data outside the Kingdom is not banned outright, but it is restricted to conditions set by the law and a dedicated transfer regulation, and some sectors add their own requirements. Before choosing a hosting or cloud provider, confirm where data is stored and processed, and ask legal counsel to assess your specific situation.
04How often should a website or app be penetration tested?
A practical rule: before launch, after every major change to architecture, permissions or payments, and at least once a year for products that handle sensitive data or payments. Between tests, automated vulnerability and dependency scanning covers part of the risk, but it does not replace an independent manual test.
05How is the PDPL different from NCA cybersecurity controls?
The PDPL focuses on individuals' rights and how their personal data is collected and processed, and SDAIA oversees it. NCA controls focus on protecting systems and networks; they are mandatory for specific entities such as government bodies and critical infrastructure operators, and a useful reference for everyone else.
حوّل هذا الدليل إلى خطة.
أخبرنا أين تقف اليوم، وسيرسم فريقنا معك الخطوات التالية — بدءًا من Server management.
الطريقة الأسرع
عندك سؤال؟ اسألنا على الواتساب.
أخبرنا بما تخطط له وسيوجهك فريقنا إلى الشخص المناسب — دون تعبئة أي نموذج.
نرد عادةً خلال دقائق في أوقات العمل.
More guides for you
كل الأدلة
Cloud Hosting vs Dedicated Server: Which One Fits Your Business?A practical decision guide to cloud hosting vs a dedicated server: traffic patterns, performance, control, Saudi data residency, total cost, backups and migration steps.
تصميم موقع طبي احترافي: من أول زيارة إلى حجز الخدمةهل يصل المريض إلى خدمتك بسهولة عندما يبحث عنها؟ تصميم موقع طبي احترافي يعرّف الناس بعيادتك، يسهّل اختيار الخدمة والحجز، ويمنح مشروعك حضورًا رقميًا جديرًا بالثقة. ما المقصود بتصميم موقع طبي؟ تصميم موقع طبي هو بناء تجربة…
ما هو السيو التقني؟ دليلك لتحسين موقعك وتصدر نتائج البحثقد تمتلك محتوى ممتازًا وتصميمًا جذابًا، لكن الأخطاء التقنية قد تمنع موقعك من الظهور. فما هو السيو التقني، وكيف يساعدك على الوصول إلى عملائك؟