The Custody Integrity Standard

An open, verifiable standard for the integrity of drug-testing custody records

Why This Standard Exists

Drug-testing records decide jobs, custody of children, and liberty. The industry's integrity vocabulary carries enormous weight and no defined bar: "chain of custody," "audit trail," and "court-ready" are claims any vendor may make, and no certification program tests them.

CIS-1 defines the bar as a set of verifiable properties. Each requirement pairs with a verification procedure that an independent examiner, an auditor, or an adversarial attorney can run against a live system and watch pass. A conformant system answers challenges by demonstration.

The standard is written so that any vendor could conform. That is what makes it a standard. Azimuth publishes it, submits to examination against it, and invites the rest of the industry to do the same.

Conformance Language

MUST denotes a property required for CIS-1 conformance. Each requirement's Verification describes the procedure an examiner performs on a live system. A system conforms when every procedure passes.

A. Capture & Identity

• A1 — Every specimen MUST be bound at collection to a serialized seal identifier recorded before any result exists. Verification: trace any released result to its seal record and collection event timestamps.
• A2 — Donor identity MUST be verified at collection by a recorded mechanism (identity document check, biometric verification where enrolled), and the mechanism used MUST appear on the custody record. Verification: sample released results; each shows its identity-verification event.
• A3 — Where a read informs a result, the system MUST retain the source image or images behind the call. Verification: select released results at random; render the stored capture images.

B. Event Integrity

• B1 — Custody events (collection, seal, transfer, read, disposition, review, release, amendment) MUST be append-only: no interface, role, or support pathway may edit or delete a recorded event. Verification: attempt mutation as the highest-privilege application role; confirm structural refusal, and an audit record of the attempt.
• B2 — Every event MUST carry actor attribution, including the real actor during any impersonation or support session. Verification: perform a supported impersonation action; confirm dual attribution on the trail.
• B3 — Released reports MUST be frozen: any post-release change MUST occur only through a versioned amendment that preserves the superseded content and notifies prior recipients. Verification: attempt to alter a released report; issue an amendment; confirm revision history and rescind notice.
• B4 — The event log MUST be tamper-evident by cryptographic means (per-record hash chaining or equivalent), such that deletion, alteration, or reordering of historical events is detectable by recomputation. Verification: recompute the chain over a produced range and confirm any introduced change surfaces as a located failure.
• B5 — Event timestamps MUST be traceable to a reliable time source, and exports MUST be cryptographically signed so a third party can later prove an export is authentic, complete, and unmodified, without access to the producing system. Verification: validate the signature and completeness proof of a produced export offline, against the published public key.

C. Reproducibility

• C1 — Random and color-code selections MUST store the seed and the exact ordered pool used, and MUST re-derive identically on demand, independent of subsequent roster churn or software upgrades. Verification: re-run any historical draw; compare the output to the recorded selection.
• C2 — A contested read MUST be re-readable against the original stored image through a defined, recorded dispute process. Verification: run a dispute; confirm the second read binds to the same image and both reads persist on the record.

D. Disclosure & Access

• D1 — Result disclosure MUST be audience-scoped: each recipient class sees only its entitled view, enforced by the system, per report, by default. Verification: render the same result as a decision-maker and as an authorized clinical reviewer; compare the fields disclosed.
• D2 — Every access to a shared result, including tokenized views requiring no login, MUST be logged with time and audience. Verification: open a share link; locate the access event.
• D3 — Where a program is designated under 42 CFR Part 2, every released report MUST carry the §2.32 redisclosure notice. Verification: release a report from a designated program; inspect the document.

E. Retention & Deletion

• E1 — Retention and PHI deletion MUST be policy-driven, and deletion MUST anonymize rather than destroy the integrity record: custody events survive de-identification. Verification: run a deletion in a test environment; confirm PHI removal and custody-chain survival.
• E2 — Legal holds MUST block deletion, and a blocked deletion MUST record the reason. Verification: place a hold, attempt the deletion, inspect the recorded block reason.

Examination

An examination against CIS-1 consists of performing every Verification above against a live, production-configuration system and reporting the outcome of each. The procedures are written to be runnable by a CPA firm, a security firm, or a technical auditor without reliance on the vendor's own tooling: hash chains recompute from exported data, export signatures validate offline against a published public key, and every other procedure observes system behavior directly.

Examination inquiries, and requests for the examiner's procedure pack: [email protected]

CIS-1 Version 1.0, September 2026. This standard is published openly; any vendor may adopt it and submit to examination against it. Revisions will be versioned, and prior versions preserved.