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.
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: each scan is chained to the previous by its hash, the certificate is signed over the final chain digest, the public key is published for pinning, a QR code on the certificate resolves to a public verification page, and each certificate is timestamped by an independent authority. Get in touch for the detail of what to verify against. Scan capture times are the device's own clock. We hold the signing key, so tampering by us is provable rather than impossible.
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 attests from their own device against the session digest, and both attestations are embedded in the signed certificate. It is not two cryptographic signatures backed by two customer-held keys — 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 a target list, the system identifies the serial unaided on 79.6% of devices. 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.