Certificate of Destruction: What It Is & Why It Matters

The erase itself is only half the job. The other half is the paper trail that proves it happened — and a certificate of destruction is its headline document.

A certificate of destruction (sometimes called a certificate of data destruction or erasure certificate) is a formal record that a specific set of media was sanitised on a specific date, by a specific method. It's what you hand an auditor, a client, or a regulator when they ask: "how do you know that data is really gone?"

In this series:

Chain of custody

Behind every good certificate is a chain of custody — the unbroken record of where each drive was and what happened to it. A chain of custody starts at identification (serial number, model, source) and ends at final disposition (erased, resold, or destroyed), with each step timestamped.

tScrub's reports are built around a Chain of Custody ID (COCID): one identifier ties together every drive in a job, the system serials they came from, the methods used, and the final status of each drive.

What a certificate should include

Field	Why it matters
Certificate ID	Unique reference you can file and later look up
Chain of Custody ID	Links the certificate back to the job
Device list (Annex A)	Serial numbers, models, and methods per drive
Certification date / range	When the erasure took place
Method & outcome	Which wipe ran and its NIST 800-88 result
Technique & media disposition	How the data was destroyed — and whether the hardware still exists (sanitised in place and reusable vs physically destroyed)
Report manifest	File names and SHA-256 hashes of the source reports
Signature	Cryptographic proof the report hasn't been tampered with
Verification code / QR	Lets a third party confirm the certificate is genuine

Certificate of destruction vs certificate of erasure

Vendors use both names, and they are not quite the same claim. A certificate of erasure says the data was wiped; a certificate of destruction can imply the media itself no longer exists. That distinction matters the moment a drive is resold or reused — which is exactly what erasing in place is for.

tScrub keeps the certificate of destruction title (it is the name auditors and customers ask for) but makes it defensible by stating how the destruction was achieved — the method, the NIST SP 800-88 level reached, the technique, and the media disposition:

Method — e.g. ATA Enhanced Secure Erase, NVMe Crypto Sanitise, software overwrite, or operator-confirmed physical destruction.
Level — Clear, Purge, or Destruction, stated per drive and as the highest level reached for the run.
Technique — e.g. cryptographic erase (media encryption key destroyed) or ATA Enhanced Secure Erase (internal block erase).
Media disposition — e.g. "12 media sanitised in place (data destroyed; hardware reusable); 2 media physically destroyed", so nobody reads "destruction" as "the hardware is gone".

Page 1 carries the summary; Annex A opens with a destruction method summary and then lists every drive individually, and the signed machine-readable twin repeats the same technique and disposition fields for automated auditors.

How tScrub certificates work

The flow is simple: run tScrub to produce a report (CSV + manifest + signature), then upload it on your dashboard's Media page and generate a certificate from the Certificates page. The dashboard verifies the report, renders a printable PDF certificate — with a device annex and, where the report includes it, a pre/post-wipe SMART capture — and stores the issuance record.

The verification QR code

Every tScrub certificate carries a QR code that encodes a signed code for that certificate. Scanning it opens the verifier, which checks the signature on the reader's own device against the published key, so it confirms the certificate with no network at all; the same certificate ID also has a public record at /verify?cert=… that confirms the issuance record and document hash against the database. That turns a static PDF into something a third party can independently check — no phone call to you required.

Machine-readable certificates (JSON-LD)

Alongside the PDF, every certificate is issued as a signed JSON-LD document — the same link with &format=jsonld. It carries the same data as structured fields (certificate ID, COCID, every drive and report, the PDF's SHA-256) plus a detached Ed25519 signature and an RFC 3161 timestamp, so compliance platforms and automated auditors can ingest and verify it without a human reading the PDF. See how verification works.

Free vs paid: self-signed vs vendor-signed

Not all signatures are equal, and tScrub is explicit about which kind a certificate has:

Self-signed (free tier) — the report is signed with an ephemeral key generated on the appliance. It's tamper-evident (any modification breaks the signature) but not attributable — the key isn't tied to tScrub, so the certificate can't be independently confirmed as issued by a trusted party.
Vendor-signed (paid tiers) — reports are signed with a vendor-issued key, so certificates are attributable and verifiable. The QR confirms them fully.

For regulated disposal, vendor-signed certificates are the standard; self-signed is fine for internal reuse tracking.

Making certificates audit-ready

File certificates by job, and keep the source reports alongside them.
Use a COCID convention your team recognises (e.g. a ticket or asset number).
Prefer vendor-signed certificates for any drive leaving your control.
Record SMART data where available — it's useful evidence of a drive's condition at erase time.

FAQ

Is a certificate of destruction a legal requirement?

Not in itself, but data-protection law (GDPR, HIPAA) requires you to be able to demonstrate appropriate disposal. A certificate is the most practical way to do that.

Can I generate a certificate without a tScrub report?

tScrub certificates are generated from a tScrub report (CSV + manifest), because the certificate is only as trustworthy as the record it certifies.

Certificate of destruction: what it is and why you need one