# Consent Records: What to Keep When a Visitor Says No

Source: https://cookierampart.com/blog/2026-11-11-consent-records-what-to-keep.html

[Home](../index.md) / [Blog](index.md) / Consent Records: What to Keep When a Visitor Says No


Published 2026-11-11

Everyone logs the accepts. The consent platform records who said yes, when, and to what, because the marketing team wants to know how many people opted in. Almost nobody logs the rejections properly. The visitor who said no gets a cookie, a banner that does not reappear, and nothing else. The audit will ask about that visitor, because the visitor who said no is the one whose data the site was not supposed to touch.

A rejection is a consent event, not the absence of one. GDPR Article 7 says the controller must be able to demonstrate that the data subject consented. The same logic applies in reverse: when a visitor declines, the site has to be able to demonstrate that it stopped. A site that cannot produce the rejection record cannot prove it honored the rejection, and a rejection that cannot be proved is a rejection the site has to assume it violated.

## The six fields that make a record

The SecurePrivacy audit guide lists what a valid consent log needs at minimum: a user or device identifier, a precise timestamp, the specific purposes consented to or declined, the banner version shown at the time, the collection method, and a record of any subsequent changes or withdrawals. Six fields. A rejection record needs all six, exactly like an accept record, because the audit does not ask what the visitor said yes to. It asks what the visitor said, full stop.

The banner version is the field teams skip most often. A rejection recorded against banner version 4 means the visitor saw the purposes as they were listed in version 4. If the tracker list changed in version 5, that rejection still stands for the purposes as they were, and the site has to know which version the visitor saw to know what they rejected. The WPLegalPages consent audit guide makes the same point: the log has to show what the user was shown, not just what they clicked.

The timestamp has to be precise, date, time, and timezone, in ISO 8601 format. A rejection logged as November 11 is not a record. A rejection logged as 2026-11-11T14:32:07Z is. The difference matters when a visitor complains that their data was used after they declined, and the site has to show that the use stopped before the complaint, not after.

## How long the no has to live

Consent logs must be retained for as long as the processing they authorize continues, plus the applicable limitation period for regulatory enforcement, typically three to five years after processing ends. A rejection record has the same retention as an accept record, because the rejection is what justifies the absence of processing. Delete the rejection, and the site has no answer when someone asks why a visitor's data is not in the system. Keep it, and the absence is explained.

The practical failure is that most consent platforms store the accept in a database and the rejection in a cookie. The cookie expires, the browser is cleared, the device is replaced, and the rejection is gone. The site has a database full of yeses and no memory of the nos. The fix is to write every consent event, accept or reject, to the server-side log at the moment it happens, with all six fields. The cookie is a convenience for the browser. The log is the proof.

## The test that takes ten minutes

Reject everything on the site, then check the consent log. The rejection should be there, with all six fields, within seconds. Then check it again in a week, after the cookie has expired or been cleared. The rejection should still be there. If it is not, the site is logging accepts and forgetting rejections, and the audit will find that out before the team does.

Then test the withdrawal the same way. Accept, then withdraw, then check the log. There should be two events, linked by the same identifier, with the withdrawal timestamped after the accept. If the log shows one event, or two events with different identifiers, the site cannot prove the withdrawal happened, and the processing that continued after it is unexplained.

Keep reading: [the CMP migration records checklist](https://cookierampart.com/blog/2026-11-08-cmp-migration-checklist-records.md), [consent renewal intervals](https://cookierampart.com/blog/2026-11-06-consent-renewal-intervals.md), and [what happens when consent cookies are cleared](https://cookierampart.com/blog/2026-11-08-consent-cleared-cookies-reprompt.md) cover the nearby cases in this series.

## Frequently asked questions

### Do I have to log rejections, or only accepts?

Both. A rejection is a consent event, not the absence of one. The site has to be able to demonstrate that it honored the rejection, and a rejection that cannot be proved is a rejection the site has to assume it violated.

### What fields does a consent record need?

Six at minimum: a user or device identifier, a precise timestamp, the specific purposes consented to or declined, the banner version shown, the collection method, and a record of any subsequent changes or withdrawals.

### How long must consent records be kept?

For as long as the processing they authorize continues, plus the limitation period for enforcement, typically three to five years after processing ends. A rejection record has the same retention as an accept record.

### What if the visitor clears their cookies?

The server-side log should still hold the rejection. The cookie is a convenience for the browser. If clearing the cookie erases the history, the site is logging accepts and forgetting rejections.