Verification and validation are not the same thing

Verification is the check. Validation is the decision. Verification is the operational step: inspect what the technique did to this device and confirm it completed without errors or anomalies. Validation sits above it. The organisation reviews that verification data against how sensitive the data was, approves the work as effective, and accepts whatever confidentiality risk is left (NIST, FAQ for SP 800-88r2, 2026). 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 we check every drive and nobody ever reviews those checks against the sensitivity of what was on them, we hold a stack of evidence that something happened and nobody’s signature saying it was enough.

Why this changed

Before Revision 2 the two words were used loosely, and often interchangeably. Rev. 1 was in practice a lookup table: find the media type, read off the technique, do the technique. Revision 2 — published on September 26, 2025, the same day Rev. 1 was withdrawn (NIST, 2025) — 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 looked at what the verification records actually showed, weighed it against how sensitive the data was, and accepted the result. That decision has to be evidenced rather than assumed, and it carries a name.

The device-level technique guidance moved to IEEE 2883-2022 (IEEE, 2022), which is where our 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

We verified everything and validated nothing. This is the common one. Every drive has a record. Every record says the wipe completed. Nobody has read those records against the sensitivity of what was on the drives, and nobody can show why that 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 nobody has signed for it.

We validated a method and never verified it ran. Rarer, and worse. There is 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 (NIST SP 800-88 Rev. 2, § 4.6). If the record is per batch rather than per device, it is not verification. It is a summary.

For validation, per method and media class: what the method is, what media it applies to, what the verification records for it actually showed, how sensitive the data was, the basis for believing the method does what it claims, who approved it, when, what residual risk they accepted, and when it will be reviewed. The verification data and the acceptance are the parts that get skipped. Three acceptable forms of basis:

• Testing we 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 we issued, quite possibly one from eight months ago, and ask for its history. This is the verification test. What fails it is not usually a missing record — it is a record made somewhere other than at the machine, or a batch line that covers the device without saying anything about it specifically.

“Who looked at these results, and what did they accept?” This is the validation test, and it is the one that catches people. It is a question about a decision, not about a technique: which verification records were reviewed, against what sensitivity of data, who approved the method as effective, and what residual risk they took on. “It is what we have always used” is not an answer. “The standard says so” stopped being an answer when Rev. 2 moved technique guidance to IEEE 2883 and asked us 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 our own documents. If the procedure uses them interchangeably, an assessor will assume the confusion runs deeper than vocabulary. Often they are right.
2. Check the 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 in use. One page per method. What it is, what media, what the verification records showed, why we believe it works, who approved it, what they accepted, when.
4. Name an owner for the programme, and a risk owner. Rev. 2 expects defined roles, and validation ends in somebody accepting a residual risk. 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 rather than a policy problem, and it is not the problem it is usually described as. Regulated operators already capture serial numbers. A barcode scanner and a spreadsheet solved that years ago, and anybody who runs a floor will say so inside a sentence of being told otherwise.

The gap is when the record gets made. The scan happens at a bench. The destruction happens later, at the machine, with a person and a trolley in between. Nothing in the file describes that interval, so what the file holds is a record of what somebody says happened rather than evidence that it happened; the difference stays invisible until an assessor tests it —

• the serial is read at the bench and the drive goes into the shredder some time afterwards, and the record carries one of those two moments;
• the assessor asks which of them the certificate line refers to, and the honest answer is the scan;
• the technician who could have described what happened in between finished their shift eight months ago.

Revision 2 pictures the alternative rather than the workaround. Section 4.6 offers, as an example and not as a requirement, that “some ISM include bar codes on the label for the model and serial numbers, so the person performing the sanitization might simply enter the details into a tracking application and scan each bar code as the ISM is sanitized” (NIST SP 800-88 Rev. 2, § 4.6). The scan and the sanitization are the same moment in that sentence. That is the whole of the difference: not whether we hold serials, but whether the record was written where the event happened and while it was happening.

Validation, by contrast, is a thinking problem, and it depends on the first one. It is a few pages of reasoning somebody sits down and does, once per method rather than once per drive — but the reasoning is only as good as the verification records it reads. Weak records make the acceptance a guess. 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 any one operation depends on its clients, its contracts and its 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.

One question to finish on, and it is the one we would ask ourselves first: pick a serial off a certificate issued last month — does the record behind it show the moment the drive was destroyed, or the moment somebody scanned it? If it is the second one, how are you closing the gap between them? We would like to hear it.