Consent & Tamper-Evident Audit

Cookie Consent

Cookie consent controls what runs in a visitor's browser before they have agreed to it.

Where to find it

Architect Panel → Security:

• Cookie Consent — the console — categories, banner and what each category gates

Architect Panel → Configuration:

• Site Settings — where analytics and tracking tags are configured

Why this replaced what came before

The platform previously shipped two bolt-on banners. Neither blocked anything: they drew a banner while the analytics and pixel tags loaded regardless of the answer.

That is the one thing a consent tool has to get right. A banner that records a refusal and then loads the tracker anyway is worse than no banner — it creates a record showing you were told no and did it anyway.

Categories gate tags

Consent is organised into categories — strictly necessary, analytics, marketing and so on — and each category gates the tags assigned to it. A tag in a category the visitor has not accepted does not load.

Strictly necessary cannot be refused, and should contain only what genuinely is: the session cookie, the consent record itself. Anything you would like to have is not strictly necessary.

Setting it up

1. Define your categories, keeping them few and comprehensible.
2. Assign each tag or tracker to a category. Anything you cannot categorise is a good sign you should not be running it.
3. Configure the banner text. Say what the categories do in plain terms.
4. Make refusing as easy as accepting — a prominent Accept with a buried Reject is a pattern regulators have been explicit about.
5. Test with a fresh browser profile and confirm, in developer tools, that a refused tag genuinely does not load.

Test that it actually blocks

This is the step that matters and the one most often skipped. Open the site in a private window, refuse everything, and look at the network requests. If your analytics endpoint is still being called, the configuration is wrong — and you will not discover it any other way, because the banner looks correct.

Recording consent

The consent decision is recorded, which is what lets you demonstrate compliance. Keep those records — the ability to show what somebody was asked and what they chose is the point of the exercise.

Worked example

A site runs analytics and an advertising pixel. Both are assigned to non-necessary categories. A visitor refusing analytics gets a site that works identically, minus the measurement. The team verified this by refusing consent and confirming no request was made to either endpoint before shipping the change.

Recommendations

• Verify blocking in the browser, not by reading the configuration.
• Keep strictly necessary genuinely necessary.
• Make reject as easy as accept.
• Re-test after adding any new tag. A new tag with no category is the usual leak.

Tamper-Evident Audit and Read Logging

Two related controls: making the audit trail tamper-evident, and recording reads as well as writes.

Where to find it

Architect Panel → Activity:

• Audit Chain — the chain state and its verification points
• Record Read Log — who opened which record, and when
• Activity Log — the general activity trail

Why an ordinary audit trail is not enough

A normal audit table records what changed. It does not prove that the record of what changed has not itself been altered — and anybody with database access could edit or remove a row.

For most purposes that is acceptable. For an investigation, a regulator or a court, "the audit trail says so" invites the question of whether the audit trail could have been edited.

The hash chain

Each audit entry is stamped with a hash of its content, chained to what came before. Altering or removing an entry breaks the chain from that point onward, and the break is detectable.

This does not make tampering impossible. It makes it evident — which is the achievable and useful property.

Gaps are declared, not silent

One legitimate operation does remove audit rows: retention disposal, which deletes the audit for a record it destroys.

Rather than leaving a break indistinguishable from tampering, disposal declares the gap. So a verification run can distinguish "records were lawfully destroyed here" from "something was altered here" — which is exactly the distinction that matters.

Read logging

Write auditing answers who changed this. Read logging answers who looked at it — frequently the more important question.

Inappropriate access to records is far more often reading than editing: a member of staff looking up a neighbour, an ex-partner, a celebrity. No write audit will ever show that. The read log will.

Read logging has a cost

Every record opened writes a row, so the log grows quickly on a busy system. Enable it where the sensitivity justifies it — casework, HR, health, anything classified — rather than everywhere by default, and set a retention period for the log itself.

Using it

The read log is only useful if somebody looks. Two practical uses:

• Investigation — after a concern is raised, showing who accessed a record and when.
• Proactive sampling — periodically checking access to high-profile records, which is how inappropriate access is usually found rather than reported.

Pair it with break-glass review; between them they cover both the access that was refused and escalated, and the access that was permitted but questionable.

Worked example

A council receives a complaint that a resident's records were accessed by a member of staff who knows them personally. The read log shows three accesses over two months, none associated with any case activity. The write audit showed nothing at all, because nothing was changed — which is precisely why read logging was enabled on that datastore.

Recommendations

• Enable read logging on sensitive datastores, not everywhere.
• Set a retention period for the log — it is personal data too.
• Verify the chain periodically rather than only after an incident.
• Sample proactively. Waiting for a complaint means most inappropriate access is never found.