Received Isn't Destroyed: What Your Certificate of Destruction Can't Prove

For an IT asset manager, this will be a familiar story.

A decommission is signed off. The drives come out of the racks, go into sealed containers with serialized, tamper-evident tags, and leave with a courier. Someone at the other end signs for the tags. A week or two later, a certificate of destruction arrives, itemized, every serial accounted for. The ticket is closed and the risk is handed over.

Except it isn’t, quite. We know the drives arrived. We know someone says they were destroyed. Between those two facts is the part of the process nobody on our side saw, and that is where the risk still sits. Just ask Brighton and Sussex University Hospitals: of about 1,000 hard drives it needed destroyed, at least 252 never were, and it could not explain how. Some turned up on an internet auction site, and the ICO fined the trust £325,000 (ICO, 2012).

This guide covers three things: what a certificate of destruction should contain, where the gap is, and how to test the one you’ve been given.

What a hard drive destruction certificate should contain

NIST SP 800-88 Rev. 2 calls it a certificate of sanitization, and destruction is one of the methods it covers. Whether you call it a certificate of data destruction or a NIST 800-88 certificate of destruction, the fields are the same. For each device sanitized, it says the certificate should record the manufacturer, model and serial number, the method and tool used, how the result was verified, and who verified and validated it (NIST, 2025, § 4.6). Note the word “should”: NIST is guidance, not a requirement. But if you don’t follow it, you should be prepared to explain why to an auditor or an investigator.

Guidance isn’t the same as best practice, though. NIST says what a certificate should record, including a verification method and the names of the people who verified it. It doesn’t ask for evidence that someone outside the process could check, and that is what decides whether the certificate can be relied on.

The gap: destruction rests on someone’s word

Wipe a drive with erasure software and the tool makes its own record as it works, one line per serial. That is what good evidence looks like: made by the process, at the moment, about the specific device. R2v3 requires exactly that for logical sanitization, “for each unique identifier of the data storage media” (SERI, R2v3, Appendix B (10)).

Shred the same drive and the standards ask for much less:

• R2v3 requires a per-device record from the erasure software. For physical destruction, it sets the method, checks that quantities processed match quantities received, and requires video of the destruction kept for at least 60 days (SERI, R2v3, Appendix B (7), (9), (10), (15)(b)). In short, it records which drive you erased, but only how many you destroyed. Drives are often destroyed because they can’t be wiped, or because they are too sensitive to reuse. Either way, the weaker record falls on them.
• NAID AAA’s hard drive destruction endorsement requires serial numbers to be recorded and the log returned to the client, unless the client opts out. It requires an audit trail through the whole process for overwriting and degaussing, but not for physical destruction (i-SIGMA, 2025, §§ 4.3, 4.6, 4.7). The manual doesn’t say why. It may be that a wipe can’t be seen to have worked while a shred can. Either way, the same point applies as for R2v3: the weaker record falls on the drives that are destroyed. It also requires CCTV of processing through final destruction, kept for 90 days (§ 2.5).
• NSA/CSS sets the methods for destroying a drive, from degaussing and deforming the platters to disintegration on devices from its Evaluated Products List (NSA/CSS, 2026, §§ 30, 45). The current manual sends documentation to Policy 6-22, dated 15 August 2023, which is not public (§ 49). The 2019 edition, which is, required at least two people to verify the results, recorded by serial number, before media left the facility (NSA/CSS, 2019, ¶ 29). Even the NSA didn’t rely on one person’s word.

Video doesn’t close the gap either. CCTV records a room, not a serial: it can show that shredding happened, but it can’t identify which device went in. And it isn’t kept long. R2v3 asks for 60 days and NAID AAA for 90. Losses can take far longer to surface: across all kinds of breach, IBM’s average is 247 days just to identify and contain one (IBM, 2026). By the time anyone asks what happened to a drive, the footage may well be gone.

None of them say when, where or how the destruction record is made. So it can be made the way it was for me: someone records what they say they destroyed, and signs it.

When I was an asset manager sending classified equipment away for destruction, it went from one secure facility to another inside the same organization, sealed with tamper-evident, serialized tags and carried by an appropriately cleared courier. What came back was a receipt of goods and an itemized certificate of destruction. Some items had no accessible serial number, so they were described by model, color and any identifying marks. The receipt and the certificate were both evidence. But the destruction rested on someone’s word.

Someone’s word is the weakest kind of evidence, and auditors have long treated it that way. The Public Company Accounting Oversight Board (PCAOB), which sets the auditing standards for US public companies, says that “inquiry of company personnel, by itself, does not provide sufficient audit evidence” (PCAOB, AS 1105 .17). A certificate isn’t quite that: it comes from a third party, and auditors rate evidence from an independent source above the company’s own (AS 1105 .08). But a destruction vendor is independent of its client, not of the work it is certifying. It is vouching for itself. The same standard says that “as the risk increases, the amount of evidence that the auditor should obtain also increases” (AS 1105 .05). Destruction runs the other way: the riskier the drive, the weaker the record. The international standard, ISA 500, adds that a record made at the time is more reliable than an account given later (IAASB, ISA 500). Security assessment follows the same rule. The Australian Signals Directorate’s Essential Eight assessment guide rates “a policy or verbal statement of intent” as Poor, the lowest of its four levels (ASD, 2024).

So if accounting and security assessment both treat someone’s word as the weakest evidence, why is it still accepted as proof of destruction in our industry?

Why an attestation isn’t enough

Attestation never failed me outright, and it was compliant with every standard. It left doubt, and with classified assets and the rising cost of a data breach, doubt is a risk I was still carrying. The global average cost of a breach is now $4.99 million, up 12% in a year and the highest IBM has recorded; in the US it is $11.5 million (IBM, 2026). Three things stay open when the only proof of destruction is a signature:

• detection: a missing device looks exactly like a destroyed one on paper;
• insider risk: anyone who handles a device between receipt and the shredder has the opportunity to take it;
• investigations: when something goes wrong, there is nothing to reconstruct what happened to a specific device.

Morgan Stanley is the case everyone in this industry knows. The SEC found disposal failures going back as far as 2015. Morgan Stanley had hired a moving and storage company “with no experience or expertise in data destruction services” to decommission devices holding customer data. That company sold devices to a third party, and some were eventually resold on an internet auction site with customer data still on them. Morgan Stanley did not properly monitor the vendor for several years. Separately, during a refresh of branch servers, a records reconciliation showed that 42 servers were missing (SEC, 2022). It agreed to pay the SEC $35 million, without admitting or denying the findings.

The problem isn’t a lack of evidence. Certificates of destruction are routine. It’s the type and quality of that evidence. A certificate shows that someone says the drives were destroyed; it can’t show that each one went into the shredder. Evidence made at the moment of destruction, of each device, is different. An insider who knows each drive has to be shown going in has far less room to sell it on, and if someone does it anyway, the gap shows. In security-control terms, the shredder is a preventive control; that kind of evidence is both a deterrent and a detective control.

Detection still depends on the asset owner checking, and that is where matching comes in. When each destroyed drive is matched against the client’s asset list as it is destroyed, and the record comes back in a standard format such as CSV or JSON, the asset owner can reconcile it in their own IT asset management software the day it arrives. A serial on the asset list with no destruction record next to it stands out immediately. Reconciliation is what caught Morgan Stanley’s 42 missing servers. A per-device record from the vendor makes the same check possible at the point of destruction.

Records matter long before the shredder too. In most organizations, finding a device comes down to knowing the right people. Asset management software helps, but only if someone keeps the records up to date, and it is not unusual to find devices in a back room that have fallen off the radar. Inside the controlled environment, that is a nuisance. Once a device leaves it, it is a potential data breach. That is why best practice is to keep a record every time a device changes security zone. Recording each change acknowledges that the device’s security state, and its risk, has changed, so the risk can be managed. NIST names three of those points: when media enters the environment, when it leaves where it was last used, and when it reaches the post-sanitization destination. And it warns what happens without them: if tracking breaks down before the end, the destruction records can show that the drives which arrived were destroyed, but not that every drive you had made it there (NIST, 2025, § 4.6). A drive that went missing on the way never appears in them.

Why the gap is wider now

I’d argue this gap matters more now than it did a few years ago, for four reasons:

• the price of hardware: AI demand has pushed memory prices up sharply. TrendForce expected server DRAM prices to rise about 90% in a single quarter in early 2026, and a Seagate executive expects memory price rises to be “the new normal” (SCMP, 2026). Hardware that is worth more is more tempting to sell on;
• circularity: more devices are wiped and resold, and data-centre operators now run reuse programs at scale (Microsoft’s Circular Centers, AWS re:Cycle). More devices moving between owners means more handovers, and each one is a point where, as NIST warns, tracking can break;
• the cost of a breach: a record $4.99 million on average, up 12% in a year (IBM, 2026);
• more parties in the chain: compromise through a supply chain or business partner was among the biggest cost amplifiers IBM measured, adding $227,250 to a breach, and took 258 days to identify and contain (IBM, 2026). An ITAD vendor is part of its client’s supply chain.

How to test a certificate you’ve been given

It’s the test any evidence has to pass, which is the reason for collecting evidence in the first place. It comes down to two questions.

1. What type of evidence is it, and where did it come from? An attestation (a signature on a form), an image, or a video. A certificate is the operator’s own statement that the work was done. Auditors ask this first: “The reliability of evidence depends on the nature and source of the evidence.” Evidence from an independent source beats evidence from the people who did the work, evidence obtained directly beats evidence obtained second-hand, and an original beats a copy (PCAOB, AS 1105 .08). In intelligence circles, the source is rated separately from the content. The source and information reliability matrix, often called the Admiralty code, grades the source from A (“reliable”) to F (“reliability unknown”) (US Army, FM 2-22.3, Appendix B).
2. Can it be verified, and does it corroborate? Auditors weigh corroboration against quality: “As the quality of the evidence increases, the need for additional corroborating evidence decreases” (PCAOB, AS 1105 .05). The reverse is true too. More of the same type of weak evidence doesn’t make up for its poor quality (AS 1105 .05). And where evidence from one source is inconsistent with another, the auditor has to resolve it (AS 1105 .29). The same matrix grades the information itself from 1 to 6, and the top grade is “confirmed by independent sources.” Those sources have to be credible in their own right, and the more of them agree, the stronger the confirmation. A court asks a related question, about authenticity rather than weight: evidence has to be shown to be “what the proponent claims it is,” and one way is “evidence describing a process or system and showing that it produces an accurate result” (FRE 901(a), 901(b)(9)). A certificate, timestamped photos of each device and a video of the destruction corroborate each other as evidence of the same event, and each can be validated and verified.

If you’re advising on someone’s destruction program, that is where I’d push: on the quality of the evidence and the assurance it gives, not just on whether a certificate exists.

A note on shredding itself

NIST Rev. 2 says shredding and pulverizing “should be avoided for anything but the lowest security categories of data,” because denser, harder media can survive them (NIST, 2025, § 3.1.3). The NSA approves hard drive shredders for deforming the platters after a drive has been degaussed (NSA/CSS, 2026, annex). In some programs, a shred is followed by further destruction, depending on the data and the organization’s own policy. Either way, it is the last step at which each device can still be identified on its own. After that, there is only residue. So it is the last chance to record what was destroyed, device by device. Recording it doesn’t make a shred adequate for a higher category; it means you know exactly which devices went on to the next step.

Free certificate of destruction template

Download the template (CSV), to open in Excel, Numbers or Google Sheets. The template follows NIST SP 800-88 Rev. 2 § 4.6 and adds a per-device log, with optional fields for photo and video references.

Verified destruction

Verified destruction replaces someone’s word with a record of each drive at the moment it is destroyed. The certificate can then be checked against what was actually destroyed, which deters insiders, exposes gaps and supports any investigation.

That evidence does three jobs:

• deterrent: an insider who knows each drive must be photographed going into the shredder, and that the photo goes back to the asset owner, knows that taking one will show. The opportunity isn’t removed, but it now comes with a real chance of being caught;
• detection: every destroyed device is matched against the asset list as it happens. A serial on the list with no destruction record stands out the day the record arrives, not months later in an audit or after a breach;
• investigation: when something does go wrong, there is a timestamped, per-device record of what happened to that specific device, where and when, and it is kept for as long as you need it rather than for 60 or 90 days.

Isn’t that still the operator vouching for itself? Partly, and that is why two things matter. First, a camera on its own can’t tell you which device it filmed. To tie destruction video to a serial today, each drive has to be scanned inside the camera frame, with the scanner and camera clocks kept in sync. That is slow and manual. Verified destruction captures the device’s identity and its image in the same moment, by the same system. Second, the independent check stays with the asset owner: each record is matched against the client’s own asset list, and the client reconciles it in their own software.

It is what we’re building at Nabel Solutions, starting at the shredder.

How much of your current certificate could you prove, if someone asked tomorrow?

References

• ASD (2024). Essential Eight Assessment Process Guide, October 2024. Australian Signals Directorate.
• FM 2-22.3. Human Intelligence Collector Operations, Appendix B, Source and Information Reliability Matrix. US Army.
• SCMP (2026). Memory price hikes ‘the new normal’ as AI boom fuels storage demand, Seagate says. South China Morning Post. TrendForce figure as reported by SCMP.
• FRE (Federal Rules of Evidence). Rule 901, Authenticating or Identifying Evidence, (a) and (b)(9).
• IAASB. ISA 500, Audit Evidence.
• IBM (2026). Cost of a Data Breach Report 2026. Published 29 July 2026. Mean time to identify and contain (247 days) as reported by Help Net Security, 30 July 2026, and Baker Donelson.
• ICO (2012). Brighton and Sussex University Hospitals NHS Trust fined £325,000. News release, 1 June 2012.
• i-SIGMA (2025). Certification Specifications Reference Manual, revision 0925M. §§ 2.5, 4.3, 4.6, 4.7.
• NIST (2025). SP 800-88 Rev. 2, Guidelines for Media Sanitization. September 2025. §§ 3.1.3, 4.6.
• NSA/CSS (2019). Policy 6-22, Handling of NSA/CSS Information Storage Media, 21 November 2019. ¶ 29. Superseded by the 15 August 2023 edition, which is not public.
• NSA/CSS (2026). Policy Manual 9-12, Storage Device Sanitization Manual, 19 February 2026. §§ 30, 45, 49 and annex.
• PCAOB. AS 1105, Audit Evidence. .05, .08, .17, .29.
• SEC (2022). Morgan Stanley Smith Barney to Pay $35 Million for Extensive Failures to Safeguard Personal Information of Millions of Customers. Press release 2022-168, 20 September 2022.
• SERI. R2v3 Standard, Appendix B (7), (9), (10), (15)(b). Sustainable Electronics Recycling International.