Safeguard 3.5: Securely Dispose of Data

Safeguard 3.5 requires you to securely dispose of data so it cannot be recovered when it is no longer needed, including on endpoints, servers, removable media, cloud storage, backups, and physical records. Operationalize it by defining disposal triggers, approved destruction methods per media type, execution ownership, and audit-ready evidence that each disposal event occurred as required ¹.

Key takeaways:

• Treat disposal as a lifecycle control with triggers (offboarding, decommissioning, retention expiry), not an ad hoc IT task ².
• Standardize approved methods by data sensitivity and media type, including cloud, backups, and paper ².
• Keep a tight evidence bundle: tickets, logs, certificates of destruction, and exception approvals mapped to assets and data sets ².

“Securely dispose of data” sounds simple until you try to prove it across SaaS, endpoints, data lakes, backups, and third parties. Safeguard 3.5: securely dispose of data requirement is about preventing residual data exposure: data that remains on a device, in a deprovisioned account, inside a snapshot, or in a box of paper records after the business thinks it is “gone.” That gap shows up during incidents, litigation holds, M&A diligence, and customer security reviews.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to convert this safeguard into a control that has (1) clear trigger events, (2) approved destruction standards per medium, (3) named operators and approvers, and (4) repeatable evidence. Your goal is not to debate perfect sanitization algorithms. Your goal is to demonstrate that the organization consistently disposes of data in a way that is appropriate for the medium and sensitivity, and that exceptions are rare, approved, and time-bound ².

This page gives you a requirement-level runbook you can hand to IT, Security, Legal, and Procurement, then audit without heroics ¹.

Regulatory text

Framework requirement (excerpt/summary): “CIS Controls v8 safeguard 3.5 implementation expectation (Securely Dispose of Data).” ¹

Operator interpretation (what CIS is asking you to do)

You must ensure that when data is no longer required, it is disposed of in a way that prevents unauthorized recovery. That includes:

• Digital data on endpoints, servers, removable media, storage arrays, and cloud services.
• Copies such as exports, staging files, logs, and backups.
• Physical records that contain sensitive data (for many organizations, this includes printed HR, finance, and customer support records).

CIS does not require you to adopt a single technical method for every scenario. CIS expects you to pick methods that match the data sensitivity and media type, and to run the process consistently with provable results ².

Plain-English requirement summary

Dispose of data securely and verifiably once it is no longer needed. “Securely” means a reasonable attacker (or a curious employee) cannot recover the disposed data from the original medium or service. “Verifiably” means you can show who did it, when, to what asset or system, using which method, and under what approval ².

Who it applies to

Entities

• Enterprises of any size
• Service organizations (including SaaS, managed services, and shared services)
• Technology organizations ¹

Operational contexts that must be in scope

Include these in scope explicitly, because they are where disposal programs fail in practice:

• Joiner/mover/leaver workflows (account deprovisioning, mailbox and drive data handling)
• Asset lifecycle (laptops, mobile devices, servers, network gear, removable media)
• Cloud lifecycle (SaaS deprovisioning, object storage deletion, snapshots, data warehouse tables)
• Backup and DR (backup retention expiry, media rotation, restore testing artifacts)
• Third parties handling your data (records storage, shredding, ITAD, cloud providers, MSPs)
• Legal holds and investigations that pause deletion

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

Step 1: Define disposal triggers (the “when”)

Create a short list of trigger events that force secure disposal actions:

• Data retention period ends for a dataset/record category
• Employee/contractor offboarding (for user-held and user-generated data)
• System decommissioning or migration cutover
• Device replacement/return (including BYOD exit where allowed)
• End of third-party contract and return/destruction obligations

Put these triggers into your control card so disposal is scheduled work, not a best-effort clean-up ².

Step 2: Classify disposal obligations by data and medium (the “what”)

Build a disposal matrix with two axes:

• Data sensitivity (example tiers: Public, Internal, Confidential, Regulated)
• Media/service type (endpoint drive, mobile, removable media, paper, SaaS account, object storage, database, backups)

Output: a one-page table that tells operators what method is approved for each cell.

Step 3: Standardize approved destruction methods (the “how”)

Define approved methods per medium. Keep it practical, and tie each to evidence:

• Endpoints/servers/storage: cryptographic erase where supported, secure wipe, or physical destruction through ITAD.
• Removable media: physical destruction or verified wipe.
• Paper: shredding via approved process or vendor with certificates.
• Cloud/SaaS: administrative deletion plus verification (audit logs, provider evidence, export of deletion report), and awareness of retention features (eDiscovery, vaults, recycle bins).
• Backups: enforce retention expirations and document how “deletion” works for immutable storage and snapshots.

Your policy should specify that ad hoc “delete key files and hope” is not an approved method for sensitive data.

Step 4: Assign ownership and approvals (the “who”)

You need named roles, not a generic “IT” assignment:

• Control owner (accountable): typically Security GRC or IT Risk.
• Operators (responsible): IT Operations for devices/servers, Cloud/SaaS admins for services, Records Management for paper, and Backup admins for DR platforms.
• Approvers: data owner or system owner; Legal for hold exceptions; Security for method exceptions.
• Third-party manager: Procurement/TPRM for vendor oversight and contract enforcement.

This is the point where many programs fail: everyone agrees disposal matters, but nobody owns the evidence ².

Step 5: Implement execution mechanics and tooling (the “do it”)

Operationalize disposal with work you can track:

1. Create a disposal request or ticket type with required fields: asset ID/system, data category, trigger event, method, operator, approver, due date, evidence attachments.
2. Integrate with asset inventory so device disposal cannot close without a destruction record.
3. Integrate with identity/SaaS workflows so offboarding triggers mailbox/drive disposition steps (transfer, archive, delete) aligned to retention and legal hold rules.
4. Implement verification: spot checks, log reviews, or vendor certificate reconciliation. Verification must be a separate step from “I ran a script.”
5. Track exceptions: legal holds, eDiscovery retention, broken media, air-gapped backups. Require time bounds and compensating controls.

Step 6: Build the minimum evidence bundle (what auditors will ask for)

Define, in advance, what “proof” looks like for each disposal pathway ²:

• Ticket or workflow record with approvals
• System logs or admin reports showing deletion/wipe event
• Inventory update showing asset disposition
• Certificate of Destruction (paper and hardware), mapped to serial numbers
• For cloud/SaaS: admin audit logs, deletion reports, configuration screenshots for retention settings where applicable
• Exception approvals and legal hold notices when deletion is paused

Store evidence in a controlled repository with consistent naming (system, date, asset/data set, method).

Step 7: Run control health checks and remediate gaps

Set an operating rhythm:

• Review a sample of completed disposal events for evidence completeness.
• Reconcile disposed assets vs. certificates.
• Reconcile offboarding list vs. disposed user data actions.
• Track findings to closure with owners and due dates ².

Required evidence and artifacts to retain

Use this as your evidence checklist.

Artifact	What it proves	Owner
Disposal & Sanitization Standard (policy/procedure)	Approved methods per medium and sensitivity	Security/GRC
Disposal trigger list + RACI	Who acts, when, and who approves	Security/GRC + IT
Disposal tickets/workflow exports	Disposal events occurred and were approved	IT Ops / SaaS Admins
ITAD/shredding contracts + DPAs/SOWs	Third-party obligations for destruction	Procurement/TPRM
Certificates of Destruction + serial mapping	Hardware/paper destruction occurred	IT Ops / Records
Cloud/SaaS audit logs or deletion reports	Logical deletion performed	Cloud/SaaS Admins
Backup retention configuration evidence	Backups expire per policy	Backup Admins
Exception register (legal hold, technical constraints)	Controlled deviations	Legal + Security

Common exam/audit questions and hangups

Expect these, and prepare your evidence set to answer them quickly:

• “Show me how you decide when data is disposed of.” Auditors want triggers tied to retention and lifecycle events ².
• “Which systems are in scope, including backups and SaaS?” The hangup is usually shadow SaaS and unmanaged backups.
• “Prove that decommissioned devices were sanitized.” They will ask for serial-number-level traceability.
• “How do legal holds change deletion?” Auditors look for a formal exception path with Legal approval.
• “How do you oversee third parties that destroy data?” They want contracts plus certificates and reconciliation, not only a vendor attestation.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. A policy that says “we securely dispose” with no workflow, triggers, or evidence fails basic diligence. Fix: implement ticketing and evidence requirements ².
2. Ignoring backups and snapshots. Teams delete production data but keep it in backups indefinitely. Fix: define backup retention and disposal mechanics explicitly.
3. No asset-to-certificate mapping. A pile of certificates with no link to inventory is weak proof. Fix: require serial number mapping at ticket closure.
4. SaaS recycle bins and retention features left on by default. Deleting a user may not delete their data. Fix: document per-SaaS deletion behavior and retention settings, then capture admin evidence.
5. Third-party destruction treated as “their problem.” If a third party loses your media, you own the outcome. Fix: contract clauses, due diligence, and operational reconciliation.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific actions.

Risk-wise, disposal failures often surface as:

• Post-termination access to residual user data
• Data exposure from resold/returned devices
• “Deleted” customer data found in old exports or backups during incidents
• Contract breaches when a customer requires certified destruction at end of service

Treat disposal as a data governance and incident-prevention control, not only an IT hygiene task ².

Practical 30/60/90-day execution plan

You asked for speed. Use this phased plan; adjust sequencing based on your asset footprint and regulatory exposure.

First 30 days (stand up the control)

• Publish a one-page control card: objective, owner, triggers, scope, methods, exception rules ².
• Build the disposal matrix (data sensitivity x medium) and get Security + IT + Legal sign-off.
• Add a ticket/workflow template with required evidence fields.
• Identify third parties involved in destruction and confirm contract coverage (certificates, timelines, audit rights).

By 60 days (make it run end-to-end)

• Roll out disposal workflows for the highest-risk paths: offboarding, endpoint returns, and paper destruction.
• Implement evidence capture and central storage conventions.
• Create an exception register for legal holds and technical constraints with explicit approvers.
• Run a first control health check on a sample of completed events; open remediation items ².

By 90 days (prove it and harden it)

• Expand scope to cloud/SaaS and backup retention evidence.
• Reconcile asset inventory against destruction evidence for a full period.
• Add recurring reviews and metrics that are operational (for example: overdue disposal tickets, missing certificates), not vanity dashboards.
• If you need a system to keep control cards, evidence bundles, and remediation tracking in one place, Daydream can act as the operating layer so disposal stays auditable without spreadsheet sprawl ².

Frequently Asked Questions

Does “securely dispose” mean physical destruction every time?

No. You choose a method appropriate to the data sensitivity and media type, then prove it happened. For some media and risk levels, verified wipe or cryptographic erase is appropriate; for others, physical destruction is the cleanest option ².

How do we handle legal holds that prevent deletion?

Treat legal hold as a formal exception with Legal approval, scope (systems/data sets), and release criteria. Keep a hold register so auditors can see why disposal was paused and who authorized it ².

What’s the minimum evidence for SaaS data disposal?

Keep the deprovisioning/deletion ticket, the approver, and SaaS admin audit logs or a deletion report that ties the action to the user/account/data set. Add configuration evidence when retention settings or recycle bins affect deletion behavior ².

Are backups in scope even if we can’t delete a single customer’s data from them?

Yes, backups are in scope for disposal. If granular deletion is not feasible, enforce retention limits, document the technical constraint, and show that expired backups are destroyed or aged out per configuration and process ².

How do we manage disposal when a third party destroys devices or paper?

Put requirements in the contract (certificates, chain of custody, audit rights), then reconcile certificates to your inventory or box/asset lists. Evidence should show what was destroyed, when, and by whom, not only that the third party “has a process” ².

What should we do about “temporary” exports and analyst extracts?

Treat them as data stores with owners, retention, and disposal triggers. Require storage in approved locations, block long-lived local copies where feasible, and enforce deletion through scripts or access-controlled workspaces with retention controls ².

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8

2. CIS Controls v8