CCSP: Data Retention, Deletion, Archiving and Legal Hold

A data retention policy states, for each record series (a category of records handled the same way, such as customer invoices, employee files or chat messages), how long it is kept, the event that starts that period, what happens at the end of it, and who owns the rule. The usual form is a retention schedule: one row per record series, approved by legal, compliance and the business, and applied to every place the series is stored, including cloud services.

Retention policy versus classification policy

The two policies are related but answer different questions. Classification (sub-domain 2.5) says how sensitive data is, and therefore how it must be labelled, protected and who may access it. Retention says how long it is kept and how it is disposed of. "HR files are Confidential" and "HR files are restricted to the HR team" are classification and access statements; "HR files are kept six years after employment ends, then deleted" is a retention rule, because it has a period, a trigger and a disposition. A classification level can inform the disposition method (sensitive data may need verified destruction), but it does not set the period.

Ownership and review

A schedule is only as current as its last review. Give the policy a named owner (often records management or the privacy office, working with legal) and a scheduled periodic review, plus a review whenever a relevant law, contract or business process changes. Automation enforces whatever period it is given; only a review notices that a regulation has changed the required period.

Retention periods come from three sources that pull in different directions: legal and regulatory obligations set the minimum, business need sets how long data is useful, and privacy law caps the maximum for personal data. A defensible period sits at or above every applicable minimum and no longer than the purpose justifies.

• Legal and regulatory minimums. Tax, accounting, employment, financial-services and healthcare rules often require specific record types to be kept for a set number of years. Where a statute sets a period for a record type, that period is the floor: a schedule built only from how long teams find data useful can delete records the organization is legally required to keep.
• Contracts. Customer and supplier contracts may require records to be kept (or deleted) by a date.
• Business need. Operations, analytics, warranty and dispute handling justify keeping some data beyond the legal minimum, and must be stated as a purpose.
• Privacy limits. The GDPR's storage limitation principle (Article 5(1)(e)) says personal data may be kept in a form that identifies the data subject for no longer than is necessary for the purposes for which it is processed. It sets no number of years; the organization derives each period from its purposes and from other laws. Keeping everything "to be safe" has no purpose and breaches the principle. The same article allows longer storage solely for archiving in the public interest, scientific or historical research, or statistical purposes, subject to the safeguards of Article 89(1) (such as pseudonymization or data minimization); ordinary business archiving does not qualify for that extension.

Operational design inputs shape how data is stored and protected; they are not a source of retention periods, which come only from obligations and stated purposes.

Pseudonymization does not extend retention; anonymization ends it

Pseudonymized data is still personal data under the GDPR, because it can be re-identified with additional information (Recital 26). Storage limitation therefore still applies to it, so pseudonymizing records after the legal minimum does not justify keeping them longer without a purpose. Data that is truly anonymized, so that no one can reasonably re-identify the person, is outside the GDPR and can be kept, which is why "anonymize" is a valid disposition in a schedule. Storage limitation applies to archives and backups as well as live systems.

Conflicting retention requirements are reconciled per record series, not with one blanket period: each category of data keeps the period its own obligations require, so a long legal minimum for one record type never becomes an excuse to keep everything else as long.

The erasure exception for legal obligations

The GDPR right to erasure (Article 17) is not absolute. Article 17(3)(b) says it does not apply to the extent that processing is necessary for compliance with a legal obligation. That exception covers only the data the obligation requires (for example invoices under tax law) and only for that purpose: the retained invoices must not keep feeding marketing or analytics. Profile data, marketing preferences and other records with no such obligation must still be erased without undue delay.

A retention schedule is enforced in the cloud by turning each rule into an automated mechanism in the service that holds the data, rather than relying on people to delete expired data by hand. Manual clean-ups miss data systematically, and any fix that still depends on people remembering to delete keeps that root cause.

• IaaS and PaaS storage. Object storage lifecycle rules transition and expire objects; databases use scheduled purge jobs or time-to-live settings. Rules are keyed to the tag, prefix or metadata that identifies each record series, so each category gets its own period.
• SaaS. The customer cannot reach the provider's storage, so it uses the provider's tenant retention settings (retention policies for mail, chat, files and sites). Many SaaS defaults keep data indefinitely, so the setting must be configured to match the schedule. Where the service has a native setting, it is the mechanism of choice, because it runs inside the provider's storage the customer cannot reach.
• Immutable retention. Where records must not be altered or deleted before their period ends (regulated financial records, audit evidence), write-once-read-many (WORM) or retention-lock features enforce the minimum. The storage options themselves are covered in the storage architectures lesson (sub-domain 2.2).

The trigger must be the one the mechanism counts from

Storage lifecycle rules usually count from the object's creation or upload date. If the policy counts from a different event ("six years after the contract ends", "six years after employment ends"), an age-based rule deletes records too early when the event comes long after upload, and lengthening the rule only moves the error. The fix is to record the trigger date (for example as metadata or in the system of record) and calculate disposal from it. This is also why an undefined trigger in the policy itself produces both early deletion and indefinite retention at once.

Deletion is defensible when it is authorized by an approved schedule, applied routinely and consistently, preceded by a check for legal holds, and documented. Courts and regulators distinguish routine, policy-driven disposition from selective deletion; an organization that can show the former is in a strong position even if deleted records later turn out to be relevant, provided no preservation duty applied when they were deleted.

1. Authorize: the record series has reached the end of its period under the approved schedule (and the data owner has approved, where the procedure requires it).
2. Check holds: confirm that no legal hold, investigation or audit covers the records before anything is deleted.
3. Delete every copy with a method suited to the media and data sensitivity (next sections).
4. Record it: keep a disposal record (sometimes a certificate of destruction) listing the record series, the authorization, the method and the date.

The disposal record is the evidence that a specific deletion happened under the rule; the schedule itself only states the rule. A common misconception is that controls around the deletion (how it is secured or how complete it is) prove it was legitimate: legitimacy comes from authorization, the hold check and the record.

Deletion mechanisms range from a logical delete to physical destruction, and NIST SP 800-88 (Guidelines for Media Sanitization; Revision 2, 2025, keeps the same three categories) groups sanitization into clear, purge and destroy according to how hard recovery becomes. Revision 2 dropped the Revision 1 media-specific technique tables and points to IEEE 2883 for them, so the techniques below are common practice rather than NIST's current list.

A logical delete (a "deleted" flag, or removing a file from an index) is not sanitization at all: the data remains and the application merely hides it.

Cryptographic erase is a purge technique

Cryptographic erase sanitizes data by destroying every copy of the key that encrypted it, leaving unreadable ciphertext. When the encryption is strong (for example a FIPS-validated implementation of a strong cipher) and no copy of the key survives, it meets the purge bar on its own; overwriting the freed blocks is not an extra condition. Because cloud customers cannot reach or destroy the provider's physical media, cryptographic erase is the practical way to sanitize data in multi-tenant cloud storage; the choice of method in the cloud is covered in the cloud security concepts lesson (sub-domain 1.3).

Media limits: SSDs and failed drives

Flash media behaves differently from magnetic disks. SSDs remap writes across spare and worn-out blocks (wear leveling and over-provisioning), so overwriting through the normal interface, however many passes, can leave data in blocks it never reaches. Degaussing does nothing to flash. For a working SSD, the drive's own sanitize or block-erase command (or cryptographic erase on a self-encrypting drive) is the purge method; a drive that no longer responds to commands cannot be sanitized logically and must be destroyed, by shredding or disintegration. These choices apply to the customer in a private cloud or for its own hardware; in a public cloud the provider sanitizes its media and the customer relies on contract terms and audit reports for it.

Deletion is complete only when every copy of the data has been dealt with: the primary store, replicas, caches, exports, test copies, logs and backups. Each copy needs its own handling, so the procedure starts from a data map that lists where the record series lives (data discovery and mapping are sub-domains 2.4 and 2.5).

• Replicas that apply the primary's changes (read replicas, synchronized copies) are covered by deleting at the primary.
• Exports and copies in other buckets, analytics stores or file shares are independent: unless each has its own lifecycle rule, it must be deleted explicitly, or it stays forever.
• Backups, especially immutable ones, cannot be edited. They are left to expire on their normal cycle and, until then, the data in them is kept beyond use.

Erasure requests and backups: "beyond use"

Data protection authorities (for example the UK ICO in its right-to-erasure guidance) accept that personal data in backups need not be deleted immediately if it is put beyond use: the organization does not use it for any other purpose, holds it only until it is replaced on the normal schedule, and is clear with the individual about what happens to their data in backups. As good practice (not something the guidance states explicitly), the organization also re-applies the erasure if a restore brings the data back. The live data is still erased without undue delay: "beyond use" is a concession for copies that cannot be edited, not a reason to delay erasing production.

Assurance that the provider has deleted your data

When a customer leaves a provider, or must prove deletion to a regulator, it needs evidence specific to its own data. Build that into the contract before signing:

• a deletion deadline after termination that meets the customer's own legal requirement ("within a reasonable time" is undefined and cannot be shown to meet a 30-day rule);
• scope that names backups, replicas and subprocessors' copies, since a provider's backup rotation can otherwise outlast the deadline;
• a signed certificate of deletion stating what was deleted, how, and when it was completed.

The common misconception is to treat generic assurance (attestation reports, certifications, published policies) as proof of a specific deletion: those show that a disposal process exists and operates in general, not that this customer's data was deleted by a given date.

Archiving moves data that must be kept, but is rarely used, to lower-cost long-term storage while keeping it retrievable, intact, findable and protected for the rest of its retention period. A successful upload is not proof of a usable archive; the procedures below are.

Protective controls around an archive are worthwhile, but only a test restore checked against the recorded hashes shows the archive can be used. When migrating archives, converting messages to another format such as PDF may improve readability but loses the metadata that makes them evidence.

Retrieval latency versus findability

Deep archive tiers can take hours to return data and charge per retrieval. That latency is usually acceptable for a targeted request; the real risk is combining slow, costly retrieval with no index, because then the organization cannot tell which files are relevant without restoring most of the archive. Index at archive time.

Access to archives

Archived data is rarely needed, so standing access is excess privilege. Give archive access to a separate role, with retrieval granted on request and approval, rather than to the staff who run the live system. Other protective layers are useful, but the principle is to remove standing access, not to watch it.

Location commitments cover every tier

Data residency or localization rules restrict where data is stored, and they apply to archives and backups as much as to live data. A cheaper archive tier offered only in another country breaks such a rule whatever else is done: controls that protect confidentiality or legitimize a transfer do not change where the data physically sits. Choose an in-country archive tier and obtain the provider's contractual location commitment for all tiers, backups and replicas; relying on default region placement gives no assurance.

A legal hold (litigation hold) is an instruction to preserve data relevant to an actual or expected legal matter, which suspends normal retention and deletion for that data until counsel releases it. The duty to preserve arises when litigation is reasonably anticipated, which is usually well before a suit is filed.

The trigger

Typical triggers are a demand letter threatening suit, a credible threat from a former supplier or employee, notice of a regulatory investigation, or an internal incident that will clearly lead to claims. Filing of the suit, a formal discovery request and a court order all come later; deleting relevant data under the routine schedule after the trigger can be treated as spoliation (destruction of evidence), with sanctions. This "reasonably anticipated" standard comes from common-law e-discovery practice (notably in the US), and CCSP teaches legal hold in those terms.

Scope

The duty covers relevant data, not everything. A well-scoped hold names:

• the custodians: the people whose data is likely to be relevant;
• the data sources they use: mailboxes, cloud drives, shared sites, messaging apps, line-of-business systems;
• the relevant period and subject matter.

The common mistake is an over-broad hold: preserving everything in sight adds storage cost, review cost and privacy exposure for people with no link to the matter. Preservation also means keeping the data where it is, in place and unaltered, rather than relying on people to collect it.

A legal hold is implemented by setting preservation in each system that holds the in-scope data and telling the custodians, and it is released by removing those settings and notifying the same people, after which normal disposition resumes.

Implementing a hold

• System holds. Use the platform's hold features (mailbox and site holds in SaaS, retention locks or legal-hold flags on objects, suspension of deletion jobs) so held data is preserved even if a user deletes it or its retention period ends. A hold does not restart the retention period, does not change the data and does not authorize deleting originals once copied to an evidence store.
• Hold notices. Send each custodian a written notice that explains the duty and must be acknowledged, and interview custodians about where they keep relevant data. System holds preserve only the sources counsel knew about; interviews find the messaging app, personal workspace or local files the first scope missed, and an acknowledged notice documents that the custodian knew.
• Backups. Backups are normally outside a hold when the same data is preserved in live systems. When backups are the only remaining source (relevant files were already deleted from the live share), pull just those backup sets out of rotation before they expire. Preserve narrowly, as with any hold.
• Hold-aware processes. Offboarding, account deprovisioning, tenant migration and storage clean-up jobs can delete held data unless they check for holds first. If a departing employee is a custodian, keep the account's data (for example as an inactive, held mailbox) until release: anything with an expiry date of its own is not a hold.

Releasing a hold

When counsel releases a hold, the team must remove the hold settings in every system and notify custodians and system owners; if the decision is never carried into the systems, the data stays preserved indefinitely, which is over-retention. After release, records whose retention period ended during the hold are due for disposal at once (the period was paused for them, not restarted), and records still within their period continue on the normal schedule. Holds are tracked per record: anything still covered by another active hold stays preserved until that hold is released too.