Auditors and assessors
What to ask an operator for
We build the system that produces this evidence, so we have an obvious interest. Read it with that in mind — and take the parts that are useful on your next assessment.
- Written for
- Assessors
- Jurisdiction
- United States
- Standard
- NIST SP 800-88 Rev. 2
Start with one device, not with the policy
Policies describe intent. Pick a serial off a certificate the operator issued eight or more months ago, and ask what happened to that device.
- What was captured, and can they show the capture rather than a typed line?
- What the system or the technician read, and what was decided.
- The method, the date and the person or process that confirmed it.
- Whether the record can be shown not to have changed since.
Most operations fail on the last one without realising. A spreadsheet is not evidence that nothing was edited; it is evidence that somebody typed something once.
Separate verification from validation, and ask for both
Revision 2 made these two different obligations, recorded separately, and most operators still use the words interchangeably.
- Verification is per device — did sanitization run correctly on this one?
- Validation is per method — is that method effective for this class of media at all?
- Ask for a per-device verification record and a written basis for the method, dated, with an owner.
An operation that verifies everything and validates nothing has volume without reasoning. It is the most common gap, and it is invisible if you only ask to see records.
What each standard asks the record to show
Clause by clause: what the standard asks for, how it is usually done, and what Serial Xtractor records. Read each row as a question to put to the operator.
| Standard | Asks for | Today | With Serial Xtractor |
|---|---|---|---|
| NIST SP 800-88 Rev. 2 · §4.6 | A certificate of sanitization for each item | One certificate for the whole load | Partly recorded: One certificate per job, a line for every device |
| NIST SP 800-88 Rev. 2 · §4.6 | The serial number, per item | Typed, or scanned at a bench | Recorded by Serial Xtractor: Read from the label in under a second |
| NIST SP 800-88 Rev. 2 · §4.6 | Media type, and the method — clear, purge or destroy | Typed onto the certificate | Recorded by Serial Xtractor: Recorded per device, method printed on the certificate |
| NIST SP 800-88 Rev. 2 · §4.6 | Verification — each item checked and recorded | One signature for the batch | Partly recorded: Each device recorded with its time and capture |
| NIST SP 800-88 Rev. 2 · §4.6 | Validation — the method shown to work | Often never written down | Stays with the operator: Stays with you — one written basis per method |
| NIST SP 800-88 Rev. 2 · §4.6 | Who performed and who verified — with a signature | Typed onto the certificate | Partly recorded: All recorded and printed — signature still wet-ink |
| R2v3 · Appendix B(2) | Traceability for each device * | A spreadsheet | Recorded by Serial Xtractor: Per device, on an append-only record |
| R2v3 · Appendix B(15)(b) | Processed matches received | A count at each end | Recorded by Serial Xtractor: Matched, missing and unexpected — by serial |
| NAID AAA · 4.3 | Every drive serial, logged and returned † | The operator's own log | Recorded by Serial Xtractor: A per-device log on the certificate, sent to the client |
| R2v3 B(9) · NAID AAA 2.5 | Video of destruction | Facility CCTV | Stays with the operator: Stays with your CCTV |
- Recorded by Serial Xtractor
- Partly recorded
- Stays with the operator
- NIST SP 800-88 Rev. 2 is guidance — §4.6 says the certificate should record these, and treats verification (per device) and validation (per method) separately.
- * R2v3 accepts the identifier “or tracking through other means”, so a spreadsheet conforms.
- † Unless the data controller signs an opt-out.
- These standards bind the operator. Read from NIST SP 800-88 Rev. 2, R2v3.1 and the NAID AAA manual 0925M.
Three things that look like evidence and are not
- A batch line. Forty drives on one row cannot carry a result for any one of them.
- A certificate with no underlying records. The certificate is the claim; the per-device data is the proof, and retention has to cover both.
- A method statement citing a withdrawn document. Revision 1 was withdrawn in September 2025, and a policy still naming it has not been reviewed since.
What to ask for when a record claims to be tamper-evident
"Immutable" and "tamper-proof" are marketing words unless the operator can tell you what makes them true. Four questions separate a claim from a mechanism.
- What is signed, and with what scheme? A signature over a single document is weaker than one over a chain of every record in the session.
- Who holds the key? If the vendor does, ask what stops the vendor rewriting history — the honest answer is "nothing, but it becomes provable", and a vendor who claims otherwise is overclaiming.
- Can you verify it yourself, without the vendor? If verification runs through the vendor's API, the vendor is still the authority.
- Is the timestamp trusted or self-asserted? A device clock is fine if it is described as one.
Ours, today: each scan is written once as its own entry, with the device's own clock as its time, and the certificate is signed in ink. A hash-chained record, a signed certificate, a public verification page and an independent timestamp are on our roadmap — until they ship, the honest answer to these questions is that you are relying on us.
Separation of duties, and what evidence of it looks like
Ask who witnessed a destruction and how that is recorded. A name typed into a field by the same person who did the work is not separation.
- Were the operator and the witness distinct, authenticated parties?
- Did the witness see the actual manifest, or a summary of it?
- Is the attestation bound to the specific record, or just to the session?
- Could either party alter the record after attesting?
Ours: the operator is a signed-in user; the witness watches the live manifest from their own device through a read-only link, and both have their own block on the certificate. Neither is yet a cryptographic signature bound to the record — that is on our roadmap, and we would rather you knew the difference.
Where our own product would fail your test
Stated plainly, because a page like this is worthless if it only lists other people's weaknesses.
- Nabel Solutions holds no ISO 27001 certification and no SOC 2 report. Our infrastructure provider does; we do not, and we do not imply otherwise.
- Without an asset list, our model selects the correct serial on 97.7% of legible drive labels within one character (87.4% exact), measured in our lab with five-fold cross-validation. The rest are held for an operator rather than guessed. Against a list it is 100%, and a list is normally supplied.
- The mobile app is backed by a cloud service that holds captured images. If an operator tells you their capture is entirely on-premise, check which deployment they actually run.
Ask us anything you would ask an operator
If you assess this industry and want to understand what the record contains or how it can be tested, we will walk you through it. No sales call, and we are not asking you to recommend anything.
We're on a mission to bring automation to ITAD
Interested in hearing more, or got something you'd like to talk through? Get in touch.