WordPress Consent Logs: How Long to Keep Them and What They Must Show

When a complaint arrives, the question is never whether the site had a banner. It is whether the site can show what a specific visitor was told and what they chose, on a specific date. Sites that cannot answer discover that an unlogged banner is nearly the same as no banner, evidentially.

WordPress makes logging easy to start and easy to neglect. Plugins record choices by default, then a site cleanup, a migration, or a well meant data purge quietly deletes the history the whole system existed to create.

What a complete record contains

At minimum: a timestamp, an identifier such as a user ID or an anonymized visitor ID, the purposes accepted or rejected, the version of the privacy notice and banner text in force, and the method, such as banner click or settings page. Screenshots of each banner version belong with the records, because text versions alone are hard to reconstruct later.

Store the record outside the cookie itself. A log that lives only in the visitor's browser is a log the visitor controls and the site cannot produce. Server side or plugin database records, backed up with the site, are the point of the exercise.

Retention: tie it to the data, not the calendar alone

A sensible rule is to keep consent logs while the data gathered under that consent is still held or used, plus a margin for the complaint and audit windows in your jurisdictions. Deleting the log while still emailing the list built on that consent inverts the logic of proof.

Indefinite retention has its own cost, because logs contain identifiers. The answer is a written schedule: define the period, anonymize or delete on schedule, and treat the schedule as part of the privacy documentation rather than a housekeeping afterthought.

Migrations and plugin changes are the danger moments

Consent history is most often lost when a site changes plugins, hosts, or consent platforms and the old records do not migrate. Any such change needs an export of the old logs first, stored with the site's compliance records, before the old tool is switched off.

Test restores too. A backup that has never been restored is a hope, not a record. Include the consent log in the list of things a restore must demonstrably bring back.

Make the log auditable by a stranger

Once a quarter, pick a random recent consent record and reconstruct the whole story from the log alone: what the visitor saw, what they chose, and what the site then did. If your own team cannot do it in fifteen minutes, an auditor will not manage it either.

That exercise also surfaces drift, like banner text that changed without a version bump, or purposes in the log that no longer match the settings page. Drift is normal. Unnoticed drift is the problem the audit exists to catch.

Frequently asked questions

What should a consent log include?

A timestamp, an identifier for the visitor or user, the purposes accepted or rejected, the version of the notice and banner shown, and how the choice was made. Keep copies or screenshots of each banner version so the record can be understood later.

How long should consent logs be kept?

At least as long as the data collected under that consent is retained or used, plus a margin for complaint and audit periods under your local rules. Set the period in a written retention schedule and apply it consistently.

Where do WordPress sites usually lose their consent logs?

During plugin changes, host migrations, and database cleanups, when old records are not exported before the old tool is removed. Export and store the history first, and verify that backups actually restore the log.

Can the consent record live only in a cookie?

No. A cookie is controlled by the visitor and can vanish at any time, and the site cannot produce it as evidence. Keep a server side or database record, backed up with the site, as the authoritative log.