Data Protection for Software Projects: GDPR, UAE PDPL and More

If your software collects names, emails, phone numbers, locations or anything else that identifies a person, data protection law applies to it. For a business operating across borders, several laws can apply at once, depending on where your company is based and where your users live.

Retrofitting compliance after launch is slow and expensive. Designing for it from the first sprint costs little. This guide gives product owners and founders a working map of the main laws and the engineering decisions that satisfy them.

This article is general information, not legal advice. Confirm your obligations with a qualified adviser for your markets.

The laws most likely to apply

Other Gulf states, including Qatar, Bahrain and Oman, have their own data protection laws. Sector rules add further obligations: health data in the UAE, for example, is subject to separate federal rules that can require it to stay in the country.

What the laws have in common

The details differ, but the major laws share a core set of principles. Build for these and you satisfy most of any single regime.

• A lawful reason for each use of data. Consent is one reason. Performing a contract, legal obligations and legitimate interests are others, depending on the law.
• Purpose limitation. Use data only for the purposes you told people about.
• Data minimisation. Collect only what you need for those purposes.
• Retention limits. Delete data when you no longer need it.
• Security. Protect data with measures proportionate to the risk.
• Individual rights. Let people access, correct and delete their data, and in some regimes export it or object to its use.
• Breach notification. Report serious breaches to the regulator, and sometimes to the people affected. Under the GDPR, you have 72 hours to notify the regulator.
• Care with international transfers. Moving data across borders needs a legal basis, such as an adequacy decision or standard contractual clauses.

Building compliance into the software

Most compliance work is ordinary good engineering, done deliberately.

Map the data first. Before building, list every piece of personal data the system will hold, why it needs it, where it will be stored and who can see it. This map becomes the backbone of your privacy notice and your records of processing.

Minimise the forms. Every field you add is data you must protect, justify and eventually delete. Ask for a date of birth only if you need one.

Encrypt everywhere. Use TLS for data in transit and encryption at rest for databases, backups and file storage. Encrypt particularly sensitive fields separately.

Control access by role. Give each staff role the minimum access it needs, and log who viewed or changed personal records. Audit logs are invaluable when a regulator or customer asks what happened.

Automate retention. Build scheduled jobs that delete or anonymise records once their retention period ends. Manual deletion never happens reliably.

Make rights requests easy. Provide a way to export and delete a person's data from the admin panel. Requests arrive by email at the worst times, and a one-click export turns a week of work into minutes.

Record consent properly. When you rely on consent, store what the person agreed to, when and in which version of your notice. Make withdrawing consent as easy as giving it.

Choose hosting regions deliberately. Cloud providers let you keep data in specific regions, including the UAE and the EU. Decide early, because moving data later is disruptive.

Vendors and transfers

Your software almost certainly sends data to other services: hosting, email delivery, analytics, payments, customer support tools, AI models. Under most regimes, you remain responsible for what they do with it.

For each vendor, sign a data processing agreement, check where they store and process data, and keep a list of your sub-processors. When data leaves the EU or UK, confirm the transfer mechanism, usually standard contractual clauses. Your privacy notice should describe these categories of recipients.

AI features need extra care

AI features raise specific questions. Send models only the personal data a task needs, and remove identifiers where you can. Use business API terms that exclude your data from model training, and check how long the provider retains prompts. For features that make significant decisions about people, such as screening applicants, you may need a data protection impact assessment and a human review step. Our guide to agentic AI for business covers the engineering guardrails.

A checklist before launch

1. A data map listing each type of personal data, its purpose, location and retention period.
2. A privacy notice that matches what the software does.
3. A lawful reason recorded for each processing purpose, with consent capture where needed.
4. Encryption in transit and at rest, and role-based access with audit logs.
5. Working export and deletion for individual rights requests.
6. Automated retention and deletion jobs.
7. Data processing agreements with every vendor, and a sub-processor list.
8. An incident response plan that names who decides whether to notify a regulator, and how fast.
9. Hosting regions chosen to meet any residency requirements.
10. A data protection impact assessment for high-risk processing.

We design these controls into the systems we build, from custom business software to AI automation. If you are planning software that handles personal data across several markets, talk to us early. Getting the architecture right at the start is far cheaper than correcting it later.