Saudi Arabia's data regulator wants to change the rules again. SDAIA has put draft amendments to the Implementing Regulations of the Personal Data Protection Law (PDPL) on the Istitlaa public consultation platform, and the official gazette Umm Al-Qura reports that comments close on 5 November 2026. The gazette item is one line about the goal: clearer procedures so that the people and companies covered by the law can actually comply.
The detail is in a Clyde & Co note of 8 October that walks through the draft article by article. Three of the changes land straight on the systems that hold the most personal data in a typical company and get the least attention: the help desk and the mail server.
What the draft changes
All of this is a draft. It can change after the consultation, and Clyde & Co says it would take effect 60 days after publication in the Official Gazette if adopted. The points that matter for IT and support teams, as summarised in that note:
| Topic | Draft rule |
|---|---|
| Storage (Art. 23) | Controllers store personal data inside the Kingdom. Transfers and disclosures abroad stay possible under the PDPL's existing transfer rules. |
| Breach notice to SDAIA (Art. 24) | Within 72 hours of becoming aware of a breach, damage or unauthorised access, whether or not harm is likely. Telling the affected people still depends on a damage assessment. |
| Requests from SDAIA (new Art. 36) | Answer within 20 business days of receipt. SDAIA may extend if you justify it. |
| Data subject requests (Art. 3) | No answer within the 30-day period means the request counts as rejected, and the person can complain to SDAIA. |
| National Register of Controllers (Art. 34) | Registration becomes mandatory for public entities, controllers whose core activity is processing personal data, anyone processing sensitive data, and anyone transferring data outside the Kingdom. |
| Marketing (Arts. 28, 29) | Keep evidence of consent, offer a clear way to withdraw it, and on withdrawal stop the processing and destroy the data without undue delay. |
Local storage: where is the primary copy of your tickets?
We went through the current transfer article in our earlier piece on help desk data residency under the UAE and Saudi laws. The short version was that hosting tickets abroad was allowed with paperwork. The draft flips the default. Storage in the Kingdom becomes the rule and the transfer mechanisms become the exception you have to justify.
For a SaaS help desk hosted in Frankfurt or Virginia, that raises a plain question your vendor should be able to answer in one email: is there a Saudi region, and does the attachment store live there too, or only the database? Attachments are where the national ID scans and medical notes sit. The same question applies to mailboxes, backups and the search index that a mail or ticket system builds on the side.
The 72-hour clock with no harm test
Today a controller decides whether a breach is likely to cause harm before it has to tell SDAIA. The draft drops that test for the regulator notice. Someone signing into a support agent's account from an unknown country and reading tickets for an afternoon would count, whether or not anything was copied out.
The hard part of 72 hours is rarely writing the notice. It is answering "what did they see?" fast enough. That needs three things most teams find missing on the day:
- An access log on tickets and mailboxes that records reads, not only edits, and that you can query by account and time range.
- A named person who owns the notice. The draft also widens the data protection officer role and puts breach notifications on the DPO's list.
- A decision, made in advance, about who can see which queues. A help desk where every agent can open every ticket turns a single stolen password into a breach of the whole archive.
Deadlines your support queue will have to keep
Two of the new time limits are queue problems more than legal ones. A data subject request that sits unanswered for 30 days is deemed rejected, and an SDAIA request needs an answer in 20 business days. If those requests arrive by email to a shared inbox, they will get lost behind delivery complaints. Give them their own request type, an owner, and a due date counted in working days on the Saudi calendar, so the Friday and Saturday weekend and public holidays are handled for you.
The marketing changes point the same way. "We have a prior relationship" stops being enough on its own; you need to show the consent and honour a withdrawal by deleting the data, which means the newsletter list and the CRM have to agree about who said no.
What to do before 5 November
- Read the draft on Istitlaa and send comments if a clause would break how you work. This is the stage where that is cheap.
- List every system that stores personal data about people in the Kingdom and where its primary copy, attachments and backups physically sit.
- Check whether your ticket and mail systems log reads, and test pulling one account's activity for a given day.
- Set up a request type for data subject and regulator requests with business-day due dates.
- Check whether you fall into one of the registration groups, especially if any data leaves the Kingdom.
Our own position: if storing in-country becomes the rule, the simplest help desk to defend is one that runs on a server you choose. FanDesk is self-hostable with Docker and computes SLA due dates against a real working calendar, which covers the business-day deadlines above. It does not make anyone compliant by itself; the logging, access rules and DPO work are still yours. The same reasoning is why many teams keep mail on their own servers, as we wrote in why self-hosted email still makes sense in 2026.
This is not legal advice. For your own case, ask counsel who works with the PDPL every day.
Frequently asked questions
Are the PDPL amendments in force?
No. They are a draft under public consultation on Istitlaa until 5 November 2026, per Umm Al-Qura. If adopted, they would take effect 60 days after publication in the Official Gazette, according to Clyde & Co.
Does the draft ban storing Saudi personal data abroad?
It makes storage inside the Kingdom the rule, while transfers and disclosures abroad remain possible under the PDPL and its existing transfer mechanisms. Expect to document why each foreign copy exists.
What breaches would have to be reported within 72 hours?
Under the draft, any breach, damage or unauthorised access must be reported to SDAIA within 72 hours of awareness, whether or not harm is likely. Telling the affected individuals still depends on an assessment of damage.
How does this affect a help desk?
Tickets often carry ID scans, phone numbers and health notes, so the help desk falls under all three main changes: where the data is stored, how fast you can report unauthorised access, and the 30-day and 20-business-day response limits.