What a record has to contain
The duty is to be able to demonstrate that a particular person consented to a particular thing. A count of acceptances does not do that. A record that identifies the decision but not what was being decided does not either, because the wording changes over time.
Note what is stored and what is derived. The record holds the resolved location, not a jurisdiction name or a consent model. Those are computed from that location and the published configuration, both of which the record points at, so they can be recalculated from the evidence rather than being a label you are asked to trust.
| Field | Why it is there |
|---|---|
| Property | Which site the decision was made on |
| Visitor key | A pseudonymous identifier, not a name or an email |
| Categories | What was granted and what was refused |
| Region | The resolved location: US-CA, GB, or empty where geolocation failed |
| Source | banner or preference_center, the surface that collected it |
| Timestamp | When |
| Configuration version | Exactly what the visitor was shown |
| Chain hash | Links the record to its predecessor on that property |
Why the configuration version is the important one
Banner copy, category descriptions and the technology list all change. A record that says "accepted analytics on 4 March" is worth little if nobody can say what "analytics" meant on your site that day. Published configurations are versioned and immutable, so the pointer resolves to something readable.
It also determines when you have to ask again. A privacy-relevant republish (new categories, new technologies, changed descriptions) invalidates the basis of an old decision. An appearance-only change does not, and StrongPrivacy distinguishes the two rather than re-prompting every visitor because a colour changed.
Getting it out
- Records are browsable and exportable as CSV, with the columns id, visitor_key, site, region, categories, configuration_version, source and recorded_at
- Retention runs 12 months on Free and Starter, 24 on Growth, 36 on Agency
- The record is pseudonymous by design; it is evidence of a decision, not a customer profile
The records form a hash chain
Each record stores a hash of itself and of its predecessor on that property, written inside the same transaction that appends it. Altering or removing a record afterwards breaks the chain from that point on, which makes the ledger tamper-evident rather than merely append-only: the difference between a log you assert is complete and one that can be shown to be.
Common questions
Is a consent record personal data?
Generally yes: it relates to an identifiable individual even when the identifier is pseudonymous. That is why it holds a visitor key rather than a name, and why retention is bounded rather than indefinite.
How long should consent records be kept?
Long enough to answer a challenge about a decision that was relied on, and no longer. Plan retention here runs from 12 to 36 months. Keeping them forever creates its own minimisation problem.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- Regulation (EU) 2016/679 (GDPR)
Legislation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.