A support ticket looks harmless. It is a subject line, a few messages and maybe a screenshot. But open a typical help desk in a Gulf company and you will find national ID scans attached to account recovery requests, phone numbers and home addresses in delivery complaints, salary questions in HR tickets and medical notes in leave requests. A help desk is one of the largest stores of personal data a company runs, and it usually gets less attention than the CRM or the ERP.
That matters because both the UAE and Saudi Arabia now have national personal data protection laws, and both say something about where personal data may go. This piece looks at what the two laws actually say on the points that affect a help desk, then turns that into a short list of decisions for whoever runs support. It is written for IT and support managers, not lawyers, and it is not legal advice; for your own case, ask counsel who works with these laws every day.
The two laws in one paragraph each
UAE. Federal Decree-Law No. 45 of 2021, the Personal Data Protection Law, came into force on 2 January 2022, according to the UAE government portal. The same page summarises the main points: it applies to processing of personal data inside or outside the country, it requires consent except in defined cases, it gives people the right to correct their data and restrict processing, and it sets requirements for cross-border transfer. The UAE Data Office is the federal regulator. Financial free zones such as the DIFC have their own data protection law, so check which regime applies to each entity in your group.
Saudi Arabia. The Personal Data Protection Law was issued in September 2021 (the SDAIA data governance portal gives 16 September 2021), and Article 43 of the law set its entry into force at 720 days after publication. Article 2 applies it to processing that takes place in the Kingdom and to processing of data about people residing in the Kingdom by any party outside it. SDAIA publishes the implementing regulations and runs the national register of controllers.
What the Saudi law says about sending data abroad
This is the part most help desk buyers ask about, so it is worth reading the text rather than a summary. Article 29 allows a controller to transfer personal data outside the Kingdom for listed purposes, under conditions: the transfer must not harm national security or the Kingdom's vital interests, there must be an adequate level of protection abroad (at least equivalent to the Saudi law, according to an assessment by the competent authority), and the transfer must be limited to the minimum personal data needed. The implementing regulations fill in the details and the exceptions.
SDAIA has since published practical tools for transfers, including standard contractual clauses and binding common rules for groups of companies, and a guide on assessing the risks of transferring data outside the Kingdom.
The practical reading for a help desk: hosting tickets abroad is not banned outright, but it is a decision with paperwork attached. Someone has to be able to show which mechanism covers the transfer, and that only the necessary data goes.
Three other clauses that land on the support team
Retention. Article 18 of the Saudi law says the controller shall destroy personal data without undue delay once it is no longer needed for the purpose it was collected for, unless there is a legal basis to keep it longer or it relates to a court case. Most help desks keep every ticket and every attachment forever, because nobody ever set a rule. That default is the opposite of what the article asks for.
Breach notification. Under Article 24 of the Saudi implementing regulation, a controller has to notify the competent authority within 72 hours of becoming aware of a breach that could cause harm, with a description of the incident, the categories and approximate number of people affected, and the measures taken. You cannot write that report in 72 hours if you do not know which ticket attachments sit where.
Data subject rights. Both laws give people rights over their data, including correction. In a help desk, that means being able to find every ticket about one person, across email, web form and any other channel, and act on it. If your ticket data is spread across a shared mailbox, a chat tool and a spreadsheet, that search is the hard part.
Where help desk data actually ends up
When people talk about data residency, they usually mean the main database. In a help desk the data spreads further than that:
- Attachments stored in a separate object store, often in a different region from the database.
- Email passing through the mail provider used for ticket notifications and replies.
- Search indexes, which hold copies of ticket text.
- Backups, which keep deleted tickets alive long after the retention period.
- AI features, which may send ticket text to a model hosted elsewhere to draft replies or summarise threads.
- Integrations such as SMS gateways, chat channels and analytics tools.
A vendor's "data stored in region X" usually refers to the first item, not all six. Ask about each one separately. Attachments deserve extra care for security reasons too; we wrote about hardening attachment downloads after finding a real hole in our own product.
Six decisions for whoever runs support
- Decide where tickets live, including attachments and backups. Write it down per item from the list above. If any piece sits outside the country, name the transfer mechanism that covers it.
- Set a retention rule per ticket type. Password resets do not need to be kept for five years. HR and legal tickets may need longer. Then make sure deletion also reaches attachments and, on schedule, backups.
- Stop collecting what you do not need. If agents ask customers to "send a copy of your ID" by habit, replace it with a verification step that does not leave a scan in the ticket.
- Restrict who can see what. HR and finance tickets should not be visible to every agent. Branch and department permissions are the cheapest privacy control you have.
- Keep an audit trail. When something goes wrong, the 72-hour clock starts with the question "who accessed what". Make sure the help desk can answer it.
- Check the AI features before switching them on. Know where the model runs, whether ticket text is kept by the provider, and whether you can turn it off for sensitive queues.
Cloud, regional cloud or your own servers?
There are three honest options, and none is right for everyone.
A global SaaS help desk is the fastest to start, but you rely on transfer paperwork and on the vendor's sub-processors. A help desk hosted in a local region keeps the main data in country, but check the six items above, because email, AI and backups often still leave. Self-hosting on your own servers or a local data centre gives you full control over all six, at the cost of running it yourself. We compared the trade-offs for an internal AI assistant in on-premise versus cloud deployment, and most of that reasoning applies to a help desk as well. If you are still choosing a product, our help desk buying checklist covers the rest of the criteria.
Where FanDesk fits
FanDesk can run as a cloud service, and it can also be installed with Docker on your own infrastructure, so tickets, attachments and backups stay on servers you choose. It has branch and department permissions, an activity log, SLA rules that respect business hours, and Arabic and English interfaces with right-to-left support. If data residency is the question holding up your help desk decision, look at the FanDesk deployment options and ask us how a self-hosted install would map onto your data inventory.
