Two different jobs for one record
Operational logging answers "what happened, roughly, so we can fix it". Evidentiary records answer "prove this specific person did this specific thing, and prove nobody changed the record afterwards". The second is a much higher bar, and systems that were designed for the first almost never clear it.
The distinction becomes concrete the first time somebody asks you to prove a negative — that a named administrator did not access a particular case file during a particular week. Operational logs can rarely support that claim, because absence of a log entry only proves the logging worked.
What breaks a chain of custody
- Attribution ending at a shared account. If four people know the
oraclepassword, the record names the account and not the human, and the chain ends there. - Records the subject can edit. Shell history, local syslog, and application logs on the target are all writable by exactly the person an investigation is about.
- Gaps nobody can explain. A recorder that stopped for six hours creates a period you cannot make claims about, and a defence only needs the possibility.
- Unverifiable copies. An exported recording with no way to demonstrate it matches what was captured is a file, not evidence.
- Retention that expired quietly. Evidence deleted on a default 90-day policy while the matter was still live is a problem you cannot fix afterwards.
What a defensible record looks like
- A named human, verified at the gateway. The session is authenticated to an individual with MFA before any target credential is involved. The account used on the target is injected and never known to the operator, so the two identities stay linked.
- Complete capture. Keystrokes, output, commands, transferred files, and duration — captured at the broker rather than on the target, where the subject of the investigation cannot reach it.
- Sealed at close. When the session ends, a SHA-256 digest is computed over the recording and written into an append-only ledger. Any later modification changes the digest.
- Hash-chained. Each ledger entry incorporates the previous entry’s digest, so removing or altering a record breaks every entry after it. Deleting one session is not a local edit; it is a visible discontinuity.
- Verified on export. Anything handed to an auditor, an IG, or a court is re-verified against its digest at the moment of export, and the verification is itself recorded.
Who reads it, and what they ask
| Reader | The question they actually ask |
|---|---|
| Internal affairs / IG | Who reached this record, when, and under whose authorisation? |
| CJIS auditor | Is every person with access to criminal justice information individually identified and authorised? |
| Defence counsel | Can you exclude the possibility that this evidence was altered administratively? |
| Contracting office | Did the contractor’s access end when the contract did? |
Give the auditor a login, not a binder
The last practical point is access itself. Producing evidence as a stack of exports puts your own staff between the auditor and the data, which is slow and, from the auditor’s perspective, unsatisfying. A read-only role that lets them search sessions and verify digests directly answers the integrity question far better than any document, because they are looking at the ledger rather than at your description of it.