Almost every consent plugin advertises logging. Almost nobody has ever looked at their log. That gap stays invisible until the day a visitor exercises a right or a regulator asks a question, at which point the log becomes the most important table in the database.
Auditing your own consent log in peacetime is an hour's work. It tells you whether you own evidence or merely believe you do, which are very different positions to defend from.
Locate the log before you need it
Start in the consent plugin's settings and look for records, proof of consent, or statistics sections. Some plugins store locally in custom database tables; others sync to the vendor's cloud and show only summaries in the dashboard. Either can work, but you must know which you have.
Check what triggers a record. Good systems log every consent state change per visitor: initial choice, later adjustments, and withdrawals. Weaker ones log only banner clicks on the first visit, which misses the changes that matter most in a dispute.
Run the export test on yourself
Visit your site in a private window, make a distinctive set of choices, then go and find your own record. Time how long the whole exercise takes and note what the record contains: timestamp, categories chosen, the notice or banner version, and an identifier you can match to your visit.
If you cannot find yourself, neither can your future self under pressure. Fix the process now: document where logs live, who has access, and the exact export steps, and keep that document outside WordPress too.
Retention inside the log itself
Plugins often offer log retention settings, and defaults vary wildly. Too short and your evidence expires while the data it authorised is still in use. Too long and the log itself becomes an unmanaged personal data store, especially where it holds IP addresses.
Align the retention with your consent record policy and check the setting after plugin updates, which have been known to reset preferences. The log's expiry should be a decision you made, not a default you inherited.
When the log and reality disagree
Spot check the other direction too: pick a recorded consent and verify the site actually honours it, by loading the site with that state and watching which scripts fire. A log that says refused while analytics still loads is worse than no log, because it documents the failure.
Disagreements usually trace to tag manager configurations or hard coded scripts outside the consent system. The log is the promise; the page behaviour is the truth. Audits should always compare the two, in both directions.
Related reading
These earlier guides go deeper on connected questions: WordPress Consent at WooCommerce Checkout WooCommerce checkout collects plenty and loads more. How consent interacts with checkout trackers, payment iframes, and the order data you must keep anyway., Consent and WordPress Comment Forms: The Forgotten Data Comment forms collect names, emails, and IP addresses, and most WordPress sites never think about their consent and retention. A small, fixable corner of site privacy., and Consent on WordPress Membership Sites: Logged In Does Not Mean Consented Membership sites track logged in users heavily and often assume the account terms cover everything. Separating account consent from tracking consent on WordPress..
Frequently asked questions
Where exactly are consent logs stored in WordPress?
Usually in plugin specific tables in the WordPress database, or in the plugin vendor's cloud for hosted consent services. Your plugin's documentation or a look at tables named after the plugin will tell you which model you have.
Can I export consent logs for a subject access request?
You should be able to export records matching the requester's identifier, such as their consent ID or account. Test the export format in advance; a raw database dump is not a usable answer for a person exercising their rights.
How long should WordPress consent logs be kept?
For as long as the processing they authorise continues, plus a defined period for complaints and claims, mirroring your general consent retention. Then delete or anonymise them on schedule, automatically where the plugin allows.
What if my plugin does not log consent at all?
Then your banner is a preference widget, not a consent system, and any processing that needs demonstrable consent is exposed. Migrate to a plugin or service with real records, and treat the change as urgent rather than cosmetic.