Certificate of destruction: what it is and why you need one
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 explained
- How reports are signed
- How to verify a certificate
- SMART data as audit evidence
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 |
| 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 |
How tScrub certificates work
The flow is simple: run tScrub to produce a report (CSV + manifest + signature), then upload it on your dashboard's Reports page and generate a certificate from the Certificates page. tScrub 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 verification link. Scanning it opens /verify?cert=…, which confirms the certificate's 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.
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.