ISO 27001 Annex A 8.10: information deletion that survives audit

A customer's termination notice arrives with one line that matters: delete our data within 30 days, and certify it. You have a retention policy somewhere, a recycle bin, and no record that anything was ever erased.

This guide covers ISO 27001 Annex A 8.10 for security officers, IT leads and compliance managers at UK-regulated firms and B2B SaaS companies. It moves deletion out of manual checklists and into cloud lifecycle rules, event-driven erasure and sanitisation you can evidence.

What does ISO 27001:2022 Annex A 8.10 information deletion require?

ISO 27001 2022 Annex A 8.10 information deletion requires you to erase information once its purpose and retention period end. The method must survive forensic recovery, and you keep records proving the erasure happened. The control is new in the 2022 revision and covers logical deletion; equipment disposal sits in A.7.14.

In practice the control asks for four things, in order:

1. Know when information stops being needed. The retention schedule sets the date.
2. Erase it so it cannot be recovered. The method depends on the medium.
3. Chase down the stragglers. Old versions, caches, temporary files and supplier copies.
4. Keep the proof. A log, report or certificate shows the erasure happened.

Annex A 8.10 handles the logical side of disposal. Its physical twin, A.7.14, covers wiping and destroying the equipment itself, and A.5.33 guards the opposite flank: the records you are obliged to keep. Retiring a server touches both 8.10 and A.7.14, so write one procedure that hands off cleanly between them.

Data that no longer exists cannot be breached, demanded in litigation or fined over. Deletion is the last step in handling information, and classification is the first.

UK GDPR's storage-limitation principle and the right to erasure make over-retention a regulatory exposure whether or not you certify. A breach investigation that surfaces ten-year-old customer records you had no reason to hold turns a bad week into a fine. Enterprise buyers also write deletion commitments like the one in that termination notice into contracts. A firm that cannot evidence deletion cannot sign them honestly.

Over-retention is not caution. Every record kept past its purpose is attack surface you pay to defend and get nothing back from.

How do you design an ISO 27001 information deletion policy and retention schedule?

Write one retention and disposal schedule anchored to your data inventory (A.5.9). For each information type, record how long it lives, which event starts the clock — contract end, account closure, employee departure — and who owns the decision. UK GDPR's storage-limitation principle expects documented retention periods, so the schedule serves both regimes.

The ICO guidance on the storage limitation principle asks for a policy that sets standard retention periods wherever possible, and for regular reviews of the data you hold. A schedule that lives only in someone's head fails that test, and it fails the audit too.

Build it in four moves:

1. Start from the inventory. List every information type in the A.5.9 inventory; without it, the schedule is guesswork. Classification then tells you how sensitive each type is, which later drives the erasure method.
2. Set the period. Record the legal or contractual baseline for each type, and the business purpose behind anything kept longer.
3. Name the clock-start event. Use an event, not a calendar date, so an HR or CRM change can trigger deletion automatically later.
4. Assign an owner. One named role decides exceptions and signs off what gets erased.

The usual failure is a schedule written once for the audit and never revisited, quietly out of step with current legal and contractual obligations. Put a review date on the document, and let a change in a customer contract or a regulator's expectation reopen it.

A retention schedule nobody has ever watched fire is a wish list.

Which media sanitisation methods count as deleting through forensically sound methods as part of C&D?

NIST SP 800-88 defines media sanitisation as rendering access to target data infeasible for a given level of effort, through Clear, Purge or Destroy techniques. Match the technique to the medium and sensitivity: the recycle bin only hides data, while recognised overwriting, factory resets and certified destruction remove it.

The NIST SP 800-88 Rev. 2 media sanitisation guidelines, which replaced Rev. 1 in September 2025, are the reference auditors recognise, so naming them in your procedure saves an argument. The test is outcome-based: recovery must be infeasible for a given level of effort. Your job is to pick the technique that meets that bar for each medium you hold.

Choose in three steps:

1. Identify the medium. Laptop and server drives, phones, removable media, paper and cloud storage each need a different route.
2. Set the method by sensitivity. The more sensitive the information, the stronger the technique, up to destruction for end-of-life media.
3. Capture the result. A sanitisation-tool report or a certificate of destruction is what turns the act into evidence.

Two pitfalls cause most findings. The first is treating the recycle bin as deletion. Recoverable data on a "wiped" machine is one of the most avoidable audit findings and breach causes. The second is hardware donated, sold or returned to a lessor with its storage intact.

Solid-state drives need their own route. Wear-levelling leaves copies in cells that overwriting software cannot reach, so use the drive's built-in secure erase or sanitise command, or a cryptographic erase if the drive encrypts itself.

Pull the drives before kit goes back to a lessor or a vendor for repair. Treat any journey to a sanitisation site as part of the chain, with the asset logged out and logged in again.

How do you delete cloud data and media you cannot physically reach?

Use the provider's deletion mechanisms and lifecycle automation, such as object lifecycle rules, then add crypto-shredding where you cannot reach physical media. Destroying the encryption keys makes the data unreadable wherever those keys protect it, backups included. Provider attestation reports cover the rest, standing in for direct observation of their hardware.

Cloud deletion is engineered, not witnessed. Nobody on your team will watch a provider wipe a drive in its data centre. The control shifts to setting up the platform correctly and keeping the evidence it produces.

Layer three mechanisms:

• Provider deletion. Delete through the service's own console or API, and keep the log of the call.
• Lifecycle rules. Object lifecycle rules in cloud storage, retention policies in Microsoft 365 or Google Workspace, and TTL or scheduled purge jobs on databases. Each one expires data on schedule without anyone having to remember.
• Crypto-shredding. Encrypt with keys you control and destroy the keys when retention ends.

Crypto-shredding is only as precise as your key design. One key for the whole estate means you can destroy everything or nothing. A key per customer or dataset lets you erase one tenant's data when its contract ends. Record each key destruction in your key-management log.

File the provider's current attestation report with your supplier review. Then the answer to "how do you know the provider erased it?" is a document, not a shrug.

How do you handle backups and right-to-erasure requests under A.8.10?

Erase from live systems promptly, let backup copies expire on their normal rotation, and suppress the record if a restore happens in between. The ICO's right-to-erasure guidance says to put backup data 'beyond use' even when it cannot be immediately overwritten. Write the position down as policy before a request arrives.

The ICO guidance on the right to erasure and backup systems is the anchor. Its point is that you must not use the backed-up data while it waits to be overwritten in line with an established retention schedule. Erasure does not mean rewriting every cyclic or immutable backup.

A defensible written position has four parts:

1. Erase live. Remove the data from production systems, databases and SaaS tools promptly, and log the deletion.
2. State the backup cycle. Record how long backups are kept, so the age-out date of any copy is knowable.
3. Suppress on restore. Keep a list of erased individuals and reapply it after any restore, before the system returns to service.
4. Record the request. Note the date received, the systems touched and the date backups will have aged out.

Auditors and the ICO both accept a reasoned position more readily than one made up on the spot.

Where does data hide after you delete the master copy?

Superseded document versions, caches and temporary files, personal drives, and copies held by processors and sub-processors all outlive the master record. Sweep each one deliberately, and write deletion obligations, during the contract and at exit, into supplier agreements, collecting the supplier's confirmation when they erase.

Treat the sweep as a checklist of places, each with its own mechanism:

• Superseded versions. Set version-history retention in your document stores so old drafts age out with the record.
• Caches and temporary files. Application caches, export folders and temp directories need scheduled clean-up jobs, because nobody deletes them by hand.
• Personal drives. Apply retention policies to individual drives and downloads, and clear them at offboarding.
• Processors and sub-processors. Ask each supplier holding your data how and when it erases, and who confirms it.

Supplier clauses do two jobs. During the contract, they oblige the supplier to delete on your instruction or when retention ends. At exit, they oblige it to erase everything and confirm in writing, and that confirmation is the artefact you file.

The classic miss is deleting the master record while versions, caches and duplicates live on untouched. A customer export sitting on a shared drive is still the customer's data, and a breach investigation will find it.

How do you automate information deletion end to end?

Treat retention as configuration. Lifecycle rules in cloud storage and workspace suites run continuously once set against the schedule. Add offboarding-triggered erasure workflows, a deletion-due dashboard that joins the schedule to the data inventory, and tightly restricted bulk-deletion rights protected by MFA and logging.

Deletion automates unusually well because the platforms enforce it natively. Four builds cover the control:

1. Rules kept as code. Define lifecycle and retention rules in version-controlled configuration rather than console clicks. Every change is then reviewed, and the history shows the rules matched the schedule all year.
2. Event-driven erasure. An offboarding record in the HR system, or a termination flag in the CRM, starts the deletion workflow for that person's or client's data. The workflow writes its completion record back automatically.
3. A deletion-due dashboard. The schedule held as data and joined to the inventory yields a queue of what is due and what is overdue. An annual guilt-driven purge becomes weekly housekeeping.
4. Restricted bulk deletion. Limit the right to a few hands, put MFA in front of it and log every use with the approver visible.

A bulk-delete permission with no approver and no log is an incident waiting for a typo.

Log deletions of sensitive data as well. If information later surfaces where it should not, the deletion record is how you prove what you destroyed and when.

Scale the machinery to the firm. A 30-person SaaS company does not need enterprise records-management software. Workspace retention policies and a one-page schedule usually cover it, and the platforms you already pay for carry the rest.

What audit evidence does Annex A 8.10 need?

Auditors read the retention schedule and the data inventory together. Then they look for proof that deletion ran: lifecycle rules configured in the live console, purge logs, bulk-deletion logs with the approver visible, sanitisation-tool reports, and disposal-vendor certificates of destruction filed against the specific assets they cover.

File each artefact where an auditor can find it without a scavenger hunt:

• Schedule and inventory: the policy library, reviewed together, with a visible review date.
• Lifecycle configuration: console exports or screenshots, ideally shown live rather than described.
• Purge and bulk-deletion logs: the logging platform, with approvers named.
• Sanitisation reports: attached to the asset's ticket or record.
• Certificates of destruction: attached to the asset they cover.
• Supplier clauses and confirmations: the supplier register, with attestation reports for the major clouds.

Certificate chasing can run itself. Open each asset disposal as a ticket and keep it open until the destruction certificate is attached, so the evidence gap closes before anyone asks.

The pitfall is using a disposal vendor and never collecting or filing the certificates. The work happened, the evidence didn't, and an auditor can only grade what is on the table.

What will auditors test under ISO 27001 Annex A 8.10?

Expect the auditor to pick a departed customer or employee and trace their data to confirmed erasure. They will ask for the destruction certificate for a specific disposed asset, and open your cloud console to check the lifecycle rules exist. Missing schedules or recoverable disposed hardware grade major; isolated gaps grade minor, or major as a pattern.

Questions to rehearse before the room:

• How do you know when a customer record is due for deletion? Walk through the trigger.
• A client terminated last quarter. Show their data being deleted and the evidence you kept.
• What happens to the drive in a laptop returning off lease?
• How do old versions, caches and temporary files get caught?
• What happens in your backups when someone invokes the right to erasure?
• Who can mass-delete data, and what stops them doing it by accident?

A schedule that promises "deleted after 6 years" invites the follow-up: show me something that hit 6 years and went. Have one real example ready, with the log beside it.

In certification-body practice, grading follows a pattern:

• Major: no retention schedule at all, or disposed hardware leaving with recoverable data on it.
• Minor: a missing destruction certificate, one system without lifecycle rules, or a schedule that has drifted from current legal requirements.
• Escalation: minors that repeat across the sample, or sampling that shows deletion simply never happens, aggregate to major.

Frequently asked questions