Resources · 13

Data lifecycle governance: retain, archive and delete with evidence

Connect every data category to a purpose, owner, retention trigger and deletion process that can actually be verified.

Updated 23 October 2026 · 9 min

Illustration · fictional scene

What this guide helps achieve

Reduce data with no defined use
Include backups and exports in lifecycle rules
Trace holds and exceptions
Prove deletion without re-exposing the deleted content

Quick check

What purpose still justifies each category?
Where do copies and derivatives exist?
Who may extend retention?
How does deletion propagate?
What evidence remains after purge?

Step-by-step method

01
Map categories and uses
Inventory data, purposes, people affected, systems, owners and flows. Group by operational rule rather than database table name.
Deliverable: category, use, system and owner register.
02
Define lifecycle events
Connect creation, active use, closure, archive, hold and deletion to observable events. State which rule prevails when obligations conflict.
Deliverable: event, state and action matrix.
03
Include every copy
Add caches, exports, test environments, backups, archives, devices and providers. Document how quickly lifecycle changes propagate.
Deliverable: location and replication map.
04
Manage exceptions
Control legal holds, sector obligations and evidentiary needs with an authority, scope, duration and review.
Deliverable: dated exception register.
05
Automate with control
Trigger archive and purge from versioned rules. Log volume, failures and retries without retaining deleted content as evidence.
Deliverable: processing procedure and log.
06
Test end of life
Sample records that reached their deadline, confirm absence across systems and delayed backup handling, then remediate gaps.
Deliverable: deletion report and corrective plan.

Worked example

Illustrative situation

A form creates a customer record and several copies in exports and backups. The team links each copy to its purpose, start event and documented retention rule.

Decision and expected evidence

A sample of expired records checks deletion, justified exceptions and propagation to secondary systems without copying erased data into the log.

Management indicators

Indicator	What it measures	First action
Coverage	Categories connected to a rule and owner	Handle orphan data first
Deadlines executed	Expired items handled within the expected time	Analyse blocked queues and exceptions
Copies controlled	Locations included in lifecycle propagation	Add forgotten exports and backups
Purge failures	Deletion actions failed or unconfirmed	Fix and replay with evidence

Common pitfalls

Setting a duration without a start event
Forgetting exports and test environments
Treating backup as permanent archive
Retaining deleted data inside logs

Frequently asked questions

Must immutable backups be deleted immediately?

Not always. Document their lifespan, prevent ordinary reuse and apply deletion when rotation or restoration makes it possible.

Can one period cover every data category?

Rarely. Purpose, category, relationship, obligations and evidence needs may require different triggers.

How can deletion be proved?

Retain a technical identifier, applied rule, timestamp, result and control without copying the deleted data into the log.

References: data, uses and limitations

Documentation reviewed on 2026-10-22.

References: data, uses and limitations
Source and purpose	Verified data or benchmark	How to use it	Limitation to retain
NIST · Privacy Framework Examine risks to people arising from data processing.	The Privacy Framework is a voluntary privacy risk-management tool. It is distinct from a universal legal compliance checklist.	Describe actual processing: data, purposes, recipients, access and retention. Compare documents, settings and deletion or retrieval tests. Explore the method →	Using the framework alone does not determine compliance with applicable law. Processing context and jurisdiction still need examination.

Media: sanitization and evidence

Data retirement is more than deleting a file. Define the target data, copies, medium, destination and required protection. Media sanitization, application-level deletion and retention expiry answer related but different questions.

NIST SP 800-88 Revision 2 became final on 26 September 2025 and supersedes Revision 1, withdrawn on that date. The separate FAQ published on 16 July 2026 complements it. The 20 CIE-SAN points below are CIE editorial selection, not NIST control identifiers or an exhaustive compliance checklist.

NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23

NIST · SP 800-88 Rev. 1 · withdrawn edition · Withdrawn 2025-09-26 · superseded by Revision 2

Three methods, with techniques requiring qualification

Three methods, with techniques requiring qualification
NIST method	Goal and media condition · synthesis	Reading limit
Clear	Logical techniques over user-addressable locations, protecting against simple recovery using the normal interface.	Does not establish coverage of non-addressable areas; not applicable to hard copy.
Purge	Logical or physical techniques making target-data recovery infeasible using state-of-the-art laboratory techniques, with media potentially reusable.	Select the technique for the medium and policy. Cryptographic erase is a conditional Purge technique, not a fourth method.
Destroy	Target-data recovery infeasible at the state-of-the-art laboratory level, leaving the medium unable to store data.	Damaging a device is insufficient. This method does not apply to logical or virtual storage as if it were an owned physical medium.

Revision 2 mainly addresses the sanitization program and assurance. Apart from cryptographic erase, equipment-specific technique details are referred to relevant standards and those accepted by organisational policy. This page supplies neither an erasure command nor an automatic method recommendation.

NIST · SP 800-88r2 · full publication · September 2025 · printed pages distinguished from PDF viewer pages

Verify execution, then validate adequacy

Verify execution, then validate adequacy
Layer	Question	Useful evidence
Verification · §4.5.1	Did the technique complete correctly?	Status, errors and anomalies; suitable media, residue or equipment inspection according to the technique.
Validation · §4.5.2	Is the result adequate for this data and scope?	Reasoned acceptance or rejection, considering sensitivity and observed limitations.
Documentation · §4.6	Can the action be attributed to the correct medium and its destination tracked?	Identifiers, method, technique, tool, version, verification, validation and policy-appropriate personnel.

A tool can report completion while technique or scope is unsuitable. Unless policy requires it, NIST does not call for elaborate content sampling after every Clear or Purge. Retain verification limitations and the validation decision; a check count does not replace that decision.

Explore evidence points

Filter review questions by method and stage, or search text within the rows. These filters prepare evidence reading; they do not select a technique or operate on media. Method associations are editorial, not applicability decisions.

References shown: 20 of 20.

Explore evidence points · CIE-SAN · 20
CIE reference and stage	CIE review question	CIE evidence to examine	NIST locator
`CIE-SAN-01` Retention and authority Preparation Clear · Purge · Destroy	Is retirement authorised for this data under applicable rules and validated retention needs?	Owner decision, rule and any documented hold before an operation.	SP 800-88r2 · 1.1 printed page 2 · PDF page 11
`CIE-SAN-02` Data sensitivity Preparation Clear · Purge · Destroy	Are sensitivity and expected protection explicit for the target data?	Dated categorisation and organisational acceptance criteria.	SP 800-88r2 · 4.3.2 printed page 21 · PDF page 30
`CIE-SAN-03` Target data and copies Preparation Clear · Purge · Destroy	Which media, caches, copies and derivatives contain the target data?	Scope inventory, justified exclusions and dependencies; a logical volume is not the whole storage system.	SP 800-88r2 · 2.3 printed page 6 · PDF page 15
`CIE-SAN-04` Reuse and control Preparation Clear · Purge · Destroy	Will the medium be reused, and remain under the organisation’s defined control?	Intended destination, owner and transfer or maintenance conditions.	SP 800-88r2 · 4.3.3–4.3.4 printed page 22 · PDF page 31
`CIE-SAN-05` Media capabilities Preparation Clear · Purge · Destroy	Does the vendor describe command coverage, excluded areas and relevant validation testing?	Model- and version-specific documentation, covered areas, limits and assurance evidence.	SP 800-88r2 · Appendix B printed page 35 · PDF page 44
`CIE-SAN-06` Clear scope Execution Clear	Does the selected technique cover user-addressable locations within the target scope?	Media-appropriate procedure and execution result; pass count alone does not establish protection.	SP 800-88r2 · 3.1.1 printed page 8 · PDF page 17
`CIE-SAN-07` Flash and non-addressable areas Preparation Clear · Purge	Do remapping, spare cells and abstraction limit the proposed technique?	Media characteristics and technical coverage rationale; do not transfer a magnetic-disk recipe to an SSD.	SP 800-88r2 · 3.1.1 printed page 9 · PDF page 18
`CIE-SAN-08` Purge scope Execution Purge	Does the technique target the expected protection while potentially preserving reuse?	Organisationally accepted method, technique and standard, with media-specific restrictions.	SP 800-88r2 · 3.1.2 printed page 10 · PDF page 19
`CIE-SAN-09` Destroy scope Execution Destroy	Does the result make target-data recovery infeasible at the expected level and leave the medium unusable?	Media-specific criteria, result inspection and residue destination; a merely damaged device is insufficient.	SP 800-88r2 · 3.1.3 printed page 11 · PDF page 20
`CIE-SAN-10` Encryption history Cryptographic erase Purge	Were target sensitive data encrypted under the required conditions throughout their presence on the medium?	Encryption history and coverage; late activation alone does not address earlier plaintext data.	SP 800-88r2 · 3.2.2 printed page 13 · PDF page 22
`CIE-SAN-11` Keys and recoverable copies Cryptographic erase Purge	Are target keys, copies and dependent keys identified, including outside the medium?	Key-management map, escrow, injection, backups and sanitization mechanism; do not copy secrets into the record.	SP 800-88r2 · 3.2.3 printed page 14 · PDF page 23
`CIE-SAN-12` Cryptographic assurance Cryptographic erase Purge	Is implementation and key-sanitization quality supported by evidence?	Relevant assurance or validation for generation, encryption, wrapping and sanitization; distinguish US federal requirements from local policy.	SP 800-88r2 · 3.2.4 printed page 15 · PDF page 24
`CIE-SAN-13` CE traceability Traceability Purge	Does the record identify cryptographic-erase mechanisms, coverage, errors and commands?	Product and version references, cryptographic scope, key life cycle and error handling.	SP 800-88r2 · 3.2.5 printed page 16 · PDF page 25
`CIE-SAN-14` Logical or cloud storage Execution Clear · Purge	What assurance covers the encrypted boundary, copies and key management when hardware is abstracted?	Provider commitments and evidence; deleting an object or API credential does not establish storage sanitization.	SP 800-88r2 · 3.1.2 printed page 10 · PDF page 19
`CIE-SAN-15` Technical verification Assurance Clear · Purge · Destroy	Did the technique finish as expected, and what errors or anomalies remain?	Tool status, errors, media condition or suitable physical inspection; policy defines any additional checks.	SP 800-88r2 · 4.5.1 printed page 24 · PDF page 33
`CIE-SAN-16` Outcome validation Assurance Clear · Purge · Destroy	Are verification results acceptable for the scope and sensitivity?	Reasoned acceptance or rejection and an identified decision owner, distinct from a completed status.	SP 800-88r2 · 4.5.2 printed page 24 · PDF page 33
`CIE-SAN-17` Anomalies and rework Assurance Clear · Purge · Destroy	Are scope limits, unsuitable settings or inadequate outcomes examined before acceptance?	Gap analysis and rework or escalation decision; reassess whether the medium remains reusable.	SP 800-88r2 · 4.5.2 printed page 25 · PDF page 34
`CIE-SAN-18` Identify the operation Traceability Clear · Purge · Destroy	Does the record connect the correct medium to its method, technique and tool version?	Media identifiers, type, origin, separate method and technique, tool and version.	SP 800-88r2 · 4.6 printed page 26 · PDF page 35
`CIE-SAN-19` Responsibilities and dates Traceability Clear · Purge · Destroy	Can execution, verification and validation owners be identified with relevant dates and locations?	Policy-appropriate roles and records; limit personal information to evidence needs.	SP 800-88r2 · 4.6 printed page 26 · PDF page 35
`CIE-SAN-20` Destination and reconciliation Traceability Clear · Purge · Destroy	Do final disposition and each medium’s tracking agree with the starting inventory?	Destination evidence and reconciliation of expected, processed, rejected or missing media.	SP 800-88r2 · Appendix C printed page 37 · PDF page 46

Cryptographic erase: four boundaries to document

Cryptographic erase: four boundaries to document
Boundary	What to establish	What the label alone does not prove
Encrypted data	Encryption history and coverage since data entered the medium, accounting for suitable prior sanitization.	Enabling encryption today alone does not address earlier sensitive plaintext data.
Keys and hierarchy	Target keys, copies, escrow, injection and dependencies that could enable decryption.	Deleting a service credential is not necessarily sanitizing a data-encryption key.
Implementation	Quality of encryption, generation, wrapping and key sanitization, with relevant assurance.	An encrypted label establishes neither coverage nor CE effectiveness.
Copies and cloud	Encrypted boundary, external copies and provider evidence where underlying hardware is abstracted.	A successful deletion API response alone does not establish sanitization of every copy.

NIST · FAQ for SP 800-88r2 · Published 2026-07-16 · consulted 2026-10-23

Six educational situations: where evidence may be missing

Six educational situations: where evidence may be missing
Fictional situation	Premature conclusion	Review to prepare
An SSD underwent multiple overwrite passes.	Pass count proves Purge.	Examine spare cells, remapping, technique scope and media assurance.
A drive no longer starts after a physical operation.	The medium is Destroy and its data unrecoverable.	Identify technique and applicable criteria; inoperability alone does not establish the outcome.
Encryption was enabled after earlier plaintext use.	Removing keys sanitizes the entire history.	Establish scope and history; examine a suitable technique for earlier data.
A cloud provider confirms object deletion.	Every physical copy is sanitized.	Review versions, replicas, backups, key boundaries and relevant contractual or technical evidence.
A tool reports completed despite an inaccessible area.	Validation follows from tool success.	Retain the anomaly, its scope effect and reasoned acceptance or rejection.
An attestation covers media delivered to a provider.	The entire starting inventory was processed.	Reconcile expected identifiers and attestations; record missing items, rejections, transfers and destination.

Connect the operation to the correct medium

Section 4.6 and Appendix C’s example describe information to record. For internal review, link media identity, separate method and technique, tool and version, verification results, validation decision, personnel and destination. The NIST example is not NIST certification of an organisation.

Retain necessary evidence with suitable access and retention. A record can reference target data without copying it: do not attach cryptographic keys, deleted content or unnecessary personal data.

Sources: NIST SP 800-88r2 and its FAQ, consulted 23 October 2026. The publication states that it is not subject to copyright in the United States; attribution to Ramaswamy Chandramouli and Eric A. Hibbard, NIST, 2025. Questions, CIE-SAN references, filter associations and fictional situations are CIE editorial synthesis in French and English. No NIST endorsement of CIE, a product or a particular method is implied.

NIST · Copyrights & Disclaimers · Publication also states its copyright status in the front matter

Verified documentary editions

SP 800-88r2 · final 2025-09-26 · FAQ 2026-07-16 · reviewed 2026-10-23

Publication PDF SHA-256: 39bb805c72723ed74f08e5806cd8463ca2554a62abb4f97b9d19c0398a8a7c55

FAQ PDF SHA-256: 3f81228035aae09714d8e70962cdde45228bc421287068236d624ce40f44e3bf

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.