TSC-CC6.5 Guidance

The tsc-cc6.5 guidance requirement shows up in SOC 2 exams as a deceptively simple question: “What happens when you stop using an asset?” If your answer is “IT recycles laptops” or “Facilities handles badges,” you are exposed. TSC-CC6.5 expects a controlled end-of-life workflow that discontinuates protections in a deliberate, auditable way, so retired assets do not become an untracked source of data leakage or unauthorized access.

This is broader than laptops. It covers physical servers, removable media, network gear, mobile devices, printed records, and any physical asset that can hold sensitive data or provide a path into your environment. It also applies when assets leave your custody temporarily, such as loaners, repairs, returns to a leasing company, or shipments to a third party for destruction.

For a CCO or GRC lead, the fastest path is to define “disposition events,” assign owners (IT, Security, Facilities, Procurement), create minimum steps per asset class, and build an evidence pack that matches how SOC 2 auditors test controls: policy, tickets/records, and periodic review. Source: AICPA Trust Services Criteria 2017 [TSC-CC6.5] (AICPA TSC 2017, 2017).

Regulatory text

Excerpt (TSC-CC6.5): “The entity discontinues logical and physical protections over physical assets.” (AICPA TSC 2017, 2017)

What this means operationally

You must have a defined, repeatable process for ending protections appropriately when a physical asset changes state (retired, transferred, lost, returned, sold, destroyed). “Discontinues protections” does not mean “stop caring.” It means you intentionally close out the protection lifecycle by:

• preventing further access pathways (logical access like credentials, keys, device management profiles),
• preventing unauthorized physical access (badges/keys, cages, storage rooms),
• preventing data exposure (sanitization, destruction, verified disposal),
• and recording what happened so an auditor can trace it.

Plain-English interpretation (what the auditor is really testing)

Auditors typically test whether your organization can answer, with evidence:

1. Which physical assets are in scope and who owns them?
2. What triggers decommissioning and who approves it?
3. What specific steps happen to remove data and access?
4. How do you prove it happened for real assets during the audit period?
5. How do you prevent “shadow disposals” (ad hoc giveaways, desk drawer drives, forgotten media)?

If you cannot show consistent records (tickets, certificates of destruction, revocation logs), you will struggle to demonstrate the control operated throughout the period.

Who it applies to

Entity scope

• Any organization undergoing a SOC 2 audit that includes the Common Criteria. (AICPA TSC 2017, 2017)

Operational context (where it shows up)

• Corporate IT (laptops, phones, tablets, peripherals with storage)
• Infrastructure/Operations (servers, network appliances, HSMs, backup devices)
• Security (encryption keys, device identities, certificates, secrets)
• Facilities/Physical security (badges, keys, racks, cages, storage rooms)
• Procurement/Finance (asset tracking, leasing, returns, disposal vendors)
• Third parties (repair shops, disposal/destruction providers, colocation operators)

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

Use this as a build sheet for your control and procedure.

Step 1: Define “disposition events” and asset classes

Create a short list of events that require a controlled process:

• Retire/end-of-life
• Reassignment to another user/team
• Return to lessor/manufacturer
• Shipment for repair/RMA
• Loss/theft
• Disposal/destruction
• Donation/sale

Define asset classes with different handling rules:

• End-user devices (laptop/mobile)
• Removable media (USB, external drives)
• Data center hardware (servers, storage arrays)
• Network/security appliances
• Printed records and labels
• “Non-obvious storage” (copiers, badge printers, IoT, lab devices)

Deliverable: Asset Disposition Standard (one to two pages) mapping events + asset classes to required steps.

Step 2: Establish minimum required actions (a “disposition checklist”)

For each asset class, set minimum actions across three lanes:

A) Data handling

• Confirm encryption status and whether crypto-erase is permitted
• Perform secure wipe/sanitization or physical destruction as appropriate
• For printed material: shred/bin with secure destruction

B) Logical access removal

• Remove from MDM/endpoint management and revoke device certificates
• Disable associated accounts, API tokens, SSH keys, service accounts tied to the asset
• Rotate or revoke secrets stored on the device (local keys, cached credentials)
• Update inventory/CMDB status to “disposed/retired/transferred” so it drops out of monitoring scope intentionally

C) Physical control close-out

• Remove facility access if the event is termination or role change (badge deprovisioning belongs in the same control family)
• For stored assets: move to secure holding area pending destruction/return, with access logged
• Maintain chain-of-custody for transfers to third parties

Deliverable: Disposition checklists embedded in your ticketing workflow (recommended) or as controlled forms.

Step 3: Route all disposals through a tracked workflow

Pick one system of record (ticketing, GRC workflow, or ITSM). Require:

• unique asset identifier (tag/serial),
• disposition event type,
• approver (manager/IT/security),
• steps completed with timestamps,
• attachments (wipe logs, destruction certs, shipping receipts).

Practical tip: treat “untracked disposal” as an incident. If someone hands a laptop to a recycler without a record, force a retroactive ticket and root cause.

Deliverable: Workflow + required fields and a report you can export for the audit period.

Step 4: Control third-party involvement (disposal, shredding, repair)

When a third party touches your physical assets:

• Contractually require secure handling and documented destruction/sanitization.
• Require evidence (certificate of destruction, serial lists, service reports).
• Define chain-of-custody expectations (sealed containers, tamper-evident practices if you use them, receiving confirmation).

Keep this aligned with your third-party risk process. If you already assess third parties, add “asset handling/disposal” to the due diligence questionnaire and contract checklist.

Deliverable: Approved disposal/provider list + contract clauses + evidence intake process.

Step 5: Monitor and review (prove the control runs)

Set an owner to review disposition activity for completeness:

• reconcile asset inventory changes against disposal tickets,
• spot-check that wipe/destruction evidence exists,
• confirm exceptions are documented and approved.

Deliverable: Periodic review record (export + sign-off) and exception log.

Step 6: Test control effectiveness (SOC 2 readiness)

Before the audit, run an internal test:

• Select a sample of disposed/transferred assets from across the period.
• Trace each from inventory record → ticket → evidence attachments → final status change.
• Document findings and remediation.

Deliverable: Control test worksheet and remediation tickets.

Required evidence and artifacts to retain

Auditors typically ask for proof that the control exists and operated. Build an evidence pack you can produce quickly:

Policy and procedure

• Asset management policy section covering retirement/disposal
• Asset disposition procedure (by asset class)
• Third-party disposal/repair handling procedure

Operational records (by asset instance)

• Disposal/decommission tickets with required fields completed
• Inventory/CMDB export showing status changes (active → retired/disposed/transferred)
• Data wipe logs or screenshots from endpoint tools (where available)
• Certificates of destruction, serial-number lists, and vendor pickup receipts
• Shipping tracking and receiving confirmations for returns/RMAs
• Chain-of-custody logs for sensitive media (if used)

Oversight and assurance

• Periodic review sign-off record and exception log
• Internal test results and remediation evidence

Common exam/audit questions and hangups

Use these to prep your control narrative and evidence:

1. “Show me your process for disposing of laptops and drives.”
   Hangup: procedure exists but evidence is inconsistent across teams.

2. “How do you ensure devices are wiped before leaving your custody?”
   Hangup: relying on informal statements from IT or a recycler.

3. “How do you track assets shipped for repair or returned to a lessor?”
   Hangup: shipping receipts exist but no linkage to the asset record and no sanitization decision documented.

4. “What about printers/copiers and other devices with storage?”
   Hangup: asset inventory excludes “edge devices,” so disposal controls never trigger.

5. “How do you know an asset didn’t ‘disappear’ without following the process?”
   Hangup: no reconciliation between inventory write-offs and tickets.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails SOC 2 testing	Fix that works in practice
Policy says “sanitize before disposal,” but teams do ad hoc recycling	Auditor samples a few assets and finds missing wipe/destruction evidence	Make the ticket mandatory for inventory status change; block “retired” status without attachments
Treating “returned to vendor/lessor” as lower risk	Returns can still expose data if wipe is skipped or incomplete	Require a documented wipe decision for all outbound transfers
No chain-of-custody for drives/media	Media is easy to lose, and auditors ask for traceability	Use sign-out logs and sealed transfer containers for sensitive media
Inventory is incomplete (copiers, lab devices, network gear)	Control only covers what you track	Expand asset types in inventory, or maintain a separate “sensitive physical asset register”
No periodic review	You cannot show control operation over time	Assign a control owner and record recurring reviews with a saved export and sign-off

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, so you should treat TSC-CC6.5 primarily as an assurance expectation rather than a “fine-triggering” rule. (AICPA TSC 2017, 2017) The risk is still real: poorly controlled disposal is a common root cause of data exposure, loss of customer trust, and incident response cost. Your goal is to prevent an avoidable incident and avoid SOC 2 exceptions that slow sales cycles.

Practical 30/60/90-day execution plan

Days 0–30: Establish the control backbone

• Name owners: IT asset manager, Security reviewer, Facilities partner, Procurement partner.
• Define in-scope asset classes and disposition events.
• Draft and approve the Asset Disposition Standard and checklists.
• Configure the ticket workflow with required fields and attachment requirements.
• Identify third parties involved in repair/disposal and confirm evidence you can obtain.

Deliverables: approved procedure, workflow live, initial asset class coverage map.

Days 31–60: Start operating and collecting evidence

• Run the workflow for all new disposition events.
• Backfill tickets for any recent disposals that lack records (as exceptions).
• Set up a secure holding area process for devices pending wipe/destruction.
• Implement a simple monthly reconciliation: inventory retirements vs tickets.

Deliverables: first month of completed tickets with attachments, exception log, reconciliation output.

Days 61–90: Prove consistency and audit readiness

• Run an internal control test across several asset classes and event types.
• Fix failure patterns: missing attachments, unclear wipe decisions, weak chain-of-custody.
• Document your periodic review cadence and store review sign-offs.
• Prepare an “auditor-ready” evidence folder structure (policy, tickets, third-party certs, review records).

Deliverables: test results and remediation, repeatable evidence pack, clean narrative for the auditor.

Where Daydream fits (without creating more work)

Most teams fail TSC-CC6.5 on evidence retrieval, not intent. Daydream can act as the system of record for the control narrative, required artifacts, and recurring review tasks, so you can produce a traceable evidence pack on demand instead of rebuilding it during audit fieldwork.

Frequently Asked Questions

Does TSC-CC6.5 apply only to laptops and end-user devices?

No. Treat any physical asset that can store sensitive data or enable access as in scope, including servers, removable media, and devices like printers with storage. Your inventory and disposition workflow should reflect that breadth. (AICPA TSC 2017, 2017)

What counts as “discontinuing logical protections” for a disposed device?

Remove the device from endpoint management, revoke device certificates, and rotate or revoke credentials/secrets associated with that asset. Document these actions in the disposition record so an auditor can trace them to completion.

If a third party provides a certificate of destruction, is that enough?

It is strong evidence, but you still need linkage to your asset identifiers and proof that the asset left your custody through an approved workflow. Keep serial-number lists, pickup/receipt records, and the internal approval/ticket together.

How do we handle assets shipped for repair (RMA) where wiping isn’t possible?

Treat it as an exception path with documented risk decisioning: what data might be present, whether encryption is in place, and what chain-of-custody controls apply. Require approvals and retain shipping/receiving evidence.

What do auditors usually sample for this control?

They typically sample a set of assets that changed status during the audit period and trace each to supporting evidence. Plan for sampling across different asset types and different disposition events to avoid gaps.

We don’t have a formal CMDB. Can we still meet the requirement?

Yes, if you maintain a controlled asset inventory and can reconcile it to disposition records. The key is traceability from “asset existed” to “asset left custody or was retired” with evidence at each step.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management