A destruction log is either the most useful record you hold about your data disposal, or it is decoration. The difference is not the format. It is whether one entry can be traced to one serial number and stands up when someone else picks the serial number.
That distinction sounds pedantic until an assessor does exactly that. At which point a log either produces an answer in a couple of minutes or it does not, and no amount of good practice elsewhere compensates.
This template rebuilds the destruction log around a change most organisations have not caught up with. NIST SP 800-88 Rev. 2, published on 26 September 2025, separates verification from validation. Verification asks whether sanitisation happened correctly on this specific medium. Validation asks whether the method itself actually works. They are different questions, answered by different people, on different cycles, and almost every destruction log in circulation collapses both into a single verified yes or no column.
The consequence matters. An operator verifying their own work with a tool nobody has independently tested is a closed loop. Every entry says pass, because the tool says pass, because the tool has never been checked. That log looks perfect and assures nothing. In this template every entry carries a verification result and a reference to the validation record in force at the time, which costs almost nothing to implement and is the single change that most improves the credibility of an existing log.
Rev. 2 changed something else worth knowing. It deliberately stopped prescribing techniques, deferring instead to IEEE 2883, NSA specifications, or an organisation-approved alternative. Which means the phrase wiped to NIST standard now conveys no information at all. A log entry, and a supplier claim, needs the technique named. The template includes a do-not-record versus record table covering that, degaussing (which does nothing to solid state media, and a log that does not capture media type cannot detect that error), and cryptographic erase, which Rev. 2 expects to be backed by a separate assurance record covering algorithms, key strengths, escrow history and any key copies held outside the device.
There is also a section on the failure that matters most, which is not a failed wipe. Failures are normal in any operation at scale. The problem is the silent retry: an operator who retries until it passes and records only the pass has produced a clean log that conceals a failed control. Nothing in the record indicates the tool, the medium or the technique had a problem. An assessor who finds one silent retry will assume there are others, and will be right to. The register is built so that a failure and its escalation are two retained entries, never one overwritten result.
Consignment-level certificates get the same treatment. A certificate stating that one pallet was destroyed on a given date is a receipt, not a log entry, because it cannot be sampled. An assessor cannot select a serial number from your asset register and find it, so it evidences nothing about any particular device.
Inside the 31 pages: what a defensible entry contains and why each field earns its place, the verification and validation procedure, Clear, Purge and Destroy explained with a method-by-media-type mapping to complete, the full field reference, the operating procedure, witnessing requirements defined rather than assumed universal, exception routes for eight failure modes, retention and audit preparation, and a validation record template.
Six appendices: a printable batch log sheet, a printable exception sheet, a certificate of sanitisation structured to the Rev. 2 field expectations, a diagram of where each field is created across the chain of custody, a 22-point readiness checklist, and a glossary.
The companion Excel register handles it at scale. One row per information storage medium, dropdown validation, an exception log, and a summary that runs four reconciliation checks before you close a batch: incomplete entries, blank verification results, entries missing a validation reference, and whether your verification failures match your logged exceptions. That last check is the one that catches a silently retried failure.
Free and customisable. Everything in square brackets is a field you complete.