Having Consent Is Not Enough; You Must Prove It
Under KVKK, having obtained explicit consent is not sufficient on its own; in an audit you must be able to prove it. A consent record is a chain of evidence showing "who consented, when, to what, and with which version of the text". If this chain is missing, you may be treated as having processed data without consent in legal terms, even if you did obtain consent in practice.
In this article, we cover at the level of principles what elements the consent records that may be requested in an audit should contain, how these records should be stored, and what to do when consent is withdrawn.
Elements a Consent Record Must Contain
- Who (the subject). A unique identifier of the user who gave consent (for example, an anonymous visitor ID or an account ID).
- When (timestamp). The date and time consent was given.
- To what (scope). Which cookie categories or processing purposes were consented to; what was rejected.
- With which text (version). The version of the banner and privacy notice shown to the user at that moment.
- How (method). Through which interface and interaction (for example, a button) consent was obtained.
- Status changes. Later updates or withdrawal of consent and their timing.
What Must You Prove in an Audit?
| What Must Be Proven | What to Look for in the Record | Why |
|---|---|---|
| Free will | That a reject option was offered | The validity of consent |
| Being informed | The text version shown | The transparency principle |
| Scope | Categories accepted/rejected | Purpose limitation |
| Prior blocking | That no cookie was written before consent | The non-essential cookie rule |
| Withdrawal | The change and its date | The withdrawability of consent |
Steps to Build a Consent Recording Process
- On every consent interaction, record who, when, which scope, and which text version together.
- Version every release of the banner and privacy notice; link which user saw which version.
- Keep technical evidence (a blocking log) showing that no non-essential cookies were written before consent.
- Store the categories the user rejected just as clearly as the positive acceptances.
- Keep consent withdrawal and update events as separate records with timestamps.
- Store records in a tamper-evident form that can be produced within a reasonable time in an audit.
- Define a retention period; keep the consent evidence for as long as the relevant processing continues and a limitation period may apply.
Common Mistakes
The most common mistake is keeping only the "accepted" flag without recording the text version and scope; in that case you cannot prove exactly what the user consented to. The second mistake is not recording rejected categories; yet a rejection carries at least as much evidentiary value as an acceptance. The third is failing to track consent withdrawal events. The fourth is keeping records in scattered systems in a form that cannot be produced within a reasonable time in an audit.
Example Scenario
An online publisher reviews its consent records in preparation for an audit. For each visitor, the system stores a unique identifier, the consent timestamp, the accepted and rejected categories, and the version number of the banner text shown, all together. Because the publisher updated the banner text three months ago, two different text versions exist; each record points to which version was seen. A user withdrew last month the consent they had given to marketing cookies; the system recorded this as a separate event with date and time. When the auditor asks, "Exactly what, when, and with which text did this user consent to?", the publisher can show the entire chain from a single record: identity, time, scope, text version, and the subsequent withdrawal.
Frequently Asked Questions
How long should I keep the consent record?
KVKK does not give a general numeric period; the principle is to keep the record limited to its purpose. In practice, it is considered reasonable to preserve the consent evidence for as long as the relevant processing activity continues and evidence may be needed in a possible dispute. When the period expires, you should destroy the record.
Is it enough to keep only the "accepted" flag?
No. "Accepted" alone does not show to what, when, and with which text consent was given. To carry evidentiary value in an audit, the record must contain at least the who, when, which scope, and which text version elements.
Should I also record the user's rejection?
Yes. A rejection record shows that the user did not want cookies to run in that category and that you complied. This is as important as an acceptance for proving that preferences are respected.
If I update the banner text, do old consents become invalid?
Changing the text version means the information shown has changed. That is why you must version every release and link which user saw which version. For significant changes, you may need to obtain consent again for the affected purposes.
This content is for general information purposes only and does not constitute legal advice.
With JUS. you can automatically keep your consent records with who, when, and which text version information, run your cookie scan for free, and request a demo to see audit-ready consent management in action.