A deletion policy that works without a data protection officer

Article 5(1)(e) GDPR requires personal data to be kept in a form permitting identification only for as long as is necessary for the purpose. That is the principle of storage limitation, and it is the one data protection duty that is breached by itself: do nothing and you breach it a little more with every day that passes.

To that add Article 5(2), accountability. You have to not only achieve compliance but be able to demonstrate it. Together those two produce exactly what a deletion policy is: a written answer to the question of when which data disappears and why. What follows is orientation — which periods apply in your market, and how they overlap in a particular case, is for your supervisory authority, your accountant or a lawyer.

Most small businesses have a de facto deletion rule; it is simply written down nowhere. Things get deleted when a system is replaced, when a folder gets too full, or when somebody expressly asks. All three triggers share the same problem — none of them has anything to do with the purpose of the data.

The purpose is the only clock the Regulation knows. Article 17(1)(a) frames it as a duty to erase: where the data is no longer necessary for the purposes for which it was collected, it is to be erased without undue delay. That duty exists whether or not anybody asks. The right to erasure is the other side of it, not the precondition.

Which is exactly why a deletion policy is not a formality but a relief. It answers once what would otherwise be argued anew in every individual case, and it can be produced on request. One page is enough. It has four columns and one row per type of data.

What does not belong in it: opinions about how long “one usually keeps that”. Every row needs a reason, and the reason is either a purpose you can name or a duty somebody can look up.

This is what the page looks like. The example rows fit a service business; the periods in the second group depend on national tax and commercial law and are deliberately left without a number here.

The third column does the work, the fourth makes the difference. A clock with no trigger never starts: “three years” only becomes a rule once it says from when. And the trigger has to be an event visible in your data — the last appointment is in the diary, whereas the end of a relationship is written nowhere. Which is why “last appointment plus period” is the more workable wording.

Somebody asks for erasure. You can delete the customer record — but not the invoices, because a tax or commercial retention period is running on them. Now what?

The Regulation anticipated this case. Article 17(3)(b) carves out of the duty to erase what is necessary for compliance with a legal obligation to which you are subject. Point (e) additionally carves out what is needed for the establishment, exercise or defence of legal claims. So the answer is not “cannot be done”, but: for that one purpose it stays, for every other it does not.

The practical name for that is restriction of processing. Article 4(3) defines it as the marking of stored data with the aim of limiting its processing in future. Recital 67 names the routes: moving it to another system, making it unavailable to users, temporarily removing it from a website — and the requirement that the restriction be unmistakably identifiable in the system.

For your business that means: the record leaves the active file. It no longer appears in the appointment search, not in the newsletter, not in the statistics. It sits in the invoice archive, accessible for the bookkeeping and for the event of an inspection, and is deleted as soon as the period has run out. That separation is the core of a deletion policy that works.

To be distinguished from that is Article 18 GDPR: there the data subject has a right to demand restriction in four named cases — for instance while it is being checked whether contested data is accurate. That is a right on the other side, not a substitute for your own duty to erase. Both use the same technical measure for different reasons.

An erasure that reaches only the main database is not one. Four places are routinely overlooked:

1. Paper. Intake forms, slips at the front desk, printed appointment lists. They are subject to the same rules and need a trigger of their own.
2. Copies in secondary systems. The newsletter list, the spreadsheet for the Christmas cards, the export somebody once pulled for a report.
3. Backups. They cannot sensibly be cleaned individually. The usual route: the erasure takes effect immediately in the live system, the backup drops out through its own retention cycle, and that cycle is named in the policy.
4. Service providers. Anyone processing on your behalf has to carry the erasure through. Article 28(3)(g) requires exactly that in the contract: delete or return after the end of the service, including existing copies.

A word on anonymisation, because it is often named as a way out. Where a record is altered so that no person can be identified any more, it is no longer personal data — the Regulation no longer applies, and analysis stays possible. That is a clean route for statistics. It does require genuine non-attributability, though; a surname removed while the customer number remains is pseudonymisation (Article 4(5)) and stays personal data.

Where invoices are archived by the system anyway, point three of that list largely takes care of itself — the workshop software, for instance, separates the job from the invoice archive rather than holding both in the same view.

A deletion policy that merely exists is a document. One that runs needs three things — and none of them is onerous.

An appointment. Once a year, ideally tied to something that happens anyway. An hour is enough: go through the rows, delete the data types that are due, note the date. That date is your evidence under Article 5(2).

A responsibility. One named person, not “the team”. In a business of five that is usually whoever also administers the software.

A rule for new arrivals. Every new type of data gets a row in the policy when it is created — not later. That is the point at which policies go stale: not through mistakes, but through new fields nobody added.

Where your software knows periods itself, use it. Automatic deletion beats a rule somebody has to remember. Where it is missing, the annual hour is the honest substitute — considerably better than the intention to “tidy up as you go”, which in practice nobody honours.