How to automate chain of custody in ITAD

A chain of custody is not a document. It is a claim about every individual device you handled, and it is only worth what it can prove when one of them is picked at random. Automating it means the evidence is captured as the work happens, by the process doing the work, rather than assembled afterwards from memory and a shift sheet.

Most operations already produce paperwork. Very few produce evidence. This is about the difference, and about what has to change to close it.

The four properties a record needs

Whatever system you use, the record has to be all four of these. Miss one and the rest stop mattering.

Per device. A line covering forty drives cannot carry a result for any one of them. If your unit of record is a batch, you have a summary — and summaries fail the only test that gets run.

Captured at the event. A serial typed at the end of a shift is a recollection. The gap between the work and the record is where transcription errors, omissions and honest mistakes live.

Tamper-evident. The record has to be able to show it has not changed since it was written. A spreadsheet cannot do this. Anyone who opens it can edit it, and nothing about the file says whether they did.

Retained with its evidence. The certificate is the claim; the per-device data behind it is the proof. Keep the PDF for seven years and let the underlying records roll off after one, and you have kept the claim and thrown away the proof.

The four places the chain breaks

1. The gap between the scan and the destruction

On most floors a device is recorded at a bench and destroyed somewhere else, minutes or hours later. The record says a drive was destroyed. What it actually evidences is that a drive was scanned and then carried away.

Nobody intends that gap. It exists because scanning and destruction are two stations, and everything between them is trust.

Closing it means capture at the point of destruction, so the scan and the destruction are the same event rather than two events joined by an assumption.

2. The serial nobody identified

A label carries a part number, a model, a service tag, a firmware revision and a serial. Reading them all is a solved problem and has been for years. Knowing which one is the serial is the actual work, and on most floors it is done by a person, by eye, several hundred times a day.

That is where wrong serials come from. Not from bad scanners — from a technician picking the wrong code off a crowded label at pace.

3. Records that cannot be shown to be unchanged

This is the one operators are most surprised by, because the file looks fine. An assessor is not asking whether the number is right. They are asking whether it is the number you wrote at the time, and a spreadsheet cannot answer that in either direction.

Append-only is the property that fixes it: entries are written once and never rewritten, so a correction becomes a new entry sitting beside the original rather than replacing it. The history stays intact and an alteration shows rather than hides.

The mechanism underneath matters, because “immutable” is a marketing word unless somebody can say what makes it true. Chaining each record to the previous one by its hash means a record cannot be removed or reordered either, not merely altered. Signing the final digest of that chain seals every record in one act. And publishing the public key means the person checking does not have to be the person who made the record — which is the whole point, since an assessor asking whether a record changed should not have to ask the party who would have changed it.

Two questions separate a real mechanism from a claim. Who holds the signing key, and can a third party verify without going through the vendor? If verification runs through the vendor’s own API, the vendor is still the authority and nothing has really moved.

4. Verification without validation

Revision 2 of NIST SP 800-88 made these two separate obligations, recorded separately. Verification is per device — did the sanitization run correctly on this one? Validation is per method — is that method demonstrably effective on that class of media at all?

Most operations do a great deal of the first and none of the second. It is the gap an assessor finds first, and no amount of automation fixes it, because validation is a piece of reasoning rather than a piece of data.

What automating it actually looks like

In the order that removes the most risk for the least disruption.

Capture the serial by machine, not by eye. This is the single highest-value change, because it removes the transcription step where wrong serials originate — and it removes the ten seconds a device that makes scanning the constraint on the whole floor.

Match against the expected list. Your client almost always supplies one. Matching against it turns identification into confirmation, which is both faster and safer.

Hold what is uncertain rather than guessing. Automation should not mean unsupervised. A device the system cannot read confidently must wait for a person. The failure mode you want is a device that takes a few seconds longer, not a wrong serial in a certificate you have already issued.

Write to an append-only record. Every entry keeps its capture, what was read, and what the operator decided. Corrections are new entries.

Generate the certificate from the record. Not typed alongside it. If the certificate and the evidence are produced separately, they will eventually disagree, and the one that disagrees is the one your client is holding.

Set retention on the whole record set. Seven years covers every common US regime. Enforce it technically rather than leaving it to whoever remembers to run the archive.

What you cannot automate, and should stop trying to

The operator’s decision. Where the system is unsure, a person decides. That is the failsafe the whole design rests on, and a vendor promising to remove it is promising to remove the thing that makes the record trustworthy.

Validation. Somebody has to write down why a method is appropriate for a class of media, who decided, when, and when it will be reviewed. It is a few pages, done once per method rather than once per drive. Nobody schedules it, which is why it is missing.

Naming an owner. Rev. 2 expects defined roles. If nobody owns the program, that is the first finding, and no system can own it for you.

The test to run on whatever you have now

Pick one serial off a certificate you issued eight months ago. Produce its history: the capture, what was read, what was decided, the method, the date, the person who confirmed it, and evidence the record has not changed since.

If that takes more than a couple of minutes, your chain of custody is a reconstruction. If it cannot be done at all, it is a claim.

Everything above is in service of making that one test boring.

What we are not claiming

We are not a certification body and this is not compliance advice. NIST SP 800-88 is guidance; how it applies to you depends on your clients, your contracts and the certifications you hold. We build a system that produces this kind of record, so read the above knowing we have an interest in you wanting one. The links below go to the primary documents rather than to anyone’s summary, including ours.