Verification and validation are not the same thing

Verification is per device. Validation is per method. Verification asks whether the sanitization actually ran correctly on this drive. Validation asks whether the method you used is demonstrably effective on that class of media at all. Revision 2 expects both, recorded separately, and most operations do a great deal of the first and none of the second.

That asymmetry is the point of this article. If you check every drive and never establish that your method works, you have a stack of evidence that something happened and no evidence that what happened was sufficient.

Why this changed

Before Revision 2 the two words were used loosely, and often interchangeably. Rev. 1 was in practice a lookup table: find your media type, read off the technique, do the technique. Revision 2 — published on September 26, 2025, the same day Rev. 1 was withdrawn — steps back from prescribing device-by-device methods and instead sets out a sanitization programme.

A programme has to be able to show its reasoning. That is where validation comes from. Somebody decided this method was appropriate for this media, and the decision has to be evidenced rather than assumed.

The device-level technique guidance moved to IEEE 2883-2022, which is where your procedures should now cite their methods from.

The two obligations, side by side

The frequency row explains why validation gets forgotten. Verification is part of the job, so it happens. Validation is a piece of paperwork somebody did once, or meant to, and it is nobody’s task on any given Tuesday.

The two ways operations fail

You verified everything and validated nothing. This is the common one. Every drive has a record. Every record says the wipe completed. Nobody can show why that wipe method is appropriate for an SSD with a controller that may not honour the command the way the software assumed. The evidence is voluminous and it answers a question nobody asked.

You validated a method and never verified it ran. Rarer, and worse. You have a well-reasoned method statement and a batch line saying forty drives were processed. Which forty? Did the process complete on each? A batch record cannot carry a per-device result, so it cannot answer.

Both failures produce paperwork. Neither produces evidence.

What each looks like as a record

For verification, per device: the serial, the method used, the date and time, the operator or system that performed it, the result, and — where the device could not be sanitized and was destroyed instead — the destruction method. If your record is per batch rather than per device, you do not have verification. You have a summary.

For validation, per method and media class: what the method is, what media it applies to, the basis for believing it effective, who decided, when, and when it will be reviewed. The basis is the part that gets skipped. Three acceptable forms:

• Testing you performed. Sample devices, sanitized, then examined for recoverable data. Document the sample size and the examination method.
• Vendor documentation. The drive or software manufacturer’s statement that the method achieves the effect claimed. Keep the version — vendor claims change with firmware.
• Independent attestation. A third party’s assessment. The strongest and the most expensive.

None of these has to be elaborate. All of them have to exist and be findable.

What an assessor actually asks

Expect two questions, and expect them in this order.

“Show me the record for this device.” They will pick one serial off a certificate you issued, quite possibly one from eight months ago, and ask you to produce its history. This is the verification test. What fails it is not usually a missing record — it is a record that exists in a spreadsheet nobody can prove was not edited, or a batch line that covers the device without saying anything about it specifically.

“Why is that method appropriate for that media?” This is the validation test, and it is the one that catches people. The answer “it is what we have always used” is not an answer. The answer “the standard says so” stopped being an answer when Rev. 2 moved technique guidance to IEEE 2883 and asked you to run a programme instead.

A third question is becoming common: “When did you last review that decision?” A validation with no review date is a validation that was true once.

Five things worth doing this month

1. Separate the two words in your own documents. If your procedure uses them interchangeably, an assessor will assume the confusion runs deeper than vocabulary. Often they are right.
2. Check your records are per device, not per batch. This is the single most common structural failure, and it cannot be fixed retrospectively.
3. Write down the basis for each method you use. One page per method. What it is, what media, why you believe it works, who decided, when.
4. Name an owner for the programme. Rev. 2 expects defined roles. If nobody is named, that is the first gap found.
5. Set a review interval and put it in a calendar. Annual is defensible. Never is not.

The part that is genuinely harder

Verification at volume is a data problem, not a policy problem. Producing a per-device record for every asset means capturing the serial, the method, the time and the operator decision as the work happens — because reconstructing it afterwards from memory and a shift sheet is exactly what a per-device record is supposed to replace.

That is straightforward when a system captures it. It is painful when a technician is reading serials off labels at the end of a shift, and it is impossible to defend when the resulting file can be edited by anyone who opens it without the edit leaving a mark.

Validation, by contrast, is a thinking problem. It is a few pages of reasoning that somebody has to sit down and do. The good news is that you do it once per method rather than once per drive. The bad news is that nobody schedules it, so it does not happen.

What we are not claiming

We are not a certification body and this is not compliance advice. Revision 2 is a NIST guidance document; how it applies to you depends on your clients, your contracts and your own certifications. Read the source rather than anyone’s summary of it, including ours, and take advice where the money justifies it. The links below go to the primary documents.