---
title: "Annex A 7.14 secure disposal or re-use of equipment: the audit trail"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-7-14-secure-disposal-or-re-use-of-equipment
published: 2023-06-02
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.7.14 Secure disposal or re-use of equipment"
journeyStage: implementation
---

# Annex A 7.14 secure disposal or re-use of equipment: the audit trail

## Key takeaways

Annex A 7.14 is proven by an unbroken trail from the asset register to a wipe log or an itemised ITAD certificate that carries serial numbers. Deletion and reformatting never count as sanitisation, and encryption from day one makes end-of-life cheap. MDM and scripted reconciliation turn that trail into a standing report instead of an audit-week scramble.

- **Scope of the control** — Covers any equipment that may hold storage, whether disposed of, sold, donated, returned to a lessor or reassigned. Premises kit such as door controllers and cameras is included.
- **Sanitisation methods** — Deletion and reformatting leave data recoverable. Choose Clear, Purge or Destroy from NIST SP 800-88 by media and sensitivity, or destroy the encryption key on encrypted devices.
- **The audit trail** — Auditors trace a retired device from asset register to wipe log or itemised ITAD certificate. Certificates must carry serial numbers that reconcile with the register.
- **Audit grading** — Hardware leaving with recoverable sensitive data grades major. Register gaps, one missing batch certificate or labels left on donated kit grade minor, becoming major as a pattern.

The due-diligence questionnaire asks what happens to your old hardware. Your honest answer is a cupboard of retired laptops and a shredding certificate with no serial numbers on it. This guide covers Annex A 7.14 secure disposal or re-use of equipment for IT managers and compliance leads preparing for an ISO 27001:2022 audit.

You will see what the control requires, which wipe method fits which device and what auditors sample. You will also see how to make the evidence a by-product of your asset register and MDM, not a scramble before the audit.

## What does ISO 27001 Annex A 7.14 secure disposal or re-use of equipment require?

ISO 27001:2022 Annex A.7.14 requires you to check whether any equipment holds storage before it is disposed of, sold, donated, returned or reassigned. If it does, sensitive data and licensed software must be made truly unrecoverable. Its guidance also covers removing identifying marks and decommissioning premises kit when you leave a site.

Disposal is where data leaves quietly. A returned lease laptop, a resold server or a donated PC can carry client records, credentials and key material. That breach needs no attacker, only a gap in your own process.

The control breaks into four duties:

- **Check for storage.** Look at every device before it leaves. Remember the sneaky ones: multi-function printers, phones, tablets and NAS boxes.
- **Sanitise.** Make data and licensed software unrecoverable, using a method that fits the media and what it held.
- **Strip identity.** Remove company labels, asset tags and classification markings before anything leaves your control.
- **Decommission premises kit.** Deal with door controllers and cameras when you vacate an office.

Annex A.7.14 is a preventive control that protects confidentiality. It closes the asset lifecycle that starts in your asset register, and your classification scheme decides how hard each device is wiped. Storage media detail sits in Annex A 7.10, deletion technique in Annex A 8.10 and the encryption that makes disposal cheap in Annex A 8.24.

For a regulated firm, a disposal slip is a reportable incident and an uncomfortable conversation with the ICO. For a B2B supplier, it is the due-diligence question "what happens to your old hardware?" answered badly.

Certified disposal costs pounds per device, while the incident costs the renewal.

## Why isn't deleting or formatting enough, and which sanitisation method fits?

Deleting files or reformatting a drive leaves data recoverable with freely available software, so neither counts as sanitisation. Choose Clear, Purge or Destroy from NIST SP 800-88 by media type and sensitivity; for encrypted devices, destroying the key (cryptographic erasure) is an efficient route before re-use or release.

The [ICO guidance on deleting data from computers and devices](https://ico.org.uk/for-the-public/online/deleting-your-data-from-computers-laptops-and-other-devices/) says a reformat is not enough, because free software can recover the data. The [NCSC guidance on secure sanitisation and disposal of storage media](https://www.ncsc.gov.uk/guidance/secure-sanitisation-storage-media) defines sanitisation as treating data so it is less likely to be retrieved. Hitting delete is not enough.

[NIST SP 800-88 Rev. 2 Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final) defines sanitisation as rendering access to target data infeasible for a given level of effort. That wording is your test. The more sensitive the data, the more effort you must assume someone will spend, so the stronger the method.

Work through method selection in this order:

1. **Identify the media.** Spinning disk, SSD, phone, NAS or the embedded storage in a printer.
2. **Rate the sensitivity** of what the device held, using your classification scheme.
3. **Pick the level** (Clear, Purge or Destroy) that makes recovery infeasible for that sensitivity.
4. **Check the encryption history.** If the drive was encrypted from first use with keys held elsewhere, destroy the key.
5. **Record the outcome** against the device serial in the asset register.

For reuse, software wiping or cryptographic erasure fits. For end of life, shredding or degaussing fits. SSDs are the exception: they do not respond to multi-pass overwriting the way spinning disks do, so cryptographic erasure or destruction is the safe answer.

Full-disk encryption from the first day of a device's life changes the economics. A drive that was always encrypted, with keys held elsewhere, reduces end-of-life sanitisation to destroying the key. Most firms still shred end-of-life drives through an ITAD vendor anyway, because the certificate is cheap and the audit conversation is shorter.

| Situation | Method | What to record |
| --- | --- | --- |
| Spinning disk, reassigned internally | Software wipe, then re-image | Wipe log or re-image record against serial |
| Encrypted laptop, reassigned or returned | Cryptographic erasure (destroy the key), then reset | Key destruction or reset log against serial |
| SSD with no encryption history | Cryptographic erasure if supported, otherwise Destroy | Method used and serial |
| Any drive at end of life | Destroy through an ITAD vendor | Itemised certificate listing the serial |
| Damaged device that cannot be wiped | Destroy, do not repair | Risk decision and certificate |

## What should an ISO 27001 Annex A secure disposal or re-use of equipment procedure contain?

A workable procedure is short: it states what happens when a device is retired, reassigned or returned, and who does it. It names one owner and fixes methods by media and sensitivity. It uses a certified ITAD vendor with itemised, serial-numbered certificates, and closes the asset register entry for every device.

Fold disposal into the asset lifecycle rather than writing a ceremony. For a 50-person firm, a short section in your IT procedures or a Disposal and Destruction Policy is enough.

A procedure that survives audit contains:

- **One named owner.** Whoever owns the asset register, typically the IT or security lead at this scale. Disposal fails in the gap between "IT's job" and "office manager's job".
- **Methods by media and sensitivity,** anchored to NIST SP 800-88.
- **ITAD due diligence.** Vet the vendor once and keep the file.
- **Itemised certificates** with serial numbers, retained as the audit artefact for ISO 27001 data destruction.
- **Register closure.** Every disposal, reassignment or return updates the asset record.
- **Identity revocation.** Accounts, certificates and device identities tied to the hardware are revoked at the same time.
- **A risk call for damaged devices.** Destroy rather than repair when the contents cannot be guaranteed.

The commonest failure is paperwork that looks complete. Certificates are never collected, or arrive as one line for "forty laptops" with no serials, which makes them impossible to check.

A destruction certificate that cannot be matched to a serial number is a receipt, not evidence.

The second failure is a policy written once and never reviewed. Put a review date in the document and trigger an earlier review when the estate changes: a new device type, a new lessor or an office move.

Standing this up takes a day or two of policy, vendor selection and register hygiene. Run it with Annex A 7.10 as one disposal workstream, ideally after full-disk encryption is enforced across the estate.

## Does reassigning a laptop to a new starter count as disposal?

Yes, treat internal reassignment as disposal-lite. Before the laptop moves to its next holder, wipe and re-image it. Then remove the previous user's profile, cached credentials and licensed software, and update the asset record. Formatting alone leaves the previous user's data recoverable, so route handovers through device-management re-provisioning.

Internal handover carries the same exposure as external disposal; the recipient is simply closer to hand. The standard failure is the sales laptop that arrives carrying the finance director's cached mailbox and the old licence keys.

Before a laptop moves between people:

1. **Wipe** the device with your MDM or wiping software, never a quick format.
2. **Re-image** it from the current build.
3. **De-provision** the previous user's profile, cached credentials and software licence seats.
4. **Revoke** any tokens or device certificates tied to the previous holder.
5. **Update** the asset record with the new holder and the wipe date.

The handover ticket should be the only route. Nobody collects a laptop from a desk drawer and passes it on with a hopeful message.

Scale changes the mechanism, not the rule. At 25 staff, a checklist on the handover ticket is enough. At 250, handovers are frequent enough that tooling should enforce the wipe, as the automation section below shows.

## What about asset tags, leased printers, CCTV and door controllers?

Before equipment leaves your control, remove asset tags, hostname labels and classification markings so a lost device cannot be attributed to you. Also decommission hidden storage: leased copiers and printers with internal drives, CCTV recorders and door-access controllers hold user lists and footage. Office moves are the usual trigger.

Labels matter. A drive found in a skip with your asset tag and hostname label on it turns an anonymous loss into an attributed one. It also hands a social engineer props for the follow-up call.

Remove these before anything is released:

- Asset tags and company stickers.
- Hostname labels.
- Classification markings.
- The same marks on donated and resold kit, where the wipe feels like the end of the job.

Hidden storage is the second blind spot. Check these at every office move or lease end:

- **Leased copiers and multi-function printers** with internal drives, which the lessor collects on a date that arrives before anyone thinks of the contents.
- **CCTV recorders** holding footage.
- **Door-access controllers** holding user lists.
- **NAS boxes, phones and tablets** that sit outside the laptop process.

An office move should trigger a check of access-control and camera kit. The next tenant should not inherit your user lists or footage. For leased equipment, ask the supplier in writing how drives are wiped, or arrange the wipe before collection.

Put label removal on the same ticket as the wipe, and keep the checklist note as evidence.

## How do you stop a hardware graveyard building up?

Treat "retired" as a state with a deadline, not a destination. Retired devices left in a cupboard with unknown contents and no owner become unmanaged risk, and auditors will open that cupboard. A scheduled query for assets in retired state with no disposal outcome after a set number of days surfaces them automatically.

Graveyards form for ordinary reasons. Nobody owns the next step, a lessor deadline slips, or someone thinks the spare might be handy. If a device then goes missing, you cannot say what it held.

A retired laptop in a cupboard has not been disposed of. It has been postponed.

The fix has four parts:

- **Add a retired state** to the register, date-stamped on entry.
- **Set a deadline** for a disposal outcome, in a number of days you choose.
- **Schedule the query** that flags retired assets past that deadline and sends them to the register owner.
- **Clear the backlog once.** Record every serial in the cupboard, then wipe or destroy the batch through your ITAD vendor.

The cupboard then becomes a dashboard item with a name against it. That is a far easier conversation than the one with an auditor holding the door open.

## How does an auditor test Annex A 7.14, and how is it graded?

Auditors trace one or two disposals from asset register to itemised certificate. They check a reassigned device for evidence of its wipe, and walk round the storage cupboard. Hardware that left with recoverable sensitive data grades major; register gaps, a missing batch certificate or labels left on donated kit grade minor, adding up to major as a pattern.

Expect questions like these:

- "Pick any laptop you disposed of this year. Show me what happened to its drive."
- "What do you do to a machine before it moves from one employee to another?"
- "Where are your destruction certificates, and do the serials match your register?"
- "What's in that cupboard?"
- "If you moved out next month, what would you do with the door system and the cameras?"

Sampling also covers the ITAD vendor's paperwork and vetting. Returned lease equipment is a favourite line of questioning, because deadline pressure makes shortcuts likely.

On grading, certification bodies treat hardware that left with sensitive data plausibly recoverable as the total-breakdown case, and breach-notification questions follow. A single missing batch certificate stays minor until the same gap repeats across the sample.

Rehearse this evidence set before the audit:

- The disposal section of your policy or IT procedures.
- A register extract showing retired and reassigned items with their disposal outcome.
- Wipe or sanitisation logs from your tooling.
- Itemised ITAD certificates whose serials reconcile to the register.
- The vendor's due-diligence file and a note evidencing tag and label removal.
- Re-image records tying each handover to a wipe.

An auditor who picks a retired laptop and asks where it physically went should get an answer in minutes.

## How do you automate Annex A 7.14 evidence with MDM and scripted reconciliation?

Automate the chain of custody so nobody has to remember it. A retirement in the register raises a ticket that cannot close without a wipe log or certificate; a script matches certificate serials to the register; MDM enforces full-disk encryption and logs re-enrolment wipes, turning the audit trail into a standing report.

Four pieces do the work:

- **Gated disposal ticket.** The chain of custody is enforced by the process, not remembered by a person.
- **Scripted reconciliation.** Unmatched retirements surface as exceptions, so the audit reconciliation is a report you can run on any day.
- **Encryption enforced by MDM.** Full-disk encryption runs across the fleet, with compliance reported all the time. Every compliant device then has an end of life that is already half solved.
- **Re-enrolment as a wipe.** Routing handovers through MDM makes the wipe-and-rebuild a logged side effect of giving hardware to the next person.

An MDM encryption compliance export is evidence for two controls at once: Annex A 7.14 and Annex A 8.24. Add the graveyard query from the previous section. The register then shows, on any day, which retirements are open, which are closed with proof and which are overdue.

GRCMANA's GRC engineering work builds exactly this: the gated workflow, the reconciliation script and the retired-asset exception report. The audit question "where did this laptop go?" is then answered by a report, not by someone's memory.

## Frequently asked questions

### Can we donate old laptops to charity under Annex A 7.14?

Yes, provided the wipe is verified, every company tag and label is removed and the batch is recorded by serial number. If the charity offers to wipe the machines itself, you still carry the responsibility, so get its confirmation in writing per device. An unwiped donation is a breach with a photo opportunity.

### Who should own secure disposal or re-use of equipment in a 50-person firm?

The asset register owner owns the outcome but can share out the tasks. The office manager can book collections and handle handovers, and the ITAD vendor does the destruction, but only the owner closes a register entry. Add a named deputy so a holiday does not leave a retirement ticket open for weeks.

### What changed between A.11.2.7 in ISO 27001:2013 and A.7.14 in the 2022 edition?

A.7.14 is the successor to A.11.2.7. Its 2022 guidance now explicitly expects identifying markings to be removed, and physical security kit, such as door controllers and cameras, to be dealt with when you leave a site. If your 2013-era procedure only covers laptops and servers, extend it to cover office moves.

### How does A.7.14 apply to leased equipment returned to the lessor?

A lease return is a disposal with a fixed deadline. Record the return date in the register and raise the wipe ticket well before the collection date, for example 30 days ahead. Check the lease terms for printers and copiers early, and keep the lessor's collection receipt with the serial numbers listed.

### Should damaged devices be repaired or destroyed under A.7.14?

Make a documented risk call. If the device cannot be wiped and you cannot guarantee what its storage holds, destroy it rather than send it for repair. Where repair is worth it, remove the drive first if the design allows, or confirm the drive was encrypted with keys held elsewhere.
