Ask a UAE business how long it keeps customer data and the honest answer is usually forever, arrived at not by decision but by never having made one.
Deleting feels risky. Keeping feels safe. So everything accumulates: the customer database from a product line discontinued six years ago, exports sitting in downloads folders, a marketing list of people who have not opened an email since 2021.
That default is itself a risk, and it is one of the few compliance areas where doing less is the improvement.
This article covers the one clear statutory anchor most UAE businesses have, how to build a retention schedule you will actually operate, and the parts that reliably get missed.
Start from the seven-year rule
The clearest requirement most UAE businesses face comes from the Federal Tax Authority.
Taxable persons and exempt persons must retain relevant records for at least seven years following the end of the tax period to which they relate [1][2]. That applies across VAT and corporate tax obligations administered by the FTA.
What that covers is broadly everything supporting what you told the authority: records of transactions in the tax period, records of assets including purchases and disposals, records of liabilities, and other supporting documentation behind the figures in your returns. The stated purpose is to enable the authority to verify your taxable income [2][3].
This is a useful anchor because it is concrete, and it is also the source of the most common mistake in the whole subject.
Seven years is a tax record requirement. It is not the answer for everything.
Marketing contacts are not tax records. Website analytics are not tax records. Support conversations, old job applications and abandoned product databases are not tax records. Conflating the two is the single most common reason businesses keep everything indefinitely, and it is a misreading rather than a legal obligation.
Confirm the current position and how it applies to your entity with the Federal Tax Authority or your tax adviser, since requirements are amended and the detail matters more than a summary.
Why holding everything is the risk
The instinct runs the other way, so it is worth setting out the argument plainly.
Every record you hold is:
- Something you must secure
- Something that appears in a breach if one occurs
- Something to search when somebody makes a request about their data
- Something to justify if anybody asks why you still have it
- Something to migrate every time you change systems
Data you no longer need carries all of those costs and returns nothing.
A customer database from a discontinued product cannot help you. It can absolutely harm you, because a breach of it is a breach of real people's information about a relationship that ended years ago, and you will be asked why you still had it.
Most businesses are heavily exposed in that direction and worried exclusively about the opposite one, which is deleting something they needed. Both risks are real. Only one of them is usually being managed.
The two ways this goes wrong
Retention failures run in opposite directions and businesses are almost always exposed in one of them while worrying exclusively about the other.
Deleting something you were required to keep. The authority asks for records supporting a return from four years ago and they are gone, because a system was decommissioned and nobody checked what was in it first. This is the risk everybody fears, it is real, and it is comparatively rare, because the records that carry statutory retention are usually the ones sitting in accounting systems that nobody deletes casually.
Holding data you have no reason to hold. A breach exposes customer records from a product line closed in 2019. A subject request arrives and you spend two weeks finding every copy. A due diligence process asks what personal data you process and the honest answer involves several systems nobody can fully describe.
This second category is where most businesses actually sit, and it accumulates silently. No single decision created it. A system was replaced and the old one kept "just in case". An export was made for a board meeting and never removed. A marketing list was imported from an event four years ago and merged with everything else.
The asymmetry in attention is worth noticing, because the effort you put into avoiding the first risk is often what created the second one. "Keep everything, it is safer" is a policy that manages one exposure by maximising the other, and almost nobody states it that plainly.
Build the inventory first
You cannot write a retention schedule for data you have not located, and most businesses have never made the list.
For each system: what categories of data sit in it, roughly how far back, and who owns it.
Include the awkward ones. Your main platform and your accounting system are easy. The list that matters also has your email, your support tool, your CRM, your marketing platform, your file storage, your backups, and the spreadsheets on individual laptops.
This is the same starting point as security asset inventory and shadow IT discovery, and if you have done either of those you already have most of it. Our guide on shadow IT covers finding the systems nobody told you about, which are frequently the ones holding data nobody is managing.
The schedule itself
It does not need to be elaborate. Four columns:
| Data type | Keep for | Why | Then |
|---|---|---|---|
| Financial and tax records | 7 years after the tax period | FTA requirement | Archive, restricted access |
| Signed contracts | Term plus claim window | Legal exposure | Archive |
| Employee records | Per labour and tax obligations | Regulatory | Archive, restricted |
| Active customer accounts | Duration of relationship | Business need | Review on closure |
| Closed customer accounts | Defined period from closure | Business need, claims | Delete or anonymise |
| Marketing contacts | Engagement-based | Business need only | Delete |
| Support conversations | Defined period | Business need | Delete or anonymise |
| Website analytics, detailed | Short | Diminishing value | Aggregate, then delete |
| Security and access logs | Longer than most operational data | Investigation value | Delete |
| Backups | Weeks, not years | Recovery need | Rotate out |
Keep the categories coarse. Eight to fifteen covers most businesses. Splitting into fifty produces a document nobody maintains, which is worse than a coarse one that stays current.
Write the reason, not just the period. Every period should rest on one of three things: a legal or regulatory requirement, a limitation window in which a claim could arise, or a genuine business need. If a number has none of the three behind it, somebody picked it rather than deciding it, and it will not survive being questioned.
What a first schedule looks like in practice
To make this concrete, here is roughly what a small services business ends up with after an afternoon of work. Yours will differ; the shape is the point.
Financial and tax records: seven years from the end of the tax period, because the Federal Tax Authority requires it, then archived to restricted storage rather than deleted.
Client contracts and statements of work: the term plus the window in which a claim could arise, confirmed with the lawyer rather than guessed, then archived.
Employee records: per labour and tax obligations, confirmed with the adviser, restricted access throughout because these are the most sensitive records most small businesses hold.
Active client accounts and project data: for the duration of the relationship, reviewed at closure rather than kept automatically.
Closed client accounts: a defined period from closure, then anonymised so that historical revenue analysis survives without the individuals.
Prospect and marketing contacts: deleted after a defined period without engagement, automatically where the platform supports it.
Support and enquiry conversations: a short defined period, then deleted, because their value decays quickly and they frequently contain more personal detail than anybody intended.
Website analytics: aggregate retained, event-level detail deleted after a much shorter window.
Security and access logs: retained longer than other operational data, because their value is in investigating something found late.
Backups: weeks rather than years, documented, with a stated rule that deleted records are not restored from them.
Ten lines. Each with a period and a reason. That fits on one page, it can be written in an afternoon by somebody who knows the business, and it is dramatically more than most companies have.
The parts everyone misses
Backups. The most common gap and the most awkward. Data deleted from a live system persists in backups until those rotate out, which may be months.
The workable approach is a documented backup retention period, a statement that data is removed from live systems immediately and from backups within that window, and a rule that you do not restore deleted records from backup.
While you are looking: check what your backup retention is actually set to. It is frequently far longer than anybody intended, because it is a setting somebody configured once and nobody has revisited. Very long backup retention is almost always accidental rather than chosen.
Third-party systems. Your obligations follow the data rather than stopping at your own servers. Your CRM, support tool and email platform all hold personal data, and their retention settings are part of your schedule. Check what each is configured to do, because the default is frequently to keep everything indefinitely, which suits the vendor and not you.
Supplier exit. Settle in the contract how long a provider retains your data after termination, whether they delete on request, and whether you can export everything first. Our guide on getting your data out covers testing that export, which is the part businesses discover is broken at the worst possible moment.
Personal devices and laptops. The hardest part of any retention programme and where schedules quietly fail. Spreadsheets downloaded for a report, contracts saved to a desktop, exports in a downloads folder. Reduce it by making the central system easier to use than exporting, and address it explicitly in the policy rather than pretending it does not happen.
Delete, anonymise, or archive
Three endings, chosen deliberately rather than defaulting to the first or to nothing at all.
Delete where you have no continuing reason to hold it.
Anonymise where you want the aggregate and not the individuals. This is genuinely useful for analytics and it is under-used, because deletion feels more definitive. The caution is that anonymisation is a technical exercise rather than a label. Removing a name while leaving a customer number, a postcode and a purchase date is frequently enough to re-identify somebody. If you claim data is anonymised, it should genuinely not be linkable back by you or anybody else.
Archive where you must retain but do not need routine access. Move it somewhere with restricted access rather than leaving it in the live system where everybody can see it. Tax records are the obvious case: you must keep them and almost nobody needs to open them.
Specific categories worth thinking about
Marketing contacts usually need the shortest period and get the least attention. Somebody who has not opened anything in three years is not an asset, they are an unsubscribe link waiting to happen. Setting an engagement-based expiry reduces what you hold and improves your deliverability, which makes it one of the easier changes to justify to whoever will resist it.
Website analytics age badly. Product changes make old behaviour incomparable, and nobody analyses individual sessions from four years ago. Keep aggregate trends indefinitely if you like, and detailed event-level records for far less. Our guide on product analytics covers what is worth collecting in the first place.
Security and access logs are the exception that argues for longer retention. Their value is in investigating something discovered late, and an incident found in month six is much easier to investigate with six months of logs than with thirty days. Be explicit that this category has a different justification from the rest.
Customer personal data resists a single number. Define what makes a record active, and set a period running from the end of the relationship rather than from its start. A customer who bought once five years ago and a customer with an active subscription are not the same case and should not share a rule.
Deletion requests, and being able to answer
Rights to request deletion exist in data protection regimes generally. The position in the UAE is a legal question for your adviser rather than one we would answer definitively, and our guide on PDPL compliance covers the framework.
What matters practically, and is entirely within your control, is being able to respond at all.
Personal data about one individual is rarely in one place. It is in your main platform, your email, your support tool, your marketing system, your backups, and frequently a spreadsheet somebody made for a meeting.
Map those locations in advance. Doing it under a deadline with a named individual waiting is considerably harder than doing it on a quiet afternoon, and the businesses that struggle are not the ones with unclear obligations but the ones that cannot find their own data.
On conflicts: a legal obligation to retain is itself a justification for holding data, so genuine tensions are rarer than feared. Where one exists, such as a deletion request touching records you must keep for tax, the usual approach is to retain the minimum required and restrict its use to that purpose. Take advice on the specific case.
Making it actually happen
The most common failure in this entire area is writing the schedule and never applying it. The document exists, it is accurate, it is filed, and not one system behaves differently.
Plan against that explicitly.
Automate what you can. Many systems support automatic deletion after a set period. Turning that on for the categories where it fits removes reliance on anybody remembering, which is the only mechanism that survives contact with a busy year.
Diarise the rest, attached to something already in the calendar.
Start with two or three categories rather than all of them. A one-page table covering eight to twelve categories, with automatic deletion implemented for the two or three where your systems support it, is a week of work and dramatically better than the comprehensive version you will not finish.
Give it to the right owner. Finance, legal or operations rather than IT, because the decisions are about obligations and business need. IT executes the deletion. When IT owns the whole thing, periods get chosen for technical convenience, which is how businesses end up either keeping everything or deleting something they needed.
Review annually, and whenever you adopt a significant new system. A schedule untouched for three years describes a business that no longer exists and provides false comfort rather than protection.
Where retention meets everything else
Retention is not a standalone compliance exercise, and treating it as one is why it usually stalls. It sits at the intersection of four things you are probably already doing.
Security. Every framework asks what data you hold and where. A retention schedule is largely the same inventory viewed through a different lens, so if you have done asset discovery for security reasons you have already paid for most of the work.
Data protection. Holding data only as long as you have a reason for it is a core principle rather than an optional refinement. A retention schedule is how that principle becomes something a business actually does rather than something a policy says.
Supplier management. What each vendor retains, for how long, and what happens at termination belongs in your contracts. Most agreements are silent on it, which means the default is whatever the vendor finds convenient.
Storage cost and system migrations. The commercial argument nobody makes. Every migration costs more when you are moving fifteen years of data instead of three, and every backup is larger. That is a small number annually and a real one when you next replace a system.
The practical implication is that you should not run this as a separate programme with its own meetings. Attach it to work already happening. The inventory comes from your security or shadow IT work. The vendor terms go into your normal contract reviews. The schedule review sits alongside an existing annual process.
Businesses that build a standalone retention project produce a document. Businesses that attach it to existing work produce changed system settings, which is the only outcome that matters.
Two things this week
Check your backup retention setting. Not what you think it is, what it actually says. It is frequently years when somebody intended weeks, and nobody has looked since it was configured.
Delete everybody from your marketing list who has not engaged in three years. Under an hour, reduces real exposure, and improves your email deliverability as a side effect, which makes it the rare compliance action with an immediate commercial benefit.
Neither requires a policy, a project, a budget or anybody's approval. Both are strictly better than the position you are in now, and both can be finished before lunch by one person who knows where the settings live.
If you want the fuller version, mapping what data sits where, checking what your systems are configured to retain, and drafting a schedule your business can actually operate starts from around AED 2,500 with us. Implementing automated deletion is priced separately by scope. Final pricing depends on scope, and these are our own figures rather than a market survey.
The parts that turn on legal obligation, including how long to keep employment records and what a specific deletion request requires of you, belong with a qualified adviser rather than with us, and we would say so at the outset.
References
- Federal Tax Authority, retaining records
- Federal Tax Authority, Cabinet Decision No. 74 of 2023 on the Executive Regulation of Federal Decree-Law on Tax Procedures
- Federal Tax Authority, tax invoices
- UAE Government, data protection laws
- SKIMBOX, PDPL compliance in the UAE
- SKIMBOX, getting your data out
- SKIMBOX, shadow IT: the tools your team bought
- SKIMBOX, UAE e-invoicing guide
- SKIMBOX, product analytics and event tracking
- SKIMBOX, document management and going paperless in the UAE
Retention requirements are set by the relevant authority and change over time. Confirm your own obligations with the Federal Tax Authority, MOHRE where employment records are concerned, and a qualified adviser. This article is not legal or tax advice.
