Data protection for cloud backups: erasure, restoration and proof

Erasure in a cloud environment is traceable only when the organisation considers the production system, backup copies and restoration together. The GDPR does not prescribe one overwriting period for every backup. It requires a risk-based and documented solution that prevents unnecessary storage and uncontrolled reactivation of deleted data.

This article explains how to build an erasure concept for backup copies. It focuses on the distinction between the active system and backups, technical restrictions, restoration and evidence for an internal review or supervisory authority. Setting the original substantive retention period for customer, recruitment or employee data is a separate step.

The content of the copy determines its relevance. A backup, snapshot, archive export and replica may contain personal data even when they are not visible as application storage in daily work. Inventory systems, locations, copy types and responsibilities. The key question is whether the data can still be related to an individual.

A backup has a different function from the production system. It usually protects availability and recoverability. That function does not remove the need to limit storage and protect access. Under Articles 25 and 32 GDPR, the architecture and security measures must reflect the purpose and risk of the processing.

The first question is therefore what the backup contains and why the copy is needed. The original retention decision for production data remains separate. Only then can the organisation decide whether a copy is erased directly, isolated until regular overwriting or kept under a specifically documented exception.

When personal data are erased in the production system, the process must account for the related backup copies. Article 17 GDPR must be assessed in the specific case. If erasure is required and no exception applies, the organisation must not use the backup as a permanent substitute storage for the same data set.

Immediate editing of every file in every immutable backup is not technically possible in every architecture. In that situation, a defensible combination may consist of no production access, a strict restoration restriction and a defined overwriting process. The copy must not be used for new purposes during that period. Record the reason and why the solution is appropriate.

Check side paths as well: manual exports, test environments, local downloads and provider copies. An erasure run limited to the visible database leaves the evidence incomplete. The article on the erasure concept for customer and lead data covers the preceding purpose and retention review.

A reliable backup lifecycle links the purpose of the safeguard to a verifiable overwriting cycle. A statement such as “backups are deleted after seven years” does not replace a review if the cycle fits neither the purpose nor the risk. Conversely, a technical cycle must not keep data indefinitely without a reason.

Define which roles may read, export, erase or restore backups. Normal access should be restricted and logged. Encryption, separate permissions and a dual-control process may be suitable depending on the risk. The necessary measure depends on the specific environment.

Connect the cycle to restoration. An old backup that can be restored in full at any time must be assessed differently from an encrypted and technically isolated copy. Check whether the provider maintains immutable snapshots, geographically redundant copies or its own recycle bin. Where relevant, include these functions in the records of processing activities and the technical and organisational measures.

A restoration can bring an earlier data state into a new environment. Before activation, determine whether it contains erased, corrected or restricted data. Define approval with reason, scope, target system and responsible person. An emergency may require speed, but it should not make the data protection review invisible.

A separate restoration environment is useful for checking and cleaning the data set first. Compare current erasure markers, restriction lists and corrections made since the backup. Only the necessary part should then enter active operation. Remove data that are no longer required for the restoration purpose.

After the restoration, record which backup was used, what was checked, which cleaning occurred and who approved activation. This supports accountability under Article 5(2) GDPR. The article on documenting technical and organisational measures explains how controls and responsibilities can be made traceable.

Article 18 GDPR may require restriction, for example where accuracy is contested, processing is unlawful and the individual requests restriction instead of erasure, or the data are needed for legal claims. Restriction is a specific legal decision. It cannot be equated with the mere existence of a backup.

For a restricted backup copy, purpose, scope and access must be clear. The data may then be processed only under the conditions in Article 18(2) GDPR. The technical restriction should reappear in the restoration process. A restore must not treat restricted data as an unrestricted production set.

Record when restriction begins, what event ends it and who performs the review. Where the situation changes, the individual must generally be informed before restriction is lifted. Restriction is therefore a distinct status with its own control, not a general reason to retain every backup indefinitely.

Useful evidence connects the legal decision, technical configuration and actual execution. Include the backup inventory, data categories, erasure or restriction status and overwriting description. Add roles, access controls and the restoration process. A policy without a control record is usually insufficient for accountability.

Use proportionate sampling to check whether a deleted record is absent from the active system, whether the backup is available only to authorised roles and whether a test restoration applies erasure and restriction logic. Use suitable test data where a production restoration is unnecessary. For each test, record the reason, result and any corrective step.

Classify deviations by risk. An old access account, an undocumented snapshot or a restoration without approval may require different responses. The record should explain the decision and show the next review date. This keeps the architecture understandable during a provider change or migration.

If a cloud or backup provider processes personal data on the organisation’s behalf, assess its role under Article 28 GDPR. The contract should reflect backup functions, sub-processors, storage locations, access and support for erasure and restriction. Compare standard terms with the architecture actually booked.

Ask which copies exist beyond the visible backup. Snapshots, replicas, recycle bins, support copies and technical logs may matter. Clarify how an erasure or restriction status is respected during restoration. A promise to remove “deleted files” from primary storage does not answer all of these questions.

Internally assign responsibility for assessing requests, instructing the provider and checking its response. The overview of processors and service providers helps with this allocation. Update the records of processing activities when the backup architecture materially changes.

Start with one concrete erasure case and follow it through the architecture. Which application erased the data? Which copies were created afterwards? Which copies remain reachable? The answers show whether the process reflects the actual data flow or describes only the production system.

Then test restoration in a controlled scenario. The test should show whether erasure and restriction markers are applied before activation, whether permissions work and whether execution is logged. The page on access logs and evidence limits can support the access review.

Finally assign every open point an owner and review date. The topic page on privacy compliance and governance helps place the principles in context. Backup documentation is complete when it connects the decision, technical control, restoration behaviour and evidence.