What should a certificate of destruction include?

A certificate of destruction is only as useful as the information it records. A generic letter that says "the following assets have been destroyed" does not give an auditor or compliance officer the detail they need to close a data-disposition finding. The difference between a certificate that satisfies an audit and one that triggers a follow-up request is in the structure: per-asset specificity, standard citation, and a clear statement of what the document does and does not certify.

This page describes the sections a complete certificate of destruction template should contain, using Destructcert's output as a reference model.

Every certificate needs a unique identifier so it can be referenced in audit reports and tracked across disposition batches. A sequential numbering scheme (CERT-001, CERT-002, etc.) is the simplest approach — it gives each certificate a clear identity without requiring a database or serialisation service.

The generation date should be explicit. An auditor will compare the certificate date against the disposal log to confirm the timeline matches operational records.

The standard reference — NIST SP 800-88 Rev. 1, including the revision identifier — tells the reader which framework the certificate is following. Without it, the phrase "compliant certificate" has no anchor.

The core of any useful certificate of destruction is the per-asset table. Each row should record:

• Item number — A sequential row identifier within the certificate
• Serial number — The unique identifier of the asset, as it appears in the organisation's asset register or ITAD inventory
• Make / model — The manufacturer and model identifier, enough to determine the media type if it is not stated explicitly
• Media type — HDD, SSD, SSHD (hybrid), tape, optical, or flash/USB. Essential because the allowable sanitization methods differ per type
• Sanitization category — Clear, Purge, or Destroy
• Technique — The specific method used, such as degaussing, cryptographic erase, multi-pass overwrite, shredding, or incineration

A table that includes all of these fields allows an auditor to trace any individual asset from the certificate back to the operational record. A table that omits any of them forces the auditor to ask for supplementary documentation.

A certificate of destruction is a record of what the operator entered. It is not a verification that a drive was sanitized — it documents the sanitization information provided by the person or system that processed the asset.

Every certificate should include a plain-spoken disclosure that:

• Records the asset details and sanitization methods as entered by the operator
• Does not itself verify that any drive or device was sanitized
• Should not be taken as independent confirmation of sanitization

This disclosure protects both the certificate issuer and the recipient. It sets accurate expectations about what the document proves and prevents it from being misused as independent verification of destruction.

The following shows how these elements come together in a single document. This is the same format Destructcert produces — numbered, dated, with a per-asset table and a clear footer disclosure.

A certificate that contains invalid method-media combinations — for example, "Clear" on an SSD — is worse than a certificate that omits the method entirely. It appears to be compliant while actually containing an error that an auditor will flag. The fix is to validate each entry against the NIST 800-88 matrix before the certificate is generated, so that only valid pairs reach the printed document.

Destructcert's approach is to reject invalid combinations at the point of entry. If an operator selects a method that does not apply to the chosen media type, the entry is not accepted, and the certificate cannot be generated until every row passes validation. The result is a document where every entry is structurally sound — no method-media mismatches, no missing fields, no standard citations omitted.

See the sanitization methods guide for the full applicability matrix, or the NIST 800-88 overview for what the standard requires at a document level.