Most PDPL projects stall because nobody knows where the data is.

You cannot protect, restrict, transfer lawfully or delete on request data you cannot locate. Almost every stalled compliance programme we see is stalled here.

What we actually produce

• An inventory of every system, database, share and export that holds personal data.
• The personal data categories in each, with the sensitive ones marked.
• Where each dataset came from, where it goes, and who can reach it.
• A records-of-processing register you can hand to a regulator.
• The copies nobody remembered: spreadsheets on shared drives, old backups, test databases seeded with production records.

That last line is usually the uncomfortable one. It is also the reason a policy-only engagement leaves you exposed.

This is the part the compliance market mostly does not sell. We come in and do the work.

The work

• Deduplicate and reconcile records so one person is one record, not nine.
• Fix the structural problems that make compliance impossible: no retention field, no consent source, no lawful-basis column, free-text fields holding identifiers.
• Classify and label datasets so access rules can actually be applied to them.
• Apply retention and deletion to data you have no further reason to hold.
• Separate production from test and staging, and purge production records out of the environments that should never have had them.
• Remove personal data from logs, exports, caches and reporting extracts.

Every deletion and change is recorded, so the work itself is auditable. We do not quietly drop records.

Once the data is understood and clean, it often needs to move. A dataset that cannot lawfully sit where it currently sits is a finding you fix by relocating it, not by documenting it.

What migration involves

• Moving datasets into systems and regions that match their data class.
• Bringing processing in-country where cross-border transfer cannot be justified.
• Rebuilding integrations so they stop copying personal data into places it should not reach.
• Validating row counts, integrity and access control after the move, not before.
• Decommissioning the old copy, with evidence that it is gone.

We have done this work on live systems for healthcare, compliance and trading clients, which is where our caution about cutovers comes from.

If you have deployed anything AI-assisted, the compliance gap is rarely the model. It is everything around it, and it is rarely in anyone's data map.

Routinely missed

• Prompts, and the document chunks assembled into them.
• Vector stores and embeddings derived from personal records.
• Inference logs and tracing tools, which often capture full payloads by default.
• Cached and memoised responses, including at a gateway or CDN.
• Evaluation sets and fine-tuning corpora built from production traffic.
• Human review queues, where staff see records they could not otherwise open.

A useful test: ask your team for the retention period on prompt logs. If nobody can answer within a day, those logs are uninventoried and probably unbounded.

Articles 22 and 23 of the PDPL govern moving personal data outside the UAE. Article 22 permits transfer to jurisdictions judged to have adequate protection. Article 23 covers everywhere else and narrows you to specific grounds: contractual necessity, explicit consent, international judicial cooperation, or public interest.

Read that against a system you intend to run for years. Consent is revocable. Contractual necessity is a stretch for an internal tool. Neither is a comfortable foundation.

Keeping the data and the processing in-country does not give you a better answer to the transfer question. It removes the question. Where that is the right call, we build it that way.

Related obligations we scope with you

• Article 21: a documented impact assessment before high-risk processing begins.
• Article 18: a right to object to decisions made by automated processing.
• Article 10: whether your organisation needs a Data Protection Officer.

Discovery first, because everything else is guesswork without it.

Typical sequence

1. Discovery and mapping across systems, with the register as the deliverable.
2. A findings review: what is lawful today, what is not, and what cannot stay where it is.
3. Cleanup and remediation, prioritised by risk rather than by ease.
4. Migration, where a dataset needs a different home.
5. Handover: the register, the evidence trail, and the controls your team operates from here.

What we do not do

We are not your lawyers and we do not certify you. We do the data and engineering work, and we document it so your counsel and your assessors can rely on it. Where something is a legal judgement, we will say so and tell you to get it.