Backups are taken for granted as a technical necessity -- yet the moment they contain personal data, they enter the tension field of the GDPR. On one side, Art. 32 GDPR demands availability and recoverability of data, which is hard to achieve without backups. On the other, the storage limitation principle (Art. 5(1)(e) GDPR) and the right to erasure (Art. 17 GDPR) require that data not be kept longer than necessary. Reconciling both takes more than a backup routine: it takes a legal basis, a deletion concept and clean data processing arrangements. This guide shows how to structure the data backup of an online shop in line with current GDPR requirements -- without breaching commercial retention duties.
Legal Basis: Why a Backup Is Permitted at All
Every processing of personal data needs a legal basis under Art. 6 GDPR (EUR-Lex, Regulation 2016/679) -- and a backup is processing within the meaning of Art. 4(2) GDPR, because data is stored and duplicated. In practice, backups usually rely on the legitimate interest under Art. 6(1)(f) GDPR: the controller has a legitimate interest in the security, integrity and availability of its systems. The German Data Protection Conference (DSK) explicitly classifies safeguarding data availability among technical and organizational measures.
The distinction matters: the backup is not an end in itself but serves to secure data collected for another purpose (for example contract performance under Art. 6(1)(b) GDPR). The legal basis of the backup therefore follows the original processing purpose and adds the security component from Art. 32 GDPR. The German Federal Commissioner for Data Protection (BfDI) emphasizes that recoverability after an incident is an integral part of an appropriate level of protection.
Backup Is Not the Same as Archive
Retention Periods: Commercial Law Meets Data Protection
The GDPR requires personal data to be erased once the purpose ceases. Commercial and tax law, by contrast, require certain records to be kept for years. Under Sec. 257 German Commercial Code (HGB), the periods for commercial books and accounting vouchers run up to 10 years (HGB, Sec. 257), while commercial and business letters must be kept for 6 years (HGB, Sec. 257(4)). Tax law mirrors this in Sec. 147 German Fiscal Code (AO): accounting vouchers such as invoices must be kept for 10 years (Fiscal Code, Sec. 147).
These statutory duties are explicitly addressed in the GDPR: Art. 17(3)(b) GDPR exempts data from erasure where processing is necessary to comply with a legal obligation. An invoice that the right to erasure might cover must nonetheless be retained for ten years due to Sec. 147 AO. The clean solution is not deletion but restriction of processing (Art. 18 GDPR) -- often implemented in practice as blocking: the data remains for the statutory retention period but is no longer used for the original purpose.
| Criterion | Retain | Erase |
|---|---|---|
| Legal basis | Sec. 147 AO, Sec. 257 HGB, Art. 17(3)(b) GDPR | Art. 17(1), Art. 5(1)(e) GDPR |
| Typical period | 6 to 10 years (vouchers, invoices) | Immediately or once purpose ceases |
| Data affected | Invoices, accounting vouchers, business letters | Marketing consents, newsletter, profile data |
| Implementation in system | Restriction of processing (blocking) | Final deletion from active data |
| Implementation in backup | In the archive record with a defined period | Caught up on rotation, not active intervention |
A proven foundation for practical implementation is the DSK deletion concept based on DIN 66398, which groups data types into deletion classes with defined periods and trigger events (Data Protection Conference, Standard Data Protection Model). A maintained deletion concept is the precondition for retention and erasure to happen on a rule basis rather than by chance -- and it can be anchored in the ongoing Shopware maintenance of a shop.
Right to Erasure in Backups: the Special Case
When a data subject demands erasure of their data under Art. 17 GDPR, a technical question arises: what happens to the copies in old backups? Selectively deleting individual records from a consistent, often encrypted backup snapshot is technically barely possible without destroying the integrity of the entire backup. German supervisory authorities have developed a pragmatic line for this.
The State Commissioner for Data Protection of Lower Saxony and other supervisory authorities take the view that erasure in the active dataset must happen immediately, while erasure in backups is caught up only during the regular rotation -- provided the backups are isolated, not evaluated for other purposes, and the record is deleted again upon any restoration. The decisive point is that no productive access to the backup data occurs and the erasure request is recorded in a documented manner.
- Implement and document erasure in the active production system immediately.
- Record the erasure request on a watch list so it applies again upon restoration.
- Keep backups isolated -- no evaluation, no productive access, no re-import of individual fields.
- At the next rotation, the old backup containing the record expires and is overwritten.
- After a restoration, apply the recorded erasure request again before the system goes live.
No Blanket Statement Possible
Encryption and Technical Measures Under Art. 32
Art. 32 GDPR requires appropriate technical and organizational measures (TOMs) commensurate with the risk -- explicitly naming encryption (Art. 32(1)(a)) and the ability to restore the availability of personal data quickly after an incident (Art. 32(1)(c)). For backups this means concretely: encryption at rest (AES-256) and in transit (TLS 1.3). The German BSI recommends, in the IT-Grundschutz module CON.3 (data backup concept), the encryption of backup data as a standard requirement.
Encryption at Rest
Backups are stored encrypted with AES-256. Even with physical access to the storage medium, the personal data stays protected -- a core building block under Art. 32(1)(a) GDPR.
Encrypted Transport
Every transfer to off-site storage runs over TLS 1.3. Backups never leave the system in plaintext and are protected against interception in transit.
Key Management
Keys are kept separate from the backups. A compromised storage location reveals no readable data without the separately held key.
Recoverability
Regular restore tests prove that availability under Art. 32(1)(c) is actually present -- a never-tested backup does not meet this requirement.
Access Restriction
Only a clearly defined group of people has access to backups. Permissions are documented and reviewed regularly -- following the principle of data minimization.
Documentation
Backup concept, deletion concept and restore logs belong in the record of processing activities (Art. 30 GDPR) and evidence the accountability principle.
The effectiveness of these measures must be reviewed regularly (Art. 32(1)(d) GDPR). This is exactly where ongoing maintenance with security updates comes in: without current encryption libraries, patched backup software and monitored transfer paths, the TOM level remains theoretical. ENISA notes in its guidelines on data security that outdated components can undermine even the strongest encryption (ENISA, Guidelines for SMEs on the security of personal data processing).
Data Processing: Backups at the Service Provider
Anyone who has backups created, stored or managed by an external service provider passes personal data into a data processing arrangement under Art. 28 GDPR. This applies equally to hosting providers, cloud storage and maintenance providers. The precondition is a data processing agreement (DPA) covering the mandatory contents of Art. 28(3) GDPR: subject matter, duration, nature and purpose of processing, categories of data subjects, instruction-binding, confidentiality, TOMs, sub-processors and deletion duties after the contract ends.
- DPA under Art. 28(3) GDPR concluded with every provider that processes backups.
- Sub-processors (e.g. data center operators) named and approved in the DPA.
- The processor's technical and organizational measures documented and reviewed.
- Deletion and return duties for backups after the contract ends regulated.
- Record of processing activities (Art. 30 GDPR) extended to cover the backup processing.
The BfDI makes clear that responsibility for lawfulness remains with the controller -- even when technical execution lies with the processor. The controller must therefore review the provider's TOMs and be able to satisfy itself of their effectiveness. In our projects, the DPA is a fixed component of every maintenance contract with a backup component, and the list of sub-processors is kept current. We are happy to clarify the details in a personal conversation.
EU Storage Location and Third-Country Transfers
The storage location of backups is a data protection topic in its own right. If backups reside on servers outside the European Economic Area, the rules on third-country transfers under Chapter V of the GDPR (Art. 44 et seq.) apply. Without an adequacy decision, standard contractual clauses or other appropriate safeguards, such a transfer is unlawful. Following the Schrems II ruling of the CJEU (Case C-311/18, EUR-Lex), controllers must additionally assess whether the recipient country offers an equivalent level of protection.
Why EU Storage Locations Reduce Complexity
The Data Protection Conference has repeatedly stressed that transfers to third countries without appropriate safeguards are among the most frequent objections. The EU storage location is therefore not only a technical but a strategic decision that simplifies the entire backup concept. In the projects we support, we rely on hosting in Germany and EU data centers -- an aspect considered from the start when monitoring the backup infrastructure.
Data Breaches, Notification Duties and the Backup as Protection
If a backup is lost or falls unencrypted into the wrong hands, that is a personal data breach. Art. 33 GDPR requires notification to the supervisory authority within 72 hours of becoming aware (EUR-Lex, GDPR Art. 33). Where a high risk to data subjects is likely, Art. 34 GDPR adds notification of the data subjects. The fine ceiling under Art. 83(5) GDPR is up to 4 percent of worldwide annual turnover or 20 million euros -- whichever is higher.
Here the dual role of the backup becomes visible: an encrypted, isolated backup is on the one hand itself a potential risk if compromised -- on the other, it is the most important defense against ransomware and data loss. Recital 49 of the GDPR explicitly recognizes network and information security as a legitimate interest. According to Bitkom, cyberattacks cause the German economy damage in the triple-digit billions each year (Bitkom, business protection study), with ransomware-driven data encryption among the most common attack forms.
The ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident is not optional but an explicit requirement of Art. 32 GDPR.
A tested backup significantly shortens the time to recovery and can mitigate the escalation of a data breach in an emergency. Anyone who restores from a clean backup within hours after a ransomware incident -- instead of paying ransom or losing data permanently -- meets the availability requirement in practice. How to prepare updates and recovery tests safely is described in our article on staging environments for safe updates.
Bringing the Backup Concept and Deletion Concept Together
A GDPR-aware backup concept documents not only what is backed up but also how long and when the data disappears again. The BSI requires, in module CON.3, a data backup concept that defines backup type, frequency, retention duration and recovery procedures (BSI IT-Grundschutz, CON.3). Combining this concept with the deletion concept based on DIN 66398 creates a continuous lifecycle: collection, backup, retention, restriction and erasure mesh together.
- Backup scope: which systems and data types are backed up -- and which deliberately are not?
- Rotation and retention: how long are snapshots kept, aligned with deletion classes?
- Deletion classes per DIN 66398: which period and which trigger event applies per data type?
- Blocking instead of deletion logic for retention-bound vouchers (Art. 18 GDPR).
- Restore procedure including re-deletion of recorded erasure requests.
- Roles, responsibilities and access rights -- documented and reviewed.
In practice, GDPR compliance rarely fails because of a missing backup, but because of a missing link to the deletion concept and unmaintained software. Across 50+ supported projects (project experience), a documented, regularly tested and up-to-date backup concept has proven the most solid foundation. Anyone needing support here will find it in our maintenance services or in a direct conversation.
Sources and Foundations