Erasure Certificates: Per-Drive, Per-Standard, Per-Auditor

"We wiped the laptop" is not a statement an ADISA auditor accepts. The auditor knows that Dell Latitude had two NVMe drives. They want to see two erasure certificates — one per drive — with the standard, the tool, the operator, the timestamp, and the cryptographic hash that proves the operation completed.

Per-drive granularity

The platform tracks erasure at the drive level, not the device level. A laptop with two drives gets two erasure records. Each record carries: drive serial, drive type (NVMe / SATA / etc.), the standard applied (NIST 800-88 Purge, NIST 800-88 Clear, DoD 5220.22-M, etc.), the tool used (Blancco, KillDisk, manual), the operator, the start and end timestamps, the result (success / failed / aborted), and the hash if the tool produced one.

Where the data comes from

Two paths. Path A: import the report from the erasure tool. Blancco XML/CSV exports are auto-parsed; the platform extracts per-drive records and matches them to the asset on serial. Path B: manual entry, for the rare case where the operation is logged in a tool that doesn’t export, or where a physical-destruction record needs to be created (a shred, a degauss). Both paths produce the same internal record shape.

The certificate

The platform-generated certificate (per drive) is a PDF with the per-drive fields, the operator signature, the tenant letterhead, and the certifying body if applicable (e.g., "issued in accordance with NAID AAA"). The certificate is the artefact the buyer or regulator wants — but the structured data behind it is what enables the audit-trail and the per-asset evidence bundle.

Failure handling

An erasure that fails (the drive was bad, the tool reported an error) records D3 status on the asset. The asset can’t move to the sellable layer until the failure is resolved — either by a successful retry or by the asset being routed to physical destruction with the corresponding cert. No silent failures.