Data Retention and Disposal Policy Template: Schedules, Holds and Sanitisation

Data that should have been deleted years ago is still breach exposure: it can be stolen, it must be searched for every access request and legal discovery, and regulators treat keeping personal data "just in case" as a breach in its own right. A data retention and disposal policy sets how long each class of record is kept, who decides, how legal holds suspend deletion, and how data and media are disposed of so they cannot be recovered. This template covers the retention schedule, legal holds, deletion in live systems, backups, SaaS and AI platforms, decommissioning of systems and the identities attached to them, and media sanitisation with verification and certificates. It is written for CISOs, DPOs, records managers and IT operations leads; have legal counsel set the actual retention periods.

How to use this template

• Replace text in square brackets, such as [Organisation], [Records Manager] and [6 years], with your own names and values. Every retention period in this template is a placeholder: confirm each one against the laws, regulators and contracts that apply to you.
• "Must" is mandatory. "Should" is a recommended practice where a documented exception may be justified.
• The retention schedule (section 5) is usually maintained as a separate, more detailed register. Keep this policy stable and change the schedule as needed.
• This policy relies on information classification. See the Data Classification Policy Template. For deletion techniques in depth, see the Data Retention and Secure Deletion Guide.

1. Purpose

This policy ensures that [Organisation] keeps information for as long as it is needed for legal, regulatory, contractual and business purposes, and no longer, and that information and media are disposed of securely and verifiably when that period ends.

2. Scope

1. This policy applies to all information created, received or held by or on behalf of [Organisation], in any format and location, including email, collaboration tools and chat, databases, file shares, cloud storage, SaaS applications, logs, backups and archives, source code repositories, paper records and removable media.
2. It applies to data held by suppliers and processors on [Organisation]'s behalf, and to data used to train, fine-tune, ground or evaluate AI systems, including prompts, outputs, embeddings and vector stores.
3. It applies to all physical media and devices that store data, including laptops, phones, servers, storage arrays, network equipment, printers and multifunction devices, at reuse, repair, return to lessor and end of life.
4. It applies to all employees, contractors and third parties who manage [Organisation] information or equipment.

3. Roles and responsibilities

4. Retention principles

1. Every data set must be assigned to a class in the retention schedule. Data not assigned must be referred to the [Records Manager] and kept for [12 months] at most pending classification.
2. Personal data must not be kept in identifiable form for longer than necessary for its purpose. Data must not be kept indefinitely "just in case".
3. Retention periods must start from a defined trigger (for example end of contract, end of employment, account closure, date of creation) recorded in the schedule.
4. Records must be kept in approved systems of record. Copies, extracts and exports must not outlive the retention period of the source.
5. At the end of the retention period, data must be deleted, anonymised, or transferred to an approved archive where the schedule allows it. Moving data offline or to cold storage is not deletion.
6. Retention must be enforced automatically wherever the system supports it, using [retention labels or policies, lifecycle rules, database purge jobs].

5. Retention schedule

The table below is a starting structure. All periods are placeholders and must be confirmed by [General Counsel] before adoption.

For security log periods, see the Log Management and Retention Guide. For messaging apps outside approved tools, see the Enterprise Messaging Retention and Off-Channel Communications Guide.

6. Legal holds

1. When litigation, a regulatory investigation or an audit is reasonably anticipated, [General Counsel] must issue a legal hold identifying the custodians, systems and data concerned.
2. A legal hold overrides the retention schedule. Automated deletion for the data concerned must be suspended within [2 business days] of the notice, and custodians must confirm receipt.
3. Only [General Counsel] may release a legal hold. On release, held data returns to its normal schedule and any data past its retention date must be disposed of.
4. Deleting or altering data subject to a legal hold is a serious breach of this policy.

7. Deletion and disposal of information

1. Live systems: deletion must remove the data from the application, its database, search indexes, caches, replicas and derived data sets such as reports, data warehouse tables and embeddings.
2. Backups: where data cannot be removed from backups individually, backups must expire on their schedule, and restored data must have deletions reapplied before use.
3. Cloud and SaaS: retention and deletion must be configured in each service, including recycle bins, version history and soft-delete periods, and contracts must require deletion or return of data at termination with written confirmation within [30 days].
4. Cryptographic erase: where data is encrypted with keys [Organisation] controls, destroying all copies of the keys may be used to dispose of data that cannot otherwise be reached, with the key destruction recorded.
5. Erasure requests: requests to erase personal data must be assessed by the [DPO] and actioned within the legal deadline, including at processors.
6. Paper: Confidential and Restricted paper must be cross-cut shredded on site or collected in locked containers by an approved vendor.

7.1 Decommissioning systems and their identities

1. When a system, environment, tenant or application is retired, its data must be migrated, archived under the schedule or deleted, and the decommissioning recorded.
2. All identities and credentials attached to the retired system must be removed: service accounts, API keys, certificates, OAuth applications and grants, tokens, secrets in the secrets manager, and AI agent registrations. A retired system with live credentials is not decommissioned.
3. Test, demo and legacy tenants must follow the same rules as production when they are retired.

8. Media sanitisation and equipment disposal

1. All media must be sanitised before reuse, repair outside [Organisation] control, return to a lessor, or disposal, using a method matched to the highest classification of data it has held.
2. Methods must follow the [Media Sanitisation Standard], based on NIST SP 800-88, using the levels below.

1. Disposal vendors must be approved by [CISO], contractually bound to the method required, and must provide certificates for each batch. [Organisation] must reconcile certificates against the asset register.
2. Media awaiting sanitisation must be stored securely and tracked by serial number. Chain of custody must be recorded when media leaves [Organisation] premises.

See the Media Sanitisation Guide.

9. Compliance and review

1. [Records Manager] and [IT operations] must report to [CISO and DPO] [twice yearly] on the measures in the implementation guidance.
2. This policy is owned by [Records Manager], approved by [executive committee], and reviewed at least [annually] or after a change in law, a regulatory finding or an incident involving retained data. Exceptions must be recorded with an end date and approved by [General Counsel] and [DPO].

Implementation guidance

Where the design choices come from

• Storage limitation: the UK ICO guidance on the storage limitation principle (UK GDPR Article 5(1)(e)) says there are no fixed retention periods, that organisations must justify their periods, keep a retention policy or schedule where possible, review data at the end of each period, and that moving data offline is not deletion. The ICO notes this guidance is under review following the Data (Use and Access) Act; check the current version.
• Sanitisation: NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization (final, September 2025, superseding Rev. 1 of 2014) is aimed at establishing a media sanitisation programme and choosing techniques according to the sensitivity of the information. The clear, purge and destroy levels in section 8 follow the categories long used in SP 800-88.
• Information lifecycle: NIST SP 800-53 Rev. 5 SI-12 requires information to be managed and retained in line with laws, regulations and operational needs, and MP-6 requires sanitisation before disposal, release or reuse with strength matched to the information's classification.

Rollout

1. Inventory the main data stores and agree a schedule class for each with owners and legal counsel.
2. Configure retention in the largest systems (email, collaboration, file storage) in a simulation or preview mode where available, review what would be deleted for [30 days], then enable deletion. Keep the change reversible for the first cycle, for example by relying on the platform's recovery period.
3. Run a one-off clean-up of data far past retention, starting with stale file shares, old exports and unused databases, and record what was removed.
4. Test the legal hold procedure by issuing a test hold and confirming that deletion stops.
5. Reconcile disposal certificates against the asset register for the last [12 months] and close gaps.

Measures

• Schedule coverage: percentage of data stores assigned to a schedule class with automated retention.
• Overdue data: volume of data past its retention date found by discovery scans.
• Certificate reconciliation: percentage of disposed assets with a matching sanitisation or destruction certificate (target [100%]).
• Clean decommissioning: retired systems with any credential or identity still active.
• Erasure requests on time: percentage completed within the legal deadline.

Failure patterns this policy is written to prevent

• Retired environments left alive: in the Microsoft Midnight Blizzard breach, attackers password-sprayed a legacy, non-production test tenant account without MFA and then abused a legacy test OAuth application with elevated access. Section 7.1 treats retired tenants and their identities as part of disposal.
• Deletion that stops at the application: data removed from the user interface but still in exports, replicas, search indexes or embeddings.
• Uncertified disposal: drives handed to a recycler with no serial-level certificate and no reconciliation.
• Holds that do not stop automation: a legal hold sent by email while retention jobs keep deleting the data.

Framework mapping

Sources for the design choices

• NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
• ICO: Principle (e), Storage limitation
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements

Related NHI Mgmt Group resources: Data Retention and Secure Deletion Guide · Media Sanitisation Guide · Data Classification Policy Template · Log Management and Retention Guide