The chain that reports every gap

The second question a good auditor asks

The first question every auditor asks is simple: "Show me what happened." Most systems can now do that tolerably well — a record, a log file, an audit trail that writes down every action. Anyone who stops at that first answer, however, has passed only half the audit.

The second question is less comfortable: "How do I know that nobody has deleted or changed anything here afterwards?" A text file that is only appended to by convention is exactly that — a convention. It holds as long as everyone with write permission on that file abides by it. A system administrator with a text editor can remove a line, and afterwards the file looks just as complete as before. Nobody would notice, unless they happened to have an older copy for comparison.

For a tool whose entire business model rests on evidence, this second question is not optional. It is the actual point.

How the chain really solves this problem

JiCo's answer is a hash chain, and the principle behind it is surprisingly easy to explain, even though the implementation takes care: every line in the audit trail and in the outbound ledger carries two values — the cryptographic hash of the immediately preceding line, and a hash of its own covering both together, the predecessor hash plus its own content. This chaining does not break at day boundaries; it runs through across daily files.

The effect: if any line is changed or deleted afterwards, or a new one is pushed in between, the hash of the next line no longer matches its supposed predecessor. The check finds the exact place at which the chain breaks — with file name, line number and the concrete reason: changed, because the content no longer matches the stored hash; deleted or reordered, because the predecessor hash no longer fits; or a missing daily file where one should have been.

This is deliberately a chain and not a signature with a single key. The difference matters more than it sounds at first: a signature whose private key sits on the same machine as the data to be protected can be reapplied by anyone who already has access to that machine — a manipulated record would simply be signed again, and the signature would look "valid" once more. The chain makes any change inside the file immediately visible. But against a complete rewrite of the whole history, or a clean truncation at the end, even the cleverest chain is of no help as long as the evidence sits entirely on the same machine as the possible attacker.

Hence the checkpoints outside the machine

This is exactly where the checkpoints come in, and they are the part of the system that makes the chain truly probative in the first place. The current head of the chain — its most recent chained fingerprint, so to speak — is written hourly into the record as an event of its own, with the option of additionally forwarding it to a customer's SIEM system, where one is in use.

Anyone who has captured that head at a particular moment somewhere outside the machine — in their own SIEM, in a file, noted down during a routine check — can at any later time demand that precisely this head still be part of the current chain. If it is not, something has been manipulated in the meantime, and demonstrably after that moment. This check is performed by the command jico audit check --against audit=HASH. The actual probative force therefore does not lie in the file itself — a file alone can always be replaced in its entirety — but in the fact that somebody outside the machine documented a point in time against which an independent check can be made later.

The difference from an ordinary log folder

Most systems that claim to keep an "audit log" in fact mean by that little more than a collection of text files with timestamps lying somewhere on a server. That is better than no record at all, but it answers only the first of the two questions above — what happened — not the second: whether somebody has tampered with it afterwards.

The difference from a hash chain at this point is not a question of how often things are logged, but a question of the burden of proof. In case of doubt, an ordinary log can only assert that it is complete — somebody with sufficient permissions would simply have to be believed. A chained, externally anchored record can actually prove that completeness, regardless of who currently holds administrator rights on the affected system. For an internal audit or a request from a data protection authority, exactly this difference is decisive — not whether something is logged, but whether the record itself can be shown to be unaltered.

What this chain secures — and what deliberately stays outside

Here a second look is worthwhile, because it shows that evidence and data minimisation are not two goals at JiCo that have to be weighed against one another, but coincide in the same file: the chain contains no plain text. What it secures is the redaction balance — how many matches of which type the gate caught in a particular operation — not the caught values themselves.

An auditor checking the chain thus receives exactly the evidence they need: that the process was complete, that nothing was changed afterwards between proposal, decision and execution. They do not receive the personal data that the process was originally about — for that they would still need their own, separately justified access to Jira or to a mapping that is still running and not yet expired. This is not a compromise between two competing requirements. It is the realisation that auditing a process and knowing its contents are two different things — and that for the first you do not need the second at all.