# Your Reject Button Logs Nothing: Why Half Your Consent Records Are Missing

Source: https://cookiebastion.com/blog/2026-11-15-reject-button-logs-nothing.html

[Home](../index.md) / [Blog](index.md) / Your Reject Button Logs Nothing: Why Half Your Consent Records Are Missing


Published 2026-11-15

Open your consent log and filter for rejections. On most sites the result is a thin file or an empty one, next to a thick file of accepts with timestamps, purposes, and banner versions. The accept side is a record. The reject side is a shrug. That asymmetry is the problem, because a log that records agreement but not refusal cannot prove the banner offered a real choice, and it makes your acceptance rate look fabricated.

GDPR Article 7(1) puts the burden where it belongs: where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented. Demonstrate means produce the record, not describe the system. Italy's Garante has sanctioned organizations that could not produce consent records during audits. The record is the compliance. Everything else is a story about the record.

## The six fields a record needs

Six fields cover the regulatory core. A pseudonymous visitor identifier, usually the consent cookie ID. A timestamp, in ISO 8601 format. The categories or purposes accepted and rejected, both of them. The banner and privacy notice version shown, because consent to version three says nothing about version five. The method, banner click, settings save, or continued configuration. And the jurisdiction or banner variant, since the choice offered in California differs from the one offered in France.

The field teams skip most often is the purposes rejected. The CMP logs the accept with a full purpose list and logs the reject as a single event with no detail, or does not log it at all. The fix is a configuration check, not a rebuild: open the CMP's log export, filter for a rejection from yesterday, and confirm the record carries the same six fields as an accept. If it does not, the CMP is not logging refusals, and the gap is yours to fix, not the vendor's to explain away.

## The refusal is the proof

A refusal record does two jobs. First, it proves the choice was real. A 98 percent accept rate with no refusal records reads as a banner that never offered a genuine no, and regulators know what that pattern looks like. Second, it proves the refusal was honored. A log proves a choice was recorded. It does not prove the choice was honored. The honoring proof lives in the tag logs: which vendors fired after a refusal, and which ones stayed quiet. Keep both, and keep them linkable by the same identifier and timestamp.

## The retention question

How long to keep the records is the question every team gets wrong in opposite directions. The governing principle is that the record should outlive the reliance. While a consent is active and you are processing data under it, the record must exist. After the consent expires or is withdrawn, you still need the record for the period in which a complaint or claim could plausibly be made, which for most sites lands at one to three years after lapse, aligned with limitation periods in their main markets. Some frameworks stretch further: marketing consent records are often kept for the duration of consent plus three years, and UK guidance for SMS consent runs to six years from withdrawal.

Indefinite retention is the opposite failure. A consent log is personal data, with storage-limitation duties of its own, and a decade of records about people who last visited in 2019 is a breach surface with no evidentiary value. Set a retention period, automate deletion, and write both into your records of processing. Then test it: pull one refusal record from a year ago and one accept record from the same week, and confirm both are complete, linkable to the tag logs, and inside the retention window. If the refusal side comes back empty, you found the gap before an auditor did.

Keep reading: [CMP Free Plans: What the Free Tier Quietly Leaves Out](https://cookiebastion.com/blog/2026-11-14-cmp-free-plan-what-it-leaves-out.md), [The Reject Button That Logs Nothing: Consent Records After a No](https://cookiebastion.com/blog/2026-11-13-reject-button-logs-nothing-consent-records.md), [Your A/B Test Needs Consent First: The Testing Cookies Nobody Banners](https://cookiebastion.com/blog/2026-11-14-ab-test-needs-consent-first.md) cover the nearby cases in this series.

## Frequently asked questions

### What fields does a consent record need?

Six fields cover the core: a pseudonymous visitor identifier, a timestamp, the purposes accepted and rejected, the banner and privacy notice version shown, the collection method, and the jurisdiction or banner variant. The purposes rejected matter as much as the purposes accepted.

### How long should we keep consent records?

For as long as the processing they authorize is active, plus a period covering plausible complaints, commonly one to three years after the consent lapses or is withdrawn. Some frameworks run longer, up to six years for SMS consent in the UK. Indefinite retention is its own violation.

### Why does the refusal matter if nobody complains?

Because a log that records agreement but not refusal cannot prove the banner offered a real choice, and an acceptance rate near 100 percent with no refusal records looks fabricated. The refusal record is also the proof that the refusal was honored downstream.

### What if our CMP only logs accepts?

Then your records are half a record. Check the CMP's log export for a rejection from yesterday and confirm it carries the same six fields as an accept. If it does not, change the CMP configuration or move to a tool that logs refusals with full detail.