Data Center Decommissioning Guide for IT Asset Managers

Introduction

The certificate of data destruction is the operator's primary documentary defense in a post-incident regulatory review. It is also, in our editorial review of 35 vendor profiles, the document with the highest variance in what it actually means. Data center decommissioning is where that variance becomes material risk. When an entire facility closes—hundreds of racks, thousands of drives, network gear that touched every packet your organization routed—the documentary record is the only thing standing between a clean exit and a multi-year regulatory entanglement.

Data center decommissioning is the process of systematically retiring a data center facility and dispositioning every asset inside it in a manner that protects data, satisfies regulatory requirements, and produces a documentary record that will hold up under audit. For IT asset managers, it is the highest-stakes ITAD engagement the organization will run. Unlike routine hardware refreshes where individual assets move through controlled channels, decommissioning compresses the entire lifecycle—inventory, data destruction, chain-of-custody, downstream accountability—into a constrained timeline with external pressures from lease expirations, landlord requirements, and budget cycles.

This guide covers the mechanics of data center decommissioning from the operator's perspective: what the process entails, why the risks are structural rather than incidental, how to approach vendor selection and contract negotiation, and what best practices look like when the documentary record is the primary deliverable. We examine common failure modes, the questions that survive regulatory review, and the trade-offs IT asset managers face when balancing cost, timeline, and risk. For a detailed breakdown of project costs and budget planning, see our Data Center Decommissioning Cost: A Realistic Breakdown.

In our review of vendor profiles, twenty-two of thirty-five had discrepancies between the certificate of data destruction mentioned in their marketing materials and the one outlined in their published methodologies. For IT asset managers running a decommissioning project, that gap is not an academic concern—it is the difference between a certificate that satisfies the auditor and one that does not. The sections that follow describe how to close that gap before the first asset leaves the floor.

Explore our complete guide to data center decommissioning, covering best practices, challenges, and the steps IT asset managers must take.

What is Data Center Decommissioning?

Data center decommissioning is the structured process of retiring a facility's IT infrastructure — servers, storage arrays, networking equipment, and supporting hardware — in a manner that protects data, satisfies regulatory obligations, and recovers residual asset value. The process begins when an organization decides to consolidate facilities, migrate to cloud infrastructure, or exit a colocation agreement. What distinguishes decommissioning from routine hardware refresh is scope: you are dismantling an entire operational environment, not swapping individual components.

The decommissioning engagement typically involves physical asset removal, data sanitization, chain-of-custody documentation, and final disposition through resale, recycling, or destruction. In the 2016 Morgan Stanley data center decommissioning, the operator handled approximately 4,900 devices across two primary facilities in Poughkeepsie, NY and Columbus, OH, including 53 RAID arrays containing roughly 1,000 hard drives and 8,000 backup tapes. The contract specified pickup, transport, decommissioning, and resale with documented certificates of destruction for devices that could not be resold. That scale — thousands of assets, multiple device types, and split disposition paths — is representative of enterprise-grade decommissioning work.

The Core Processes Involved

A complete decommissioning program includes asset inventory, sanitization decision logic, physical handling, and documentary proof. NIST SP 800-88 Rev. 2, the current media sanitization standard, states that a sanitization program should specify policies setting expectations for asset disposal, identify scope and decision criteria, perform the sanitization, determine its adequacy, and produce the records necessary to meet compliance obligations. The standard treats sanitization as an element of the organization's data governance process, not an afterthought once hardware leaves the rack.

The failure mode in Morgan Stanley's case was not the destruction methodology itself but the chain-of-custody documentation. The contract contemplated that devices would be wiped or degaussed, resold with a revenue split, and accompanied by asset reports, disposition reports, and certificates of destruction. Early in the engagement, the subcontractor providing inventory tracking and certificates ceased working with the moving company. The database that MSSB could have monitored independently was no longer updated, and certificates of destruction stopped being issued. No one at MSSB monitored the database or maintained direct contact with the subcontractor to verify that devices were being handled as specified. The documentary record — the mechanism that survives audit — disappeared, even though the contract required it.

Decommissioning also includes physical logistics that create risk if mishandled. Morgan Stanley's policies required removing hard drives from their shelves before transport. During the 2016 engagement, however, witnesses confirmed that drives were moved from the data centers to the downstream processor's warehouse still in their cabinets, contrary to policy. The downstream processor then sold the shelves to another purchaser with the drives still present. The underlying control — physical separation of media from chassis — was specified but not enforced, and the failure created an exposure that the operator only discovered after the drives were already in a third party's hands.

For IT asset managers planning a decommissioning engagement, understanding these structural elements is essential. The contract language, the subcontractor relationships, the inventory tracking mechanism, and the physical handling protocols are not administrative details. They are the controls that determine whether your decommissioning program will hold up when auditors ask what happened to the assets. A well-structured decommissioning process treats documentation and physical custody as co-equal priorities, because both must survive the engagement intact.

For a detailed cost breakdown of what these processes entail in practice, see our Data Center Decommissioning Cost: A Realistic Breakdown guide.

Why Data Center Decommissioning Matters

The significance of proper data center decommissioning extends far beyond logistics. When an enterprise closes a data center or migrates workloads, the equipment leaving the facility carries regulatory obligations, financial risk, and environmental consequences that persist long after the racks are empty. The question is not whether to decommission carefully — it is whether the organization's documentary record will survive the audit that follows a failure.

Compliance and Regulatory Risk

Regulators expect serialized chain-of-custody for assets that touched regulated data. In the 2016 Morgan Stanley Smith Barney data center decommissioning, approximately 4,900 devices were removed from two facilities, including 53 RAID arrays containing roughly 1,000 hard drives with unencrypted customer PII. The contract contemplated certificates of destruction, asset reports, and disposition reports. What actually happened was different. Early in the engagement, the subcontractor providing inventory tracking and certificates ceased operations, and no one at the firm monitored the database or maintained direct contact with the downstream processor. Devices were resold without documentation, and hard drives were transported still mounted in their cabinets — contrary to the firm's own policies.

The failure was not in the destruction methodology. The failure was in the chain-of-custody documentation that should have survived the engagement and did not. For IT asset managers, this case is the canonical reference: the mechanism that fails is not the shredder, it is the contract language and the oversight posture that together produce an audit-defensible record.

Security and Data Protection

The security risk in decommissioning is not theoretical. Hard drives that leave a data center in their original enclosures, without individual serialization and documented destruction, create a downstream exposure that the enterprise cannot close. The Morgan Stanley case demonstrated this precisely: IT Corp B sold drive shelves to another purchaser with the drives still present. The underlying control — physical separation of drives from enclosures, serialized tracking, and certificates tied to specific assets — was contractually required but operationally absent.

For enterprises subject to SEC, FINRA, HIPAA, or GDPR obligations, the standard is clear: if the asset touched regulated data, the organization must produce a serialized record of its disposition. Factory resets, batch certificates, and vendor assurances do not meet this standard. The question the auditor will ask is whether the documentary record ties each serialized asset to a verified destruction event. If the answer is no, the posture is not defensible.

Environmental and Reputational Impact

Beyond compliance and security, improper decommissioning carries environmental and reputational consequences. Equipment resold without proper data sanitization or disposed of without R2v3 or e-Stewards certification creates downstream liability that the enterprise cannot control. When a subcontractor's subcontractor sends drives to a landfill or an unverified export channel, the regulatory exposure remains with the original asset owner.

The reputational cost of a decommissioning failure is difficult to quantify but materially significant. The Morgan Stanley case resulted in over $100 million in cumulative regulatory penalties, remediation costs, and legal settlements. The public record of that failure — available in SEC enforcement filings — is now the reference point for every enterprise IT team writing an RFP for data center decommissioning services. The operator's posture must be: assume the process will be audited, assume the documentary record will be reviewed, and structure the engagement so that what you hand the auditor is what you can defend.

How to Approach Data Center Decommissioning

Data center decommissioning is a structured process that requires coordination across procurement, IT operations, legal, and vendor management. The approach described here is built on what survives audit — the documentary record that holds up when regulators, auditors, or counsel review the engagement after the fact. The Morgan Stanley case demonstrated that the failure mode in decommissioning is rarely the destruction method itself; it is the chain-of-custody documentation that should have survived the project but did not.

The steps below reflect the operator's posture: inventory before bidding, verify before contracting, and document every handoff.

Step 1: Inventory Every Asset Before Vendor Engagement

In the 2016 Data Center Decommissioning, Moving Company handled approximately 4,900 devices, including 53 RAID arrays that collectively contained approximately 1,000 hard drives. The contract contemplated that MSSB would receive an asset report and a disposition report documenting whether devices were returned, resold, or destroyed. The underlying control — the inventory — was available, but no one at MSSB monitored it independently.

Step 2: Define Data-Bearing vs. Non-Data-Bearing Assets

Not all assets carry the same risk. Hard drives, RAID arrays, backup tapes, and network devices with configuration memory are data-bearing. Rack rails, power distribution units, and cable management hardware are not. The contract language and the certificate of data destruction should distinguish between these categories.

Step 3: Establish Vendor Approval and Subcontractor Visibility

Moving Company and IT Corp A submitted a joint bid for the 2016 Data Center Decommissioning, but only Moving Company was formally approved as an MSSB vendor — and it was approved without the use of a sub-vendor. The contract identified IT Corp A and contemplated that IT Corp A would wipe or degauss devices, but IT Corp A was never formally approved. Early in the engagement, Moving Company ceased working with IT Corp A, and IT Corp A's inventory tracking database was no longer used. This information was available to MSSB, but no one acted on it.

The mechanism here is straightforward: if the contract names a subcontractor, that subcontractor must be approved through the same vendor-assessment process as the prime. If the subcontractor changes mid-engagement, the contract must be amended and the new subcontractor must be approved before any assets are transferred.

Step 4: Require Real-Time Inventory Access

The 2016 Data Center Decommissioning contract contemplated that MSSB would have direct access to IT Corp A's inventory tracking database throughout the collection, wiping, and resale process. MSSB could have monitored the entire process independently, if it chose to do so. No one at MSSB monitored the database or had any direct contact with IT Corp A during the decommissioning process to ensure that the devices were properly handled.

For IT asset managers planning a decommissioning engagement, the question the auditor will ask is: did you verify the vendor's work as it happened, or did you wait for the final certificate? Real-time inventory access is the control that answers that question.

Step 5: Specify Transportation and Handling Requirements

During the 2016 Data Center Decommissioning, MSSB transported hard drive shelves with the drives still in place. Witnesses from Moving Company and IT Corp B confirmed that the hard drives were moved from the data centers to IT Corp B's warehouse still in their cabinets, contrary to MSSB's policies and procedures. IT Corp B also sold the shelves to another purchaser with the drives still present.

The contract language should specify how data-bearing devices are transported: drives removed from shelves, serialized, and tracked individually. If the contract is silent on transportation, the vendor will default to the most cost-effective method, which is not always the most audit-defensible method.

Step 6: Define Certificate-of-Destruction Requirements

For the devices that IT Corp A destroyed, IT Corp A provided a certificate of destruction to Moving Company, which then provided it to MSSB. Devices that were resold were first wiped and then placed for sale on an internet auction site. Certificates of destruction were not provided for devices that were resold, but wiping was documented in the database.

The contract should specify:

• What triggers a certificate of destruction (physical destruction only, or also logical sanitization)
• What information the certificate must contain (serial numbers, destruction method, date, location, witness signature)
• Who issues the certificate (the entity that performed the destruction, not a pass-through intermediary)

For a detailed breakdown of what drives decommissioning costs and where to negotiate, see our guide on Data Center Decommissioning Cost: A Realistic Breakdown.

Step 7: Establish Disposition Reporting and Reconciliation

The contract contemplated that MSSB would receive an asset report and a disposition report, as well as certificates of destruction documenting the destruction of relevant devices. However, it does not appear that MSSB ever requested or received the remainder of the resale amount from Moving Company, as contemplated in the contract.

The disposition report is the final reconciliation: every serialized asset in the initial inventory must appear in the disposition report with a documented outcome (returned, resold, or destroyed). If an asset does not appear in the disposition report, the vendor must explain why. If the vendor cannot explain why, the asset is presumed lost, and the breach-notification analysis begins.

Best Practices for Data Center Decommissioning

The difference between a defensible decommissioning and a regulatory incident is rarely the equipment itself. It is the documentary record and the upstream controls that either survive audit or do not. In our editorial review of vendor profiles, we see operators describe their data destruction processes in confident terms, but the contract language and the chain-of-custody mechanics often tell a different story. The best practices below are not aspirational — they are the minimum posture that holds up when the auditor asks to see the serialized records.

Verify Vendor Certification Before Contract Signature

Do not assume that a vendor's marketing collateral reflects its current certification status. The e-Stewards Standard, R2v3, and NAID AAA certifications all carry audit requirements, but certification lapses are common and not always disclosed. Before signing, request a copy of the vendor's current certification certificate with an issue date and expiration date. Cross-reference the vendor name and facility location against the certifying body's published directory. If the vendor describes itself as "certified" but cannot produce a certificate with a valid date range, treat that as a failure mode and move to the next bidder.

Require Serialized Asset Tracking From Pickup to Final Disposition

The Morgan Stanley enforcement action turned on a single fact: the firm could not produce serialized records showing what happened to specific devices after they left the data center. The contract contemplated an inventory database with real-time access, but no one at the firm monitored it, and when the subcontractor relationship collapsed, the database went dark. The lesson is structural: if you cannot produce a serialized record for a specific device, you cannot defend the chain of custody for that device.

Best practice is to require that the vendor maintain a serialized tracking system accessible to your team in real time, not on request. The system should log each device by serial number, capture its status at each handoff (pickup, transport, receipt at processing facility, data destruction, final disposition), and generate an audit trail that timestamps each status change. For a detailed breakdown of what to expect in vendor contracts, see our guide on Data Center Decommissioning Services: What's Included, What's Extra.

Separate Data-Bearing Devices From Non-Data-Bearing Devices at the Source

The SEC enforcement record describes a common failure mode: Moving Company handled approximately 4,900 devices, many of which were non-data-bearing, but some of which contained unencrypted customer PII. The problem was not that the vendor lacked the capability to destroy data — it was that no one separated the devices that required destruction from the devices that did not. The result was that data-bearing devices entered a resale stream without documented sanitization.

Best practice is to tag data-bearing devices at the source before any vendor touches them. Use a physical tag (adhesive label or RFID) that identifies the device as requiring data destruction and the destruction method specified (NIST 800-88 overwrite, degaussing, physical shred). Non-data-bearing devices should be tagged separately or left untagged, depending on your internal process. The vendor contract should specify that data-bearing devices follow a separate handling path with serialized tracking and that no data-bearing device may be resold without a certificate of data destruction for that specific serial number.

Remove Hard Drives From Enclosures Before Transport

MSSB's internal policies required that hard drives be removed from their enclosures before transport. During the 2016 Data Center Decommissioning, however, the firm transported hard drive shelves with the drives in place. Witnesses from Moving Company and IT Corp B confirmed that the hard drives were moved from the data centers to IT Corp B's warehouse still in their cabinets, and IT Corp B later sold the shelves to another purchaser with the drives still present. This is a failure of process, not a failure of the vendor's technical capability.

Best practice is to remove drives from RAID arrays, storage shelves, and server chassis before the vendor arrives, or to require that the vendor perform the removal on-site under your supervision. The removed drives should be inventoried by serial number, placed in tamper-evident bags or locked containers, and transported separately from the enclosures. The contract should specify that drives and enclosures follow separate disposition paths and that no drive may leave the facility inside an enclosure unless the enclosure itself is tagged for destruction.

Require Certificates of Destruction for Every Serialized Device

The e-Stewards Standard requires that the organization retain verification records of successful sanitization for each serialized device and provide verification information to customers upon request. The Morgan Stanley case demonstrates what happens when this requirement is not enforced: IT Corp A provided certificates of destruction for devices that were physically destroyed, but no certificates were provided for devices that were wiped and resold. The firm had no documentary proof that the resold devices had been sanitized.

Best practice is to require that the vendor provide a certificate of data destruction for every data-bearing device, whether the device is destroyed or resold. The certificate should include the device serial number, the destruction or sanitization method, the date, and the name of the individual who performed the work. For devices sanitized using NIST 800-88 overwrite, the certificate should specify the number of passes and the verification method. For devices physically destroyed, the certificate should describe the destruction method (shred, crush, degauss) and the final disposition of the resulting material.

Audit the Vendor's Subcontractor Relationships

The Morgan Stanley enforcement record describes a contract structure in which Moving Company was approved as a vendor without the use of a subvendor, but the contract itself identified IT Corp A and contemplated that IT Corp A would perform the data destruction work. Early in the engagement, Moving Company ceased working with IT Corp A, but no one at MSSB was notified, and the firm continued to operate as if IT Corp A were still performing the work. The result was a complete loss of visibility into the downstream process.

Best practice is to require that the vendor disclose all subcontractor relationships in writing before the contract is signed, and to require that the vendor notify you in writing within 24 hours if any subcontractor relationship changes. The contract should specify that no subcontractor may perform data destruction work unless that subcontractor holds the same certifications as the primary vendor and unless you have approved the subcontractor in writing. If the vendor relationship changes mid-engagement, the contract should give you the right to terminate without penalty.

Retain the Documentary Record for the Full Regulatory Period

The enforcement action against MSSB was filed in 2022 for a decommissioning that occurred in 2016. The firm's inability to produce serialized records six years after the fact was a central element of the case. The lesson is that the documentary record must survive not only the decommissioning itself but the full regulatory retention period for the data that was on the devices.

Best practice is to retain all certificates of destruction, asset inventories, chain-of-custody logs, and vendor contracts for at least seven years after the decommissioning is complete. Store the records in a system that is backed up and that will survive personnel turnover. If your firm is subject to SEC, FINRA, or OCC oversight, consult your compliance team to confirm the retention period for the specific data types that were on the decommissioned devices. In some cases, the retention period may exceed seven years.

Common Mistakes in Data Center Decommissioning

The Morgan Stanley case is not an outlier — it is a documented failure mode that surfaces when the contract language and the operational reality diverge. In our editorial review of 35 vendor profiles, we have seen the same structural gaps appear in different forms: the certificate that does not match the methodology, the subcontractor that was never approved, the chain-of-custody database that stopped updating midway through the project. These are not edge cases. They are the predictable outcomes of incomplete vendor oversight and inadequate documentation discipline.

Approving a Prime Contractor Without Vetting the Subcontractor

The 2016 Data Center Decommissioning engagement illustrates the core failure mode. Moving Company was approved as the vendor of record, but the contract contemplated that IT Corp A would perform the actual data destruction and resale operations. IT Corp A was never formally approved as a subcontractor. When IT Corp A ceased working with Moving Company early in the engagement, the inventory tracking database that MSSB had relied on stopped updating. No certificates of destruction were provided for devices after that point. MSSB had access to the database and could have monitored the process independently, but no one at MSSB did so.

The question the auditor will ask is straightforward: if your contract named a subcontractor and that subcontractor stopped performing, what control detected the gap? In the Morgan Stanley case, the answer was none. The operator's posture was passive — the contract contemplated oversight mechanisms, but those mechanisms were not exercised.

Transporting Data-Bearing Devices in Violation of Internal Policy

During the same engagement, hard drive shelves were transported with the drives still in place, contrary to MSSB's documented policies and procedures. Witnesses from both Moving Company and IT Corp B confirmed that the drives remained in their cabinets during transport and that IT Corp B later sold the shelves to another purchaser with the drives still present. The policy required drives to be removed before transport. The contract did not override the policy, and the vendor did not follow it.

This is a failure of the underlying control. The policy existed, the contract was signed, and the operational reality was something else. What survives discovery is not the policy document or the contract clause — it is the testimony of the moving crew and the downstream processor describing what actually happened.

Failing to Monitor the Chain-of-Custody Database

MSSB had direct access to IT Corp A's inventory tracking database throughout the collection, wiping, and resale process. The database documented which devices were destroyed, which were wiped and resold, and which certificates of destruction were issued. For a period, the system worked as designed. When IT Corp A ceased providing services, the database stopped updating. No one at MSSB monitored the database or had direct contact with IT Corp A to ensure that devices were being handled according to the contract terms.

The mechanism for oversight existed. The failure was not technological — it was operational. The contract contemplated that MSSB would receive asset reports, disposition reports, and certificates of destruction. When those reports stopped arriving, no internal control flagged the gap. The audit-defensible posture requires active monitoring, not passive receipt of vendor-generated documentation.

Assuming Certificates of Destruction Cover Resold Devices

Certificates of destruction were provided for devices that were physically destroyed. Devices that were wiped and resold were documented in the inventory database, but no certificates of destruction were issued for them. This is not unusual — a certificate of destruction is a statement that the device no longer exists in operable form. A wiped device that is resold does not meet that definition. The documentary record for those devices is the database entry showing the wipe was completed and the resale transaction.

The mistake is assuming that one certificate covers all disposition paths. It does not. If your contract permits resale, your chain-of-custody documentation must account for devices that leave the destruction process and enter the secondary market. The auditor will ask what evidence you retained showing that those devices were wiped to the standard required by your data classification policy. If the answer is a database entry that stopped updating, the position is not defensible.

Not Reconciling the Resale Revenue

The contract contemplated that IT Corp A would retain 30 to 40 percent of the resale amount and provide the remainder to Moving Company, which would then remit it to MSSB. It does not appear that MSSB ever requested or received the remainder of the resale amount from Moving Company. The financial reconciliation that the contract required did not occur.

This is a secondary indicator of control failure. If the financial terms of the contract are not being enforced, the operational terms are likely not being enforced either. The question is not whether the resale revenue was material to the overall engagement cost — the question is what other contract terms were not being monitored. For more on evaluating vendor contract terms and what to negotiate, see Data Center Decommissioning Services: What's Included, What's Extra.

Relying on Vendor-Provided Reporting Without Independent Verification

The contract required asset reports and disposition reports. Those reports are vendor-generated. They describe what the vendor says happened. They are not independent verification. In the operator's defense, independent verification at scale is expensive — serialized chain-of-custody for thousands of devices requires either continuous on-site presence or instrumented tracking with tamper-evident controls. Most engagements do not budget for that level of oversight.

The trade-off is between cost and audit-defensibility. If your risk posture requires serialized tracking, your RFP language must require it and your contract must price it. If your budget does not support serialized tracking, your documented risk acceptance must state that the chain-of-custody evidence will be vendor-generated and that the downstream accountability depends on the vendor's internal controls. That is a defensible position if it is documented in advance. It is not defensible if the contract promised serialized tracking and the vendor did not deliver it.

Frequently Asked Questions about Data Center Decommissioning

What happens if a subcontractor is used without proper approval?

The Morgan Stanley case documented a scenario where the approved vendor (Moving Company) worked with IT Corp A, but IT Corp A was never formally approved as an MSSB vendor. The contract contemplated IT Corp A's involvement, but the vendor approval process did not reflect that relationship. When IT Corp A ceased operations mid-project, the inventory tracking database disappeared, and certificates of destruction stopped being issued.

In our editorial review of vendor contracts, this pattern—approved vendor, undisclosed or improperly documented subcontractor—is the failure mode that creates the largest downstream accountability gap. The question the auditor will ask is not whether the destruction happened, but whether you can prove it happened to the contracted standard. If the subcontractor's records are unavailable or were never part of the contractual chain of custody, the answer is no.

If you discover a subcontractor was used without approval, document the discovery immediately, request all available records from both the prime vendor and the subcontractor, and escalate to legal and compliance. Do not assume the work was done correctly just because the prime vendor says it was.

How do I verify that data destruction actually occurred?

Verification depends on the destruction method and the documentary record that survives audit. For devices going to reuse, the e-Stewards Standard requires verification that overwrite instructions were successfully executed for 100% of a device's physical memory locations, with records retained for each serialized device. For devices going to physical destruction, the standard requires validation of the destruction process and logging of each container of non-serialized devices.

The certificate of data destruction is the primary document, but in our review of vendor profiles, we found significant variance in what that certificate actually means. Some certificates confirm only that the device was received; others confirm the method applied; the strongest certificates tie a serialized asset identifier to a specific destruction event with a timestamp and operator signature.

The audit-defensible position is: serialized inventory in, serialized certificate out, with no gaps in the chain of custody. If the vendor cannot provide that level of documentation, the risk is yours.

What should I do if the vendor stops providing certificates mid-project?

In the 2016 Data Center Decommissioning, IT Corp A ceased providing certificates of destruction after Moving Company stopped working with them. MSSB had access to an inventory tracking database that would have shown this gap, but no one at MSSB monitored it. The result: devices containing unencrypted customer PII were sold at auction with no destruction record and no ability to reconstruct what happened.

If certificates stop arriving, stop the project. Do not assume the work is continuing to the contracted standard. Contact the vendor immediately, request an explanation in writing, and require documentary proof that all devices processed to that point were handled correctly. If the vendor cannot provide that proof, escalate to legal and prepare for the possibility that some devices were not destroyed or were disposed of outside the contracted process.

The mechanism that failed in the Morgan Stanley case was not the destruction technology—it was the monitoring discipline. The database was available, the access was granted, and no one looked. That is an operator-grade failure, not a vendor failure.

Can I rely on a vendor's marketing claims about certifications?

No. Marketing materials describe capability; the verified position describes what the vendor is actually certified to do. In our editorial review, 22 of 35 vendor profiles showed discrepancies between the certificate of data destruction mentioned in marketing and the one outlined in published methodologies. Some vendors claimed NIST 800-88 compliance but did not specify whether they used the Clear, Purge, or Destroy method. Others referenced R2v3 certification but did not disclose whether their downstream processors were also certified.

The RFP language that survives audit is: "Vendor shall provide [specific certification] issued by [specific body], current as of contract execution, and shall provide copies of all certifications for any subcontractor or downstream processor." If the vendor cannot produce those documents, the certification claim is not verified.

For a more detailed framework on evaluating vendor claims, see our guide on how to evaluate data center decommissioning companies.

What is the difference between data wiping and physical destruction?

Data wiping (also called sanitization or logical destruction) overwrites the data on a storage device, rendering it unrecoverable while leaving the device intact for reuse. Physical destruction (shredding, crushing, degaussing) renders the device itself unusable. The choice depends on the device type, the data classification, and the organization's risk tolerance.

NIST 800-88 defines three sanitization methods: Clear (logical techniques applied to user-addressable storage), Purge (physical or logical techniques that render target data recovery infeasible using state-of-the-art laboratory techniques), and Destroy (rendering the device unusable). For devices containing regulated data—ePHI, PII, consumer report information—Purge or Destroy is the standard. Clear is not adequate.

The failure mode we see most often: an operator selects wiping for cost reasons, the vendor applies a Clear-level wipe, and the device is resold. The data is recoverable with forensic tools, and the operator has no audit-defensible record that Purge was applied. If you specify wiping, specify the NIST method by name, and require the certificate to confirm that method.

How long should I retain decommissioning records?

The retention period depends on the regulatory framework and the data classification. For SEC-regulated entities, Regulation S-P requires policies and procedures to protect customer information, and enforcement actions have cited failures to retain adequate records. For HIPAA-covered entities, the retention period is six years from the date of creation or last effective date. For GDPR-regulated data, the retention period must align with the organization's data retention policy and the ability to demonstrate compliance.

In practice, the conservative position is: retain all chain-of-custody documentation, certificates of destruction, and vendor contracts for the longer of (a) the regulatory retention period, (b) the statute of limitations for contract claims in your jurisdiction, or (c) seven years. If the decommissioning involved a data breach or regulatory inquiry, retain the records indefinitely.

The records that matter in a post-incident review are: the RFP, the contract, the inventory list, the certificates, and any correspondence showing you monitored the vendor's performance. If you cannot produce those documents, the regulatory posture is that you did not have adequate controls.

What should I do if devices were sold instead of destroyed?

In the 2016 Data Center Decommissioning, devices that were supposed to be wiped and resold were instead sold at auction with no wiping and no destruction record. MSSB did not discover this until the devices appeared in a third party's possession, and by then the chain of custody was irretrievable.

If you discover that devices were sold instead of destroyed, or sold without adequate sanitization, treat it as a presumed data breach until you can prove otherwise. Engage legal and compliance immediately, notify your regulators if required, and begin forensic reconstruction of what data was on the devices and where they are now. Do not assume the data was wiped just because the vendor says it was—if the certificate does not exist or does not tie to a serialized device, the data is presumed exposed.

The Morgan Stanley settlement was $100M+ in cumulative costs, and the failure was not in the destruction methodology but in the chain-of-custody documentation that should have survived the auction and didn't. The lesson for IT asset managers is: the documentary record is the control. If the record does not exist, the control did not happen.

Conclusion

Data center decommissioning is not a project that tolerates improvisation. The documentary record you produce during the process — the chain-of-custody logs, the certificates of data destruction, the serialized asset manifests — is the only defense that survives audit when regulators or litigators arrive years later. In our editorial review of 35 vendor profiles, we observed that twenty-two vendors showed material discrepancies between the certificates described in their marketing collateral and the ones outlined in their published methodologies. The Morgan Stanley case remains the canonical reference: the failure was not in the destruction method itself but in the chain-of-custody documentation that should have survived the auction and did not. That gap cost the firm over $100 million in cumulative fines, settlements, and remediation.

The operator's posture during decommissioning determines whether the project becomes a routine milestone or a future liability. Start with a complete serialized inventory before any vendor sees the asset list. Select vendors whose certification posture and published methodology align with your regulatory obligations — not the ones whose sales pitch sounds most confident. Require audit-defensible chain-of-custody documentation at every handoff, and verify that the certificate of data destruction you receive describes the specific methodology applied to your specific assets, not a generic template. Build contract language that defines what happens when an asset cannot be sanitized to NIST 800-88 standards, and ensure that downstream processors are named in writing with their own certification credentials attached.

The discipline you apply to vendor selection, contract negotiation, and documentation review is the discipline that holds up under regulatory scrutiny. If you are planning a decommissioning project and need a structured framework for evaluating potential partners, our guide on how to evaluate data center decommissioning companies provides the operator-grade criteria that survive audit. The cheapest vendor is the one whose paper trail you trust enough to hand the auditor without flinching. Everything else is deferred cost.