Deletion concepts in shops: implementing retention periods

An online shop takes in data faster than it lets go of it. Orders, invoices, return slips, support threads, newsletter sign-ups, server logs - every trace has a reason for existing and a point at which it has to disappear. A deletion concept records both: which type of data is needed for how long, when the period starts and what happens afterwards. It is the operating manual for the deletion run that passes through the database at night, not paperwork for a drawer. Without it, every deletion question is decided one at a time - which in practice means not at all. Our own processing is set out in the privacy notice.

Deleting is a duty, not a courtesy

The General Data Protection Regulation contains no table of periods, only a principle: personal data may be kept in identifiable form only as long as the purpose requires. The practical work follows from that. Whoever wants to know when a record has to go must first know why it was collected and when that purpose ends. Only then comes the second question: whether a statutory retention duty blocks deletion.

The fine framework separates two levels. Infringements of the processing principles - storage limitation among them - sit in the upper tier of up to 20 million euros or 4 percent of total worldwide annual turnover (GDPR). Missing technical and organisational measures, such as a deletion routine planned but not built, sit in the lower tier of up to 10 million euros or 2 percent (GDPR). Without a concept, both are at risk at once.

How expensive that becomes is documented in a case that travelled to the Court of Justice of the European Union and back. In 2019 the supervisory authority fined a housing company 14,385,000 euros (EuGH) for running an archive system from which data no longer needed could not be removed. Fifteen further fines of 3,000 to 17,000 euros (EuGH) followed - each record kept too long was a separate infringement. That penalty notice did not become final, however: the company appealed, and after the Court of Justice ruling the Regional Court of Berlin I reduced the fine to 900,000 euros on 9 June 2026 (Landgericht Berlin). That judgment is not final either; it can still be challenged on points of law (Landgericht Berlin). Anyone quoting the figure therefore typically gives both stages. The case remains instructive whatever the amount, because the company had not misused the data. It had merely kept it - and has been before the courts over it since the 2019 notice.

Deletion is therefore not a favour to the customer but a duty that exists without any request. That is what separates the deletion concept from the access process: it runs without a trigger and has to be able to show that it ran.

The periods that set the frame

Before anything is deleted, check whether a provision requires it to be kept. For an online shop seven provisions carry most of the weight, each with a different number. Keeping those numbers apart is half the way to a working concept.

Section 257 of the German Commercial Code requires commercial books, inventories, opening balance sheets and annual accounts to be kept for ten years (HGB). Commercial letters received and sent - order confirmations and customer correspondence - fall under the six-year period (HGB) of the same provision. An order splits into two periods even though the shop treats it as one transaction.

For tax purposes section 147 of the German Fiscal Code applies. It sets eight years for accounting records (Abgabenordnung) - a figure many legacy rules still put at ten. Section 14b of the German VAT Act likewise requires invoices and invoice copies to be kept for eight years (UStG). That is the hard floor at the order archive: if the invoice record leaves the shop, it has to exist elsewhere. The document chain for electronic invoices is covered in our article on e-invoicing requirements for online shops, the special cases around corrections in the article on credit notes and cancellation invoices.

Three more provisions arrive with certain business. Anti-money-laundering records have to be kept for five years (GwG); the same provision orders that they be destroyed after ten years at the latest (GwG) - a statute mandating deletion rather than permitting it. Payroll accounts run until the end of the sixth calendar year following the last entry of a wage payment (EStG), so personnel data needs its own class. Product liability claims expire ten years after the product was put into circulation (ProdHaftG), the ceiling for batch and delivery data described in the article on tracking batches and serial numbers.

Civil limitation supplies the seventh argument and is the one most often overlooked. The standard limitation period is three years (BGB); for that long a customer can bring claims from the purchase contract, and the merchant may hold the documents for legal defence. Section 199 of the German Civil Code caps it: other claims become time-barred irrespective of knowledge ten years from the date on which they arose (BGB).

The table looks tidy and stops being tidy the moment a record falls under several rows. An order is at once a commercial letter, an accounting record and a contract document. The longest applicable period then governs the whole record, not individual fields. Deleting more finely means separating the fields beforehand - exactly the work a deletion concept does.

The start of the period is the usual mistake

Periods do not start on the day of the order. Commercial and tax retention periods begin at the end of the calendar year in which the document arose. An invoice dated 3 February 2026 starts its period on 31 December 2026. Entering the order date as the start deletes up to eleven months too early - and the mistake stays visible under review, because the record was removed as planned.

A running period can also be held while the tax assessment period is still open. For evaded tax it is ten years (Abgabenordnung), for reckless understatement five. For the deletion run that means an audit, an investigation or a live dispute has to be able to halt the run for the affected records. A concept without that switch either deletes too early or, out of caution, not at all.

In practice the database needs two fields per record: the start of the period as a date, and a restriction flag with reason and responsible role. Both are set when the record is created, not computed at deletion time. Deriving the start during the run means every change to the derivation logic gives a different result - and no evidence of which one applied.

<?php
// Löschklassen: Frist, Fristbeginn, Umsetzung, führendes System.
// Der Fristbeginn ist ein Datumsfeld im Datensatz, keine Rechenregel im Lauf.
return [
    'bestellung_beleg' => [
        'frist_jahre' => 8, // § 147 AO, § 14b UStG
        'fristbeginn' => 'ende_kalenderjahr_rechnung',
        'umsetzung' => 'anonymisieren',
        'fuehrend' => 'shop',
        'sperrbar' => true, // Betriebsprüfung
    ],
    'handelsbrief' => [
        'frist_jahre' => 6, // § 257 HGB
        'fristbeginn' => 'ende_kalenderjahr_versand',
        'umsetzung' => 'loeschen',
        'fuehrend' => 'shop',
        'sperrbar' => true,
    ],
    'konto_ohne_bestellung' => [
        'frist_monate' => 24, // Zweckfortfall, keine Aufbewahrungspflicht
        'fristbeginn' => 'letzte_anmeldung',
        'umsetzung' => 'loeschen',
        'fuehrend' => 'shop',
        'sperrbar' => false,
    ],
    'support_vorgang' => [
        'frist_jahre' => 3, // § 195 BGB
        'fristbeginn' => 'abschluss_vorgang',
        'umsetzung' => 'anonymisieren',
        'fuehrend' => 'ticketsystem',
        'sperrbar' => true,
    ],
];

From the table to deletion classes

A deletion concept that starts from a list of all database tables does not get finished. Starting from the processing activity is shorter: which operations exist, which data arises, which purpose carries it? From that angle most shops end up with seven to twelve deletion classes - a number that still holds after the next system change.

Each class gets four entries: purpose and legal basis, retention period with its start, method - delete, anonymise or restrict - and the leading system. The last entry is where most concepts fall apart, because the same record sits in four places and nobody has settled who deletes first and who follows.

Where the copies live

The deletion run in the shop database is the easy part. The laborious part is the list of places where the same record appears again: search index, cache, ERP, accounting, handover files for the carrier, support mailbox, newsletter list, reporting database, point-of-sale system, backups. Every location needs its own line, even where the line ends in a decision not to delete - but then with a reason.

Backups are the special case that stalls the discussion. Editing individual rows inside a backup makes it worthless as a restore point. The workable route is two commitments: backups have a limited retention time after which they expire completely, and after a restore the deletion run is triggered again before public service resumes. Both belong in writing in the concept and in the hosting and maintenance agreement.

The second special case is the point-of-sale system in a physical store. If stock and receipts move between till and shop, customer data moves with them - and the deletion run does not reach the till on its own. Setting that handover up cleanly is described in the article on connecting a POS system to the online shop.

A dry run that only counts is the cheapest route to a concept that holds. Before the first live run it shows how many records are due per class. If one class jumps into the hundreds of thousands, the start of the period is usually wrong - not the period.

Delete, restrict, anonymise

Deletion is not the only method, and for a shop rarely the first. Three routes are available, each with its own legal effect and its own technical price.

1. Deletion removes the record. Clean, but possible only where neither a retention duty nor a reference stands in the way. Foreign keys on order line items make removing a customer record all but impossible while the order has to stay.
2. Anonymisation severs the link to the person and leaves the structure standing. Revenue statistics stay computable, the person is no longer identifiable. The standard is strict: if order date, postcode and basket narrow the field back to one person, it is pseudonymisation with extra steps.
3. Restriction of processing freezes the record. It stays present but is excluded from every normal operation - no mailing, no reporting, no back-office display. For data that exists only because of a retention duty, that is the correct state.

The third variant is the one most often missing in a shop. A customer asks for their account to be deleted, but the invoices have to stay another eight years. The right answer: account, profile and marketing data go, the record data moves into a restricted pool no running process reads. The two convenient answers - delete everything or keep everything - are both wrong.

The erasure request from the customer account

Alongside the scheduled run there is the individual case: a customer asks for erasure. The controller has to inform them without undue delay and in any event within one month of receipt of the request about the measures taken (GDPR). The clock starts on receipt - not on internal assignment.

The period may be extended by a further two months where the complexity and number of requests make that necessary (GDPR). That is an exception carrying a duty to explain it to the data subject, not a buffer for the holiday season.

Supervisory figures show that erasure requests have become routine. In 2025 the Bavarian Data Protection Authority received 9,746 complaints and requests for investigation (BayLDA), an increase of 61 percent on the previous year (BayLDA), the largest share from internet and digital services, at 21 percent (BayLDA). In Berlin, 8,436 submissions arrived between January and the end of November 2025 (BlnBDI), among them 5,772 enquiries from data subjects seeking advice on asserting access or erasure (BlnBDI).

Counting on an unanswered request to fade away underestimates the processing speed. The Bavarian authority closed 62 percent of the formal complaints concluded in 2025 within three months (BayLDA). At federal level the Federal Commissioner for Data Protection and Freedom of Information received 9,170 notifications (BfDI) and took 129 supervisory measures such as warnings, orders or penalty payments (BfDI). Supervision does not begin with the fine.

Less data, smaller damage

The deletion concept is not only a data protection duty but a security measure. A deleted record cannot leak, cannot be encrypted and cannot be published. Put the notification duties beside it: a personal data breach has to be reported to the competent supervisory authority without undue delay and where feasible within 72 hours (GDPR). In those 72 hours the scope has to be described - and the scope is whatever was sitting in the database.

How often that happens can be quantified. The Bavarian Data Protection Authority received 3,603 data breach notifications in 2025 (BayLDA). The economic frame: data theft, industrial espionage and sabotage most recently caused damage in Germany of between 211 and 270.8 billion euros (Bitkom); 45 percent of the companies surveyed were affected by digital theft of business data (Bitkom). The survey covered 1,003 companies with ten or more employees and at least one million euros in annual turnover.

For the shop that means: every class whose period has expired and is still held in full is attack surface without return. In an incident it lengthens the notification and widens the circle of people to be informed. Securing what remains is covered in the article on IT security in e-commerce.

The concept as a document

A deletion concept that exists only as code cannot be produced when it matters. It belongs as a document next to the record of processing activities, because both need the same entries: purpose, data categories, recipients, periods. The exemption from the record-keeping duty for enterprises with fewer than 250 employees (GDPR) rarely helps a shop, since it presupposes only occasional processing.

The volume in question keeps growing. German online retail turned over around 92.3 billion euros net in 2025 (HDE), with growth of 3.9 percent on the previous year (HDE), ahead of growth in physical retail. Every one of those transactions leaves an order record, an invoice, often a customer account and several log lines.

A usable document has five parts: the deletion classes, per class the period and its start with the legal basis, the system map with the leading system, the procedure for individual requests and restrictions, and the log of the runs. The last part is usually forgotten and is the only one that shows in a dispute that deletion happened. A run without a log is an assertion. How we set such concepts up with shop operators is described under consulting and concept work; our own processing is set out in the privacy policy.

Putting the deletion run into service

The route from paper to live operation is shorter than it looks, provided it is walked in the right order. Seven steps are enough for the first complete pass.

• Record the processing activities and derive the classes from them - not the other way round from the database schema.
• Fix period, legal basis and start per class, and write the start into the data as a date.
• Draw the system map: where else does the same record sit, who deletes first, who follows?
• Introduce a restriction flag so that an audit or a dispute can halt the run.
• Run a dry pass without write access and hold the counts against a prior expectation.
• Switch on the live run, write a log - and set a period for the log.
• Maintain concept and record together whenever a system is added.

A shop that knows its periods gets faster along the way: fewer records in the search index, smaller backups, shorter restore times, less effort on every access request. To hold your shop's data against the periods once, have your data reviewed - with deletion classes, a system map and a dry run that counts before it writes.