The entity discontinues logical and physical protections over physical assets

To meet the the entity discontinues logical and physical protections over physical assets requirement, you must have a repeatable offboarding and disposal process that removes access, credentials, configurations, and facility protections from physical assets at end of life, reassignment, return, or decommission. Auditors will look for proof that protections are removed promptly, consistently, and completely across IT, facilities, and third parties.

Key takeaways:

• Treat “discontinue protections” as an end-to-end asset lifecycle control, not an IT-only task.
• Build a single workflow that covers logical access removal, physical access removal, secure sanitization, and disposition documentation.
• Evidence matters as much as process; retain tickets, logs, inventories, chain-of-custody, and sanitization certificates mapped to asset IDs.

This SOC 2 requirement sits in a place many teams under-engineer: the “last mile” of asset lifecycle. Most organizations can show they provision laptops, badge access, and system accounts. Fewer can prove they consistently remove protections and access pathways when assets are retired, reassigned, shipped, returned by a remote worker, or sent to a recycler. That gap becomes a real audit problem because the risk is concrete: orphaned credentials, devices that still contain sensitive data, lost hardware that remains enrolled in management systems, or physical controls that still grant access to spaces and equipment.

Operationalizing this requirement means designing a closed-loop process that starts with an inventory and ends with disposition, with checkpoints for both logical and physical protections. The core move is to define trigger events (termination, replacement, hardware failure, end-of-lease, vendor return), route them through a single workflow, and produce evidence at each step. If you have third parties handling repairs, returns, storage, or disposal, the process must extend to them through contract terms and chain-of-custody records.

Source of record for the requirement is the Trust Services Criteria. ¹

Regulatory text

Requirement (SOC 2 Trust Services Criteria, CC6.5): “The entity discontinues logical and physical protections over physical assets.” ¹

What an operator must do

You must ensure that when a physical asset is no longer authorized for use (retired, reassigned, returned, destroyed, or otherwise removed from service), you:

1. Remove logical protections and access paths tied to that asset (accounts, certificates, API tokens on the device, device management enrollment, VPN profiles, Wi‑Fi credentials, local admin rights, encryption keys under your control, remote access tooling).
2. Remove physical protections and access paths tied to that asset (badges/keys granting access to rooms, cages, racks; access lists for labs; visitor/contractor permissions tied to equipment custody; any physical locking mechanisms you control).
3. Prevent residual risk from the asset itself by controlling its disposition (secure wipe/sanitization, verified destruction, controlled resale, or return to lessor/manufacturer) and documenting chain-of-custody.

SOC 2 does not mandate one method. It does require that your method is designed, consistently executed, and evidenced.

Plain-English interpretation of the requirement

When you stop using a physical asset, you must also stop treating it as “protected” inside your environment. That sounds backwards, but it’s how auditors read it: protections (logical and physical) are granted for a purpose. If the purpose ends, protections must be removed so the asset cannot be used as a backdoor later.

In practice, “discontinue protections” means:

• The device is no longer able to authenticate to your systems.
• Any privileged access that existed because of that device (local admin, device certificates) is revoked.
• Any facility or room access granted because of custody of the asset is removed.
• Sensitive data is removed or destroyed before the asset leaves controlled handling.

Who it applies to

In-scope entities

• Service organizations undergoing SOC 2 examinations under the Trust Services Criteria. ¹

In-scope operational contexts (where this breaks in real life)

• Endpoint lifecycle: laptops, desktops, mobile devices, tablets, test devices, and loaner pools.
• Infrastructure lifecycle: servers, network gear, removable media, hardware security modules, backup appliances.
• Facilities and lab environments: racks, cages, wiring closets, production floor equipment with embedded credentials.
• Remote workforce and returns: employee terminations, contractors, and international shipments.
• Third party custody: repair depots, managed IT providers, colocation operators, recycling vendors, lease return programs.

If an asset can store or grant access to customer data, production systems, or restricted spaces, it belongs in your control story for this requirement.

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

Step 1: Define scope and trigger events

Create a one-page standard that lists:

• Asset types covered (endpoints, servers, network gear, removable media, badges/keys tied to asset custody).
• Trigger events: termination, role change, device replacement, end-of-lease, lost/stolen, RMA/repair, datacenter decommission, office closure.

Operator tip: auditors will ask “how do you know you captured all assets?” Start with the inventory sources you already have (ITAM/MDM/CMDB, purchasing records, ticketing) and reconcile gaps.

Step 2: Establish a single workflow with required checkpoints

Use your ticketing system as the system of record. Your workflow should require completion evidence for:

1. Identity/access actions (logical):
   • Disable device accounts and certificates (where applicable).
   • Remove device from MDM and revoke compliance/conditional access.
   • Rotate or revoke any credentials stored on the asset (VPN profiles, SSH keys, service accounts used for automation on that box).
2. Data protection actions (logical/cryptographic, tied to the asset):
   • Verify encryption state before wipe.
   • Perform secure wipe/sanitization or destruction based on disposition path.
3. Facilities actions (physical):
   • Remove badge access to areas tied to device custody if applicable (labs, cage access).
   • Recover keys, locks, cable locks, and remove from access lists for equipment rooms.
4. Disposition actions:
   • Return to lessor/manufacturer with confirmation, or ship to recycler with chain-of-custody.
   • For destroyed assets, retain certificate of destruction or internal destruction record.

Step 3: Assign RACI and make approvals explicit

Document who does what:

• IT Operations: MDM removal, wipe, reimage, credential revocation tasks.
• Security: defines sanitization standard, approves exceptions, reviews samples.
• Facilities: badge/key removals, physical access list updates.
• HR: provides termination triggers.
• Procurement/AP: lease returns and recycler engagement.
• Third party owners: ensure third party returns/disposal meet requirements.

One common hangup: no one “owns” badge removal for contractors. Put it in Facilities RACI with an HR or vendor management trigger.

Step 4: Implement disposition decisioning (reuse vs dispose vs return)

Create a short decision matrix used inside the workflow:

Disposition path	Minimum required actions	Evidence to retain
Reassign internally	wipe/reimage, revoke old profiles, update inventory owner/location	ticket + wipe log + inventory update
Return (lease/RMA)	sanitize per policy, confirm shipment/receipt, remove from inventory	ticket + shipping record + confirmation + inventory update
Dispose/recycle	sanitize or destroy, chain-of-custody, recycler attestation	ticket + chain-of-custody + certificate
Lost/stolen	remote wipe attempt, revoke access, incident record, inventory status	incident/ticket + access revocation logs + inventory mark

Step 5: Extend to third parties with contract + operational controls

Where a third party touches assets (repair, storage, disposal):

• Put disposal/sanitization requirements in the contract or SOW.
• Require disposition reporting (asset IDs, dates, method).
• Reconcile their reports to your inventory.

You do not need perfection; you need a defendable control and evidence that you enforce it.

Step 6: Build an evidence pack that matches how auditors test CC6.5

SOC 2 testing commonly follows: “show me the policy, show me the workflow, show me sampled tickets, show me logs.” Prepare:

• Control narrative (what happens, who does it, when, tools used).
• Population definition (what assets are in scope, where list comes from).
• Sample-ready artifacts (tickets and logs).

Daydream can help by centralizing your control narrative, linking tickets/logs as operating evidence, and keeping a consistent evidence trail across IT, Facilities, and third parties without rebuilding your process every audit cycle.

Required evidence and artifacts to retain

Keep artifacts tied to a unique asset identifier (serial number, asset tag, device ID) and a workflow record (ticket ID).

Minimum evidence set:

• Asset inventory record showing status change (active → retired/reassigned/returned/destroyed).
• Ticket or workflow record with completion timestamps and assignees.
• Logical access removal proof, such as:
  • MDM/endpoint management removal record,
  • directory/device disablement logs,
  • evidence of certificate revocation or profile removal where used.
• Sanitization/destruction evidence:
  • wipe logs, reimage confirmation, or destruction certificate,
  • chain-of-custody record for assets leaving your site.
• Physical access updates:
  • badge access removal record for restricted areas (where applicable),
  • key return logs or access list updates for labs/cages.
• Third party disposition reporting (if third parties handle return/disposal).

Common exam/audit questions and hangups

Auditors tend to get specific. Expect:

• “How do you define the population of physical assets in scope for CC6.5?”
• “Show a sample of retired devices and prove logical access was removed.”
• “How do you know devices returned by remote staff were sanitized before disposal?”
• “What controls apply when a third party performs repairs or disposal?”
• “How do you handle exceptions (broken devices, emergency replacements, lost/stolen)?”

Hangups that create findings:

• Inventory says “retired,” but no ticket or wipe record exists.
• Tickets exist, but they do not show revocation of device-based access (MDM, certificates, VPN profiles).
• Recycler certificate does not map to your asset IDs, so you cannot prove the specific assets were destroyed.

Frequent implementation mistakes (and how to avoid them)

1. Treating decommission as “delete from MDM” only
   Fix: require a checklist that includes credential revocation and sanitization evidence tied to the asset ID.

2. No trigger from HR and Procurement
   Fix: integrate terminations and lease end-of-life into the same workflow intake. If you cannot automate, require weekly reconciliations between HR terminations and open retrieval tickets.

3. Weak chain-of-custody for offsite disposal
   Fix: require shipping documentation, receiving confirmation, and recycler disposition reports that list serial numbers or asset tags.

4. Facilities controls live outside the control narrative
   Fix: add badge/key removal steps into the same ticket or an explicitly linked child ticket.

5. Exceptions become the default path
   Fix: add an exception type that requires Security approval and compensating controls (e.g., revoke access immediately, hold asset in locked storage until destruction).

Enforcement context and risk implications

SOC 2 is an attestation framework, so this requirement is usually “enforced” through audit findings and customer trust impacts rather than regulator penalties. The operational risk is straightforward:

• A disposed device with residual data becomes a data security incident.
• A “retired” server still reachable on a network becomes an unmonitored ingress path.
• Physical access not removed creates unauthorized entry risk, especially in shared facilities.

Even without public enforcement cases in the SOC 2 source materials provided, audit exceptions tied to asset disposal often escalate quickly because they are easy to explain to non-technical stakeholders: “You lost track of devices and data.”

30/60/90-day execution plan

Days 0–30: Stabilize the control design

• Define in-scope asset types and trigger events.
• Write a short standard operating procedure (SOP) for decommission/return/disposal.
• Create a single ticket template with mandatory fields: asset ID, disposition path, wipe method, physical access updates, evidence attachments.
• Identify third parties involved (repair, disposal, storage) and list required reports/artifacts.

Deliverables:

• CC6.5 control narrative (draft)
• Ticket templates/checklists
• Evidence map (what you will show an auditor)

Days 31–60: Implement workflow + evidence capture

• Roll out the workflow to IT Ops, Security, Facilities, and Procurement.
• Run a reconciliation between inventory and “retired” tickets; close gaps with corrective actions.
• Pilot with a small sample of real decommissions and validate you can produce evidence quickly.

Deliverables:

• Completed tickets with attached logs/certificates
• Inventory reconciliation report and remediation notes
• Third party disposition reporting process (even if manual)

Days 61–90: Operationalize and harden

• Add management review: periodic sampling of completed dispositions for completeness and evidence quality.
• Formalize exception handling with Security approval.
• Update contracts/SOWs for disposal and repair third parties to require serial-level reporting.
• Prepare an “audit-ready” evidence bundle for a defined period.

Deliverables:

• Review records (sampling results, remediation actions)
• Exception register with approvals
• Audit-ready evidence pack aligned to CC6.5

Frequently Asked Questions

Does “discontinues logical and physical protections” mean I should remove encryption and passwords?

It means you must remove the asset’s ability to access systems and ensure data is not left exposed when the asset leaves controlled use. In many cases, that includes wiping data and revoking device enrollment, certificates, and stored access profiles.

How do we handle assets returned by remote employees?

Treat remote returns as higher-risk handling: require a ticket, shipping/receipt documentation, and wipe/destruction evidence after receipt. If the device cannot be recovered, document the revocation actions (MDM lock/wipe attempt, access revocation) and mark inventory accordingly.

Are badges and keys really part of this requirement?

If physical access is part of how the asset is protected or accessed (labs, cages, equipment rooms), removing that access is a direct fit for “physical protections.” Auditors will expect Facilities actions to be reflected in your control narrative and evidenced.

What evidence is strongest for secure disposal?

Evidence that ties disposition actions to specific asset IDs is strongest: wipe logs mapped to serial numbers, chain-of-custody forms listing asset tags, and certificates of destruction that list identifiers you can reconcile to inventory.

Our recycler won’t provide serial-number-level certificates. What do we do?

Add serial-level reporting as a contractual requirement for in-scope assets, or change providers for those assets. If you must proceed, define compensating controls such as witnessed destruction for high-risk assets and retain internal records that link assets to the destruction event.

How do we prove logical protections were discontinued for a decommissioned server?

Show the decommission ticket, inventory status change, access removal logs (account disablement, certificate revocation where applicable), and network changes that remove reachability. Keep evidence that the host is no longer monitored as “in service” and cannot authenticate to production systems.

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

Footnotes

1. AICPA TSC 2017