The audit trail

01In a nutshell #sec_311beda8

The audit trail records what happened in REVIEWIT — who did what, when, on what, and with what result — in a form that can be shown to have not been tampered with afterwards.

02A precision of vocabulary #sec_fbdaf12f

In REVIEWIT, the word audit always refers to the audit trail: the trace of the acts performed in the product.

The acquisition of data from the client — the inventory of sites, groups, accesses — is called collection. The two have nothing to do with each other, and confusing them leads to looking for evidence where there is only inventory.

03The problem #sec_9df23eaa

A recertification tool produces evidence on the client's information system. A question then immediately arises, and it is the first one asked by a serious auditor:

And what proves what the tool itself did?

Without an answer, the whole system relies on the trust placed in the operator. Yet the gestures that matter most are precisely those that a malicious operator would have an interest in erasing: having excluded a resource from the scope, having set up a delegation, having canceled a campaign, having modified a rule just before a deadline.

Three requirements follow from this, and they are harder than they seem:

Record failures as much as successes. A trail that only records successful actions only proves what worked. Refused attempts, rejected accesses, security errors are often the most useful information.

Resist the one who holds the base. A trace protected by a mechanism that the operator controls is not evidence against the operator.

Never overestimate your own guarantee. A track that announces more protection than it provides is worse than a modest track: it produces unjustified confidence.

04The approach #sec_19917edd

The integrity of the track must not depend on a database engine or a host.

This is the structuring decision, and it was made against several easier solutions.

The immutability features offered by modern database engines, temporal tables and managed timestamping services have all been discarded. They work, but they shift trust to a third party — the engine publisher, the cloud provider — and they lock the product: an audit trail that does not survive a change of host is not a client asset.

The guarantee is therefore entirely applicative, carried by the product itself, and verifiable wherever it runs. This is consistent with the rest of the platform, which is deployed in the region chosen by the client.

Three principles complement this choice:

1. The foundation does not deactivate. There is no setting to turn off the audit trail — otherwise we would be deactivating the audit from the audit. What is configurable is the fineness of certain reading events, never the recording of acts.

2. An unknown act is still written. The catalog of actions lives in the database and currently has nearly two hundred and forty entries. But if a version of the product emits a code that the catalog does not yet know, the event is written anyway. Refusing to record what we do not know how to name would be the best way to create a blind spot.

3. We announce what is really guaranteed. The verification report indicates the level of protection actually in place — never the one that is planned.

05How it works #sec_e77f0329

Two capture paths

This is the most important architecture point, and it follows directly from the requirement to "record failures".

The transactional path serves successful acts. The event is deposited in the same transaction as the business act it describes. The consequence is absolute: if the act fails and the transaction is canceled, no orphan trace remains; if the act succeeds, its trace necessarily exists. There can be no discrepancy between what the product has done and what the track tells.

The autonomous path serves everything else: refused attempts, authentication failures, rejected accesses, security errors. These events have, by nature, no business transaction to cling to — the act did not take place. Without this second path, the track would only prove the successes.

The chaining

Each event receives an identifier, a sequence position assigned at writing, and a cryptographic fingerprint that includes that of the previous event. The track thus forms a chain: modifying a past event invalidates all subsequent ones.

Each chain opens with a genesis event placed in the first position. Without it, one could delete the first events of a chain and present it as complete.

The exact form of the data submitted to the fingerprint is normalized and versioned: two systems that verify the same track obtain the same result, today as in five years.

The mechanism has been tested against seven distinct forms of alteration — content modification, deletion, insertion, reordering — all detected.

The three levels of guarantee

The product explicitly distinguishes what it guarantees, and never claims the highest level.

The verification report is dated and announces the actual level. As long as the sealing is not in place, it indicates "chaining only" — and especially not N1. This discipline is deliberate: a report that overestimates its guarantee is worthless in front of an auditor who knows how to read.

The sealing key is dedicated

The key that seals the audit trail is never the one that signs the documents produced by the client.

The reason is simple: the one who can sign a report must not be able to seal the track that proves how this report was produced. Separating the two — and separating the audit base from the signer — is the condition for the sealing to mean something.

06What is recorded, and what is not #sec_548db5ca

The acts. Everything that modifies the state of the device: campaigns created, launched, canceled; decisions rendered; exclusions set and lifted; delegations put in place and revoked; rules modified; roles assigned; deletion requests issued and processed; configuration changed.

The attempts and refusals. By the autonomous path, as explained above.

The readings — in a graduated manner. Tracing each screen display would produce a volume that would drown out the useful information. Routine consultations are therefore sampled, with three exceptions systematically recorded:

• exports, because they take data out of the system;
• named personal data consultations;
• proof consultations, because knowing who looked at the file before a deadline has audit value.

Conversations with RITA — by fingerprint only. The track records that a question was asked and what resulted from it, never the text of the question. Keeping the content of the exchanges would amount to constituting a history of what users are asking each other, which is not the purpose of an audit trail.

Demonstration data — marked as such. Synthetic data sets remain possible, but their origin is marked, and this marking propagates to everything that derives from it. A demonstration must never be confused with production.

07Who sees what #sec_1be12c7e

Visibility is top-down: the administrator of a workspace sees the subscription-level events that designate their workspace — the creation of their scope, the assignment of their features, the modification of their allocation.

This is the necessary complement of delegated governance: an entity to whom autonomy is entrusted must be able to observe the decisions made above it that concern it. It sees nothing of the other entities, however.

The auditor has strict read-only access to the entire audit trail of their scope, and a search engine to navigate it.

08An assumed choice: starting from scratch #sec_c32441da

The new audit trail does not resume the history of the old one.

This is not a technical renunciation. The old journal offered no guarantee of integrity, its coverage was partial and its vocabulary ambiguous. Resuming it would mean introducing data into a sealed chain about which nothing can be affirmed — and therefore giving the impression that they benefit from a guarantee they never had.

Better a short and solid trail than a long trail whose first half proves nothing. The same reasoning applies to the replacement of the authentication system.

09What the auditor can expect #sec_7f268117

• A dated verification report, which asserts that the chain is intact — or precisely designates where it is not.
• The certainty that no completed action is missing, by transactional construction.
• The trace of refusals, and not just successes.
• The origin of each act: the author, the surface, the moment, the object, and the state before/after when it makes sense.
• An incremental export, to pour the trail into its own analysis tool or SIEM.

10To remember #sec_cc1ba3dd

A compliance product that cannot account for its own actions asks to be taken on faith. The audit trail of REVIEWIT is built so that one does not have to do so.

It is inseparable from the product — non-deactivatable, fed in the same transaction as the acts it describes, including when these acts fail. It is independent of the infrastructure, therefore portable and verifiable everywhere. And it is honest about its own strength: it announces the level of guarantee it really brings, never the one it aims for.