Most organizations have a data retention policy somewhere in a shared drive. Far fewer have a process that actually deletes data when those retention periods expire. The gap between policy and execution is where breaches find their material — and it’s exactly the gap ISO 27001 Control 8.10 was designed to close.
ISO/IEC 27001:2022 Control 8.10 requires organizations to securely delete information stored in systems, devices, and external services when it is no longer needed for business, legal, or regulatory purposes. The control applies across all storage types: on-premises servers, cloud environments, endpoint devices, removable media, and backups.
“Delete” under 8.10 does not mean dragging files to a recycle bin or running a standard OS delete command. Deletion methods must render data unrecoverable using techniques appropriate to the storage medium — secure overwriting for magnetic media, cryptographic erasure for encrypted and cloud storage, or physical destruction for end-of-life hardware. The intent is to eliminate data that no longer serves a purpose but still presents a liability if exposed, systematically reducing your attack surface.
The control also requires that deletion practices align with your retention schedule and any applicable legal or contractual obligations. This means documented procedures that specify who triggers deletion, what methods apply to each storage type, and how completion is verified. Auditors will look for evidence that deletion actually happens on schedule — not just a policy stating that it should.
Why 8.10 Matters
Control 8.10 is one of 11 new controls introduced in ISO 27001:2022, absent entirely from the 2013 version. Its addition reflects a shift in how the standard treats data lifecycle risk: retaining information past its useful life is now explicitly recognized as a security concern, not just a storage management issue.
The financial consequences of that retained data are significant. According to IBM’s 2025 Cost of a Data Breach Report, the global average cost of a data breach reached $4.44 million — a figure that includes detection, response, notification, and lost business. When the breached data includes records that should have been deleted months or years earlier, the exposure is entirely avoidable.
Consider a common scenario: an organization migrates to a new CRM platform but never purges the legacy system. The old database sits on a decommissioned server, unpatched and unmonitored. Eighteen months later, an attacker finds it through an exposed management interface. The data inside — customer records, contact details, support histories — was supposed to be deleted after migration. Instead, it becomes the breach.
This pattern repeats across vendor offboarding, cloud tenant deprovisioning, and hardware disposal. The risk is not theoretical. Organizations that treat deletion as an afterthought routinely discover that their largest exposures involve data they no longer need but never removed.
What attackers exploit
The failure modes that attackers target are predictable:
- Orphaned data on decommissioned systems — servers, databases, and file shares taken out of production but never wiped
- “Soft deleted” records — data marked as deleted in an application layer but still recoverable with standard forensic tools or direct database queries
- Backup tapes and snapshots retained indefinitely — organizations that never define a backup disposal schedule create a growing archive of recoverable data
- Cloud storage persisting after contract termination — data remaining in SaaS tenants or cloud buckets after a vendor relationship ends, often because no deletion clause was included in the contract
- Devices returned or recycled without secure erasure — laptops, phones, and storage media sent to leasing companies, recyclers, or e-waste with data intact
- Unmanaged temporary files, logs, and caches — application logs, ETL staging files, and browser caches containing sensitive data that no retention policy covers
Each of these represents data that exists only because no one executed a deletion process against it. The common thread is not sophisticated attack techniques — it is the absence of a systematic deletion practice. Attackers do not need to bypass your security controls when the data they want sits outside the perimeter you are actively defending.
How to Implement 8.10
ISO 27001 implementation for 8.10 splits into two domains: what you control directly within your own infrastructure and processes, and what you need to verify through your third-party vendors and service providers. Both require documented procedures, defined responsibilities, and auditable evidence of execution. The gap between having a policy and operationalizing it is where most organizations struggle.
For your organization
The following steps translate 8.10’s requirements into operational practice. They are ordered by dependency — each step builds on the prior one, and skipping steps is the most common reason implementations stall at audit time.
- Tie your deletion policy to your retention schedule. Your information deletion policy should reference specific data categories and their retention periods. When a retention period expires, the policy should define what triggers deletion and who is responsible for executing it.
- Classify data to determine deletion priority and method. Not all data requires the same treatment. Public marketing content and confidential customer records need different deletion assurance levels. Use your information classification scheme (Control 5.12) to map sensitivity levels to appropriate deletion methods.
- Select deletion methods appropriate to the storage type:
- Secure overwriting (single or multi-pass) for reusable magnetic media, following NIST SP 800-88 guidelines for Clear and Purge operations
- Cryptographic erasure (crypto-shredding) for encrypted storage and cloud environments — destroy the encryption key and the data becomes unrecoverable
- Physical destruction (shredding, degaussing, incineration) for end-of-life media that won’t be reused
- Factory reset plus encryption key wipe for mobile devices managed through MDM
- Automate deletion where possible. Configure lifecycle policies in cloud storage (such as S3 lifecycle rules or Azure Blob storage policies), database purge jobs for expired records, and email retention rules. Manual deletion processes are the ones most likely to be forgotten or deprioritized. Automation also creates consistent, auditable records of deletion activity.
- Address backups explicitly. Define backup retention windows and ensure backup media are destroyed or overwritten when those windows close. Backups are the most common blind spot in information deletion programs. Organizations that securely delete production data but retain indefinite backups have not actually reduced their exposure — they have only moved it to a medium that is harder to search and audit. Include snapshot retention policies for cloud-based backups alongside traditional tape and disk backup disposal.
- Log every deletion activity. Record what was deleted, when, by whom, and using what method. These logs are your primary audit evidence.
- Assign clear ownership. Define who triggers deletion (often automated or driven by data stewards), who approves exceptions to scheduled deletion, and who verifies that deletion was completed.
Common mistakes to avoid:
- Treating an OS-level file delete or recycle bin emptying as secure deletion — it is not; the data remains recoverable
- Having a retention policy that specifies periods but never triggers actual deletion workflows
- Assuming your cloud or SaaS provider handles deletion automatically at contract end — most do not without explicit instructions
- Ignoring derivative data: backups, replicated databases, logs, temporary ETL files, and cached copies
- Performing deletion but keeping no records of it — leaving nothing to show an auditor
For your vendors
Third-party risk assessment for 8.10 focuses on whether your vendors can demonstrate — not just claim — that they delete your data appropriately.
Your vendor assessment process should verify deletion capabilities during onboarding and contract renewal, not just at termination when it is too late to influence the outcome.
Questions to include in vendor assessments:
- “Describe your data deletion procedures at contract termination.”
- “What deletion methods do you use for different storage types?”
- “Can you provide certificates of destruction for physical media?”
Evidence to request:
- Data deletion policy with defined procedures and responsibilities
- Certificates of destruction from certified media destruction providers
- SOC 2 Type II or ISO 27001 audit reports covering media handling and disposal controls
Red flags that indicate weak deletion practices:
- The vendor says “we delete it” but cannot describe the specific method used
- No contractual clause addresses data return or deletion at contract termination
- No certificates of destruction are available for physical media disposal
- Backup retention is indefinite with no documented purge schedule
Beyond self-attestation, verify vendor claims through independent evidence. Review SOC 2 Type II reports for media disposal controls, request deletion confirmation letters with timestamps and method details, and include explicit deletion requirements in your data processing agreements. The strongest contracts specify deletion method, timeline, and confirmation deliverables — not just a general obligation to “delete data upon termination.”
Audit Evidence for 8.10
Auditors assess 8.10 by verifying that you have both a documented deletion policy and evidence that deletion is actually being executed. Policy alone is not sufficient — they need proof of practice. Understanding what to prepare for an ISO 27001 audit means having both documentation and execution records ready. The most common audit finding for this control is not a missing policy but a missing trail: organizations that can describe what they should be doing but cannot prove that they did it.
| Evidence Type | Example Artifact |
|---|---|
| Information Deletion Policy | Policy defining deletion triggers, methods by storage type, and responsibilities |
| Data Retention Schedule | Schedule mapping data categories to retention periods and deletion triggers |
| Deletion Logs | System-generated logs showing what was deleted, when, by whom, and method used |
| Certificates of Destruction | Third-party certificates for physical media destruction (shredding, degaussing) |
| Cloud Provider Deletion Confirmation | Written confirmation or contractual clause from SaaS/IaaS provider on data deletion at termination |
| Device Wipe Records | MDM logs or ITAM records showing secure erasure before device reuse or disposal |
| Backup Disposal Records | Evidence of backup tape/snapshot destruction per retention schedule |
| Risk Assessment (deletion scope) | Risk treatment documenting which storage types and data categories are in scope for deletion |
Cross-Framework Mapping
Control 8.10 maps to several controls across other major security and compliance frameworks. If your organization maintains multiple certifications, these mappings help you demonstrate overlapping coverage without duplicating implementation work.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | AC-04(25) | Partial |
| NIST 800-53 | AC-07(02) | Partial |
| NIST 800-53 | MA-02 | Partial |
| NIST 800-53 | MA-03(03) | Partial |
| NIST 800-53 | MA-04(03) | Partial |
| NIST 800-53 | MP-04 | Full |
| NIST 800-53 | MP-06 | Full |
| NIST 800-53 | MP-06(01) | Full |
| NIST 800-53 | SI-21 | Full |
| SOC 2 | CC6.5 (Logical and Physical Access Controls – Disposal) | Partial |
| CIS Controls v8.1 | 3.4 (Enforce Data Retention Management) | Full |
| NIST CSF 2.0 | PR.DS-01 (Data-at-Rest Protection) | Partial |
| NIST CSF 2.0 | PR.IP-06 (Data Destruction) | Full |
The strongest alignment is with NIST 800-53 MP-06 (Media Sanitization) and SI-21 (Information Disposal), which share 8.10’s focus on rendering data unrecoverable using method-appropriate techniques. The NIST OLIR crosswalk provides the formal basis for these mappings. NIST SP 800-88 (Guidelines for Media Sanitization) provides the detailed procedural guidance — defining Clear, Purge, and Destroy categories — that many organizations reference when selecting specific deletion methods for 8.10 compliance.
SOC 2 CC6.5 addresses disposal within its logical and physical access control criteria but does not prescribe specific deletion methods, making the coverage partial. CIS Controls v8.1 Control 3.4 directly addresses data retention management, making it a strong operational complement. If your organization already maintains NIST 800-53 or SOC 2 compliance, much of the implementation work for 8.10 may already be in place — the gap is typically in documentation and evidence, not in practice.
Related ISO 27001 Controls
Control 8.10 does not operate in isolation. It connects to several controls that govern the data lifecycle, media handling, and classification decisions that determine when and how deletion should occur. Understanding these relationships helps you build an integrated implementation rather than treating each control as a standalone requirement.
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.10 | Acceptable use of information | Defines rules governing when information should no longer be retained |
| 5.12 | Classification of information | Classification determines deletion priority and method by sensitivity level |
| 5.33 | Protection of records | Retention requirements that establish deletion timelines |
| 7.10 | Storage media | Secure handling of media throughout its lifecycle including disposal |
| 7.14 | Secure disposal or re-use of equipment | Physical media destruction and device sanitization at end of life |
| 8.1 | User endpoint devices | Device-level data deletion on decommission or reassignment |
| 8.9 | Configuration management | Deletion policies enforced through system and service configurations |
| 8.11 | Data masking | Alternative to deletion when data must be retained but de-identified |
| 8.12 | Data leakage prevention | Prevents exposure of data that should have been deleted |
Frequently Asked Questions
What is ISO 27001 8.10?
ISO 27001 8.10 is a technological control requiring organizations to securely delete information from systems, devices, and storage media when it is no longer needed. Deletion methods must render data unrecoverable and comply with legal, regulatory, and business retention requirements.
What happens if 8.10 is not implemented?
Without 8.10, organizations retain data beyond its useful life, increasing exposure to data breaches, regulatory penalties under laws like GDPR, and failed ISO 27001 certification audits. Orphaned data becomes a liability that grows with every missed deletion cycle.
How do you audit 8.10?
Auditors verify that a documented deletion policy exists, that deletion methods match the storage type and risk level, and that records — logs, certificates of destruction, provider confirmations — prove deletion actually occurred across systems, cloud services, and physical media.
How UpGuard Helps
Verifying that your vendors actually follow through on data deletion commitments requires visibility into their security practices — not just their contract language. UpGuard’s platform provides continuous monitoring of vendor security postures and data handling practices, helping you assess whether third parties meet your deletion and media sanitization requirements before gaps become audit findings.