Secure disposal or re-use of equipment

Secure media sanitization is one of those controls that fails quietly until it becomes a breach: a drive is decommissioned, a server is repurposed, or an RMA shipment goes out, and later someone discovers recoverable PII or unlicensed software on that device. ISO/IEC 27018:2019 Clause 11.2.7 is direct: equipment containing storage media must be verified to ensure PII and licensed software have been removed or securely overwritten prior to disposal or re-use (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

For a Compliance Officer, CCO, or GRC lead, the “hard part” is not the concept. It’s turning it into a repeatable operational flow that works across data center operations, IT asset management (ITAM), security, and procurement, including any third party that touches your retired assets. This page gives you requirement-level implementation guidance: scope decisions you must make, steps to execute, the evidence auditors expect, and the failure modes that cause audit findings.

Regulatory text

Requirement (verbatim): “All items of equipment containing storage media shall be verified to ensure that any PII and licensed software has been removed or securely overwritten prior to disposal or re-use.” (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)

Operator interpretation:
You need a control that (1) identifies any equipment with storage media, (2) sanitizes that media so PII is not recoverable, (3) removes licensed software, and (4) verifies sanitization occurred before the asset is disposed of or put back into service. “Verified” is the key audit word: you must be able to prove each asset followed the process, including assets processed by a third party.

---

Plain-English interpretation of the requirement

If a device can store data, assume it contains PII unless you can prove otherwise. Before you dispose of it, return it, sell it, recycle it, or redeploy it, you must do two things:

1. Data sanitization: Remove or securely overwrite any PII so it cannot be recovered with normal means.
2. Software/license hygiene: Remove licensed software so you are not transferring software you do not have rights to transfer.

Then you must verify and document that both happened.

---

Who it applies to (entity and operational context)

This requirement applies most directly to cloud service providers acting as PII processors (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). In practice, it touches any function involved in the equipment lifecycle:

• Data center operations / infrastructure: decommissioning hosts, storage arrays, network gear with flash storage, HSMs, backup appliances.
• Corporate IT: laptops, mobile devices, printers/MFPs with internal storage, conference room endpoints, thin clients.
• IT asset management (ITAM): asset inventory, disposition decisions, custody tracking.
• Security: sanitization standards, validation methods, exception handling.
• Procurement & Legal: third-party disposal contracts, RMA terms, licensing constraints.
• Third parties: ITAD providers, hardware manufacturers (RMAs), colocation operators, managed service providers that handle your equipment.

Operational contexts that create risk:

• Reuse/redeployment within your environment (highest volume, easy to get sloppy).
• Disposal via recycling or destruction (highest external exposure).
• Return to manufacturer (RMA/lease return) where you may lose custody before sanitization if the process is not controlled.

---

What you actually need to do (step-by-step)

Step 1: Define scope and decision rules

Create a written standard that answers, without ambiguity:

• What counts as “equipment containing storage media” (HDD/SSD, NVMe, flash modules, RAID controllers with cache, removable media, printer hard drives, BMC modules if applicable, etc.).
• What qualifies as secure overwrite vs. destruction for each media type.
• When encryption + key destruction is acceptable as sanitization in your environment (if you allow it, define how you prove encryption was enabled and keys were destroyed).
• How you address licensed software removal (imaging, secure wipe, license reclamation).

Output: a Media Sanitization & Equipment Disposition Standard mapped to ISO/IEC 27018:2019 Clause 11.2.7 (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

Step 2: Make the asset inventory “sanitization-ready”

Your CMDB/asset register must record, at minimum:

• Unique asset ID / serial number
• Asset type and media type(s)
• Location and owner/custodian
• Disposition path (reuse, recycle, destroy, RMA/return)
• Sanitization requirement flag (yes/no) and method options

Common control gap: teams track servers but not components (drives pulled from a chassis) or “non-obvious” storage (MFPs, network gear with flash).

Step 3: Implement a controlled chain of custody

Before any wipe or disposal event, you need a custody model:

• Who can authorize decommission and disposition
• Where assets are stored pending wipe/disposal (secure staging area)
• How assets move (ticketing, tamper-evident tagging where appropriate)
• How third parties receive assets (handoff record, approved transporter, documented receipt)

If you cannot prove custody, you cannot credibly prove sanitization occurred prior to disposal or re-use.

Step 4: Execute sanitization by disposition path

Use a runbook with checklists that operators follow.

A. Re-use / redeploy (internal)

• Confirm asset ID, media types, and wipe method required.
• Perform secure overwrite or other approved method.
• Remove licensed software and confirm reimaging baselines.
• Record wipe tool output/logs tied to asset ID.
• Independent verification step (see Step 5).
• Mark asset as eligible for redeploy in the asset system.

B. Disposal / recycling (external)

• Choose sanitization method (overwrite vs destruction) based on risk and practicality.
• Complete wipe or destruction before it leaves controlled custody, unless your standard explicitly allows third-party sanitization and you have strong contractual and evidentiary controls.
• Package and stage for pickup; document handoff and receipt.
• Obtain and review certificate of destruction/sanitization where applicable.

C. RMA / lease return This is where programs fail. You need a strict rule: sanitize before shipment unless you have a contractual and operational path to keep custody or guarantee sanitization with evidence.

• Validate whether the device contains storage media that will ship with it.
• If drives can be removed, pull and sanitize/destroy them; replace with blanks if required by the RMA.
• If drives cannot be removed, perform approved sanitization, then ship.
• Keep shipment tracking and acceptance records tied to the asset ticket.

Step 5: Verify and document (the “shall be verified” clause)

Verification must be more than “the tech said they wiped it.” Acceptable verification approaches vary by environment, but your process must produce a defensible record per asset. Examples of verification evidence:

• Wipe tool logs that show success status, method used, media identifier, and timestamp.
• A second-person check (four-eyes) recorded in the ticket.
• Spot-check recovery testing for defined high-risk categories (document the criteria and results).

Tie verification to a gating control: no asset changes status to “disposed” or “ready for reuse” until verification is complete.

Step 6: Integrate third parties into the control

If a third party performs transport, wipe, or destruction, treat them as part of your control boundary:

• Contract terms: sanitization requirements, evidence format, breach notification, subcontractor limits, audit rights.
• Operational controls: approved facilities, documented processes, chain-of-custody records.
• Intake QA: reject certificates that do not map to your asset IDs or lack key details.

Daydream can help here by centralizing third-party due diligence evidence and keeping disposition-related attestations, contracts, and chain-of-custody artifacts linked to the third party and the related internal control, so audits don’t turn into a scramble across procurement, security, and ITAM.

---

Required evidence and artifacts to retain

Auditors typically expect asset-level evidence plus program-level governance. Maintain:

Program-level artifacts

• Media Sanitization & Equipment Disposition Standard mapped to ISO/IEC 27018:2019 Clause 11.2.7 (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
• Roles and responsibilities (RACI) across ITAM, Security, Ops
• Approved tools/methods list and configuration baselines
• Third-party contracts and SLAs for ITAD/destruction providers (if used)
• Training/enablement records for staff who execute the runbook

Asset-level artifacts ¹

• Decommission/disposition ticket with approval
• Asset identifiers (serial, drive IDs) and media type
• Sanitization method used and date/time
• Wipe logs or destruction records tied to asset ID
• Verification record (second-person signoff or verification output)
• Chain-of-custody records (handoff forms, shipping receipts, tracking)
• Certificates of destruction/sanitization from third parties, mapped to your asset list

Retention period: align to your internal policy and contractual obligations; ISO/IEC 27018:2019 Clause 11.2.7 requires verification, not a specific retention duration (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).

---

Common exam/audit questions and hangups

Use these as your pre-audit checklist:

1. “Show me evidence for a sample of disposed assets.”
   Hangup: you have a certificate, but it doesn’t map to serial numbers.

2. “How do you know equipment with storage media is always captured?”
   Hangup: printers, network gear, lab devices, and loose drives aren’t in scope.

3. “What does ‘verified’ mean in your process?”
   Hangup: verification is informal or not documented.

4. “How do you handle RMAs and lease returns?”
   Hangup: the business ships first, asks questions later.

5. “How do you ensure licensed software is removed?”
   Hangup: sanitization focuses on PII only; license recovery is not addressed.

---

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating wipe logs as optional.
  Fix: make wipe output a required attachment to the disposition ticket; no log, no closure.

• Mistake: No gating control in ITAM/CMDB.
  Fix: enforce asset status transitions only after verification; build a simple workflow.

• Mistake: Relying on third-party certificates that are not asset-specific.
  Fix: require certificates that list your asset IDs/serials; reject mismatches.

• Mistake: Sanitization standards that don’t cover odd devices.
  Fix: maintain a living inventory of “storage-bearing equipment” categories and update it after incidents and audits.

• Mistake: Ignoring licensed software.
  Fix: add a licensing step to the runbook (reimage to baseline, reclaim licenses, confirm removal for devices leaving custody).

---

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is straightforward: failure can lead to unauthorized disclosure of PII through recoverable media, and can create licensing exposure if software is transferred without rights. From a governance standpoint, this control is often used as a proxy for whether a cloud provider can execute operational security consistently, because it requires cross-team coordination and reliable evidence.

---

Practical 30/60/90-day execution plan

First 30 days: Stabilize and stop the bleeding

• Publish a minimal sanitization standard covering the most common asset types and disposition paths, with explicit verification requirements aligned to ISO/IEC 27018:2019 Clause 11.2.7 (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors).
• Implement a mandatory disposition ticket workflow and require wipe logs or destruction evidence as attachments.
• Identify all third parties involved in disposal, transport, RMAs, or destruction; collect existing contracts and certificates.

By 60 days: Make it repeatable

• Expand the asset inventory fields needed for sanitization readiness (media type, method options, disposition path).
• Formalize chain-of-custody procedures and staging controls.
• Add verification as a distinct step with named approvers (separate from the person performing the wipe).
• Update third-party contract language and operational requirements for evidence mapping to your asset IDs.

By 90 days: Make it auditable at scale

• Run an internal audit-style sampling of recent dispositions; fix evidence gaps.
• Build reporting for open dispositions missing verification evidence.
• Train data center ops, IT support, and ITAM on the runbook; make compliance part of closure criteria.
• Centralize artifacts (tickets, logs, certificates, contracts) in a system of record; Daydream is a practical place to keep third-party evidence and disposition records tied to your control narrative for audits.

Frequently Asked Questions

Does this requirement apply only to disks, or also to devices like printers and network equipment?

It applies to “all items of equipment containing storage media,” so you must include any device that can store data, not only servers and laptops (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). Build a list of in-scope device categories and keep it current.

What does “verified” mean for auditors?

“Verified” should produce objective evidence per asset that sanitization occurred before disposal or re-use, such as wipe logs tied to serial numbers and a recorded approval step (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). A policy statement alone rarely satisfies this.

Can a third party perform the wipe or destruction?

Yes, but you remain accountable for meeting the requirement and proving verification before disposal or re-use (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). Require chain-of-custody documentation and certificates that map directly to your asset IDs.

How should we handle RMAs where the manufacturer wants the whole unit back?

Treat RMAs as high-risk because custody leaves your control. Prefer removing storage media and sanitizing it before shipment; if you must ship with media, sanitize first and retain shipment records and verification evidence.

Do we need to remove licensed software if we overwrite the drive?

Overwriting typically removes software as a byproduct, but you still need to address licensing explicitly because the requirement calls out “licensed software” separately (ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors). Document how your reimaging/wipe process prevents unlicensed transfer and how you reclaim licenses where relevant.

What evidence is most likely to fail an audit sampling test?

Certificates or logs that cannot be tied to the specific sampled asset, missing timestamps, or missing verification signoff are common failures. Design your workflow so assets cannot be marked disposed or ready for reuse until evidence is attached and reviewed.

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors