A healthcare company replaces encrypted laptops and sends the retired drives to a recycling vendor. An employee assumes the disks are safe because the operating system has been reinstalled; another assumes the presence of encryption makes every previous file irrecoverable forever. Neither conclusion is sufficient without knowing key custody, media technology, reuse requirements and the disposal evidence. ISC2 CISSP asset security follows sensitive information through the end of its life, including copies that are easy to forget.
The CISSP Asset Security domain includes classification, data lifecycle, retention, remanence and destruction. Asset security requires ownership, classification and retention decisions before any disposal step. This article addresses selection and proof of sanitization for physical and virtual storage, without pretending a single erase command suits every medium.
Classify information before choosing a disposal action
Identify whether the asset contains public, internal, confidential or regulated information under the organization’s actual scheme. Determine retention or legal-hold obligations, whether the media must be returned to a lessor, and whether the equipment will be reused internally or leave company custody. The authorized data owner should decide when information may be destroyed; an IT support ticket alone is not sufficient authority to delete records subject to an investigation.
Locate copies: endpoint caches, spare drives, virtual-machine snapshots, backup tapes, removable media and service provider replicas. Disposing of one physical device does not erase the business information if other copies still remain.
Distinguish clear, purge and destroy objectives
NIST SP 800-88 Revision 2, finalized in September 2025, moves the emphasis toward an enterprise media-sanitization programme and references appropriate supporting method standards. Do not lift tool-level recipes uncritically from the superseded 2014 revision. For an SSD, a cloud volume and a damaged disk, different vendor assurances and verification paths may be needed even when the confidentiality objective appears similar.
Sanitization approaches have different assurance levels and effects on future reuse. Clearing may be appropriate within a controlled reuse boundary, while purging or physical destruction can be required when confidentiality consequences and custody changes warrant stronger assurance. Refer to current recognized guidance such as NIST SP 800-88 and the storage vendor’s supported methods rather than memorizing a universal multiple-pass overwrite rule.
Flash-based storage, self-encrypting drives and magnetic media have different behavior. An overwrite command that appears successful on one device may leave remapped blocks or inaccessible areas on another. Choose a method supported by the technology and the intended protection level.
Treat cryptographic erase as a key-management action
Destroying a suitably protected encryption key may make encrypted content impractical to recover, but that conclusion depends on whether the encryption was active, the key was unique or properly scoped, copies of it exist, and any alternate recovery keys remain. A key stored in a backup service or an administrator’s workstation can undermine an otherwise valid cryptographic erasure claim.
Verify that the device and encryption system meet the method’s prerequisites. A disk containing partially unencrypted partitions cannot be sanitized by revoking only the key used for one protected volume.
Design chain of custody before equipment leaves the building
Record identifiers, asset owner, operator, transfer date, selected method and verification result. Use approved transport and a contract with the destruction vendor that defines evidence, confidentiality and incident notification expectations. A generic receipt saying ‘recycled’ is not equivalent to a record of verified destruction of the specific storage asset.
Separation of duties and independent sampling can reduce the risk of mistakes or fraudulent destruction certificates. High-impact media may justify witnessed destruction, while low-risk routine reuse can follow a proportionate, automated process.
Handle cloud deletion and retention differently
Deleting a cloud object from a user interface may not immediately remove snapshots, replicas, backups or delayed-deletion recovery copies. The customer must understand provider retention semantics, legal holds, immutability, backup lifecycle and contractual evidence. An individual tenant often cannot physically destroy the provider’s underlying device, so assurance relies on documented service behavior and provider controls.
A controller or data owner must reconcile deletion rights with lawful retention. Copies held by external processors and other storage regions can remain subject to deletion, retention and contract obligations after the primary system stops referencing them.
Test disposal with representative assets
Use a nonproduction device with synthetic data. Run the approved method, capture its result and verify using a supported independent check. For a media-destruction process, reconcile collected asset IDs with the supplier’s certificate. For cloud data, test what remains visible through documented restore or snapshot paths while respecting legitimate retention rules.
Failure to produce evidence means the security team cannot claim sanitization was completed, even if the device has left the room. Record exceptions and remediation rather than marking the task green based on a scheduled job.
Close the information lifecycle responsibly
A sound program connects data classification, creation, access, backup, archival, legal obligations and disposal. Owners know which copies exist, which may be destroyed, how the method is chosen and how completion is verified. Data remanence is not a niche hardware topic; it is a real test of whether the organization controls confidential information after the application stops using it.