There is a particular kind of confidence that privacy teams develop when they have a consent banner running, a privacy policy on file, and a DPA nominated. It feels like coverage. An external audit tends to disrupt that confidence, not because the fundamentals are wrong, but because GDPR consent validity is verified at a granular level that most internal teams haven't tested against.
What follows are the six items that come up repeatedly in GDPR consent audits — not the obvious ones (you have a banner, you have a policy), but the specific evidence failures that result in findings. This is not legal advice; it is a synthesis of what auditors and DPAs examine when they open a consent file.
1. Banner Version Capture at Consent Time
GDPR Article 7(1) requires that you be able to demonstrate consent was obtained. The EDPB's guidance on this is specific: you need to show not just that a visitor clicked Accept, but what they were presented with when they did. If your banner wording changed between a consent event and an audit, you must be able to produce the exact banner text that was shown to that specific visitor on that specific date.
Most audit logs store "visitor X consented to analytics at time T." Fewer store the banner version identifier alongside that event. If you've updated your banner wording — say, to reflect a new data processor added in 2024 — and you cannot produce the version shown to each visitor whose consent you're relying on, the consent records for visitors who consented under the old wording become difficult to verify. Auditors ask for this; many organizations cannot provide it.
The fix: assign an immutable version identifier to every banner configuration. Log that identifier alongside every consent event. Store banner version snapshots so you can reconstruct exactly what any version contained.
2. Reject Path Equivalence
The CJEU's Planet49 judgment (Case C-673/17) and subsequent EDPB guidance make clear that withdrawing or refusing consent must be as easy as giving it. In practice, this means the Reject All path must not require more clicks, more screens, or more cognitive load than the Accept All path.
Audit evidence here is straightforward: document the click count for Accept All versus the click count for Reject All. If they are unequal, you have an asymmetry that multiple DPAs — particularly the CNIL in France and the DSB in Austria — have cited in enforcement decisions. A three-click opt-out against a one-click opt-in is a documented non-compliance pattern, not an edge case.
We are not saying that showing a preference center is inherently non-compliant. A "Manage preferences" option on a banner with both Accept All and Reject All is entirely valid. What is not valid is making the preference center the only route to rejection while Accept All is always one click away.
3. Consent Granularity Matching Your Purposes
If you process data for advertising, analytics, and personalization under separate consent purposes, your consent records need to reflect granular per-purpose choices, not a single binary Accept. A visitor who accepted analytics but rejected advertising has two distinct consent states; your audit log needs to store them as two distinct events linked to the same session.
The IAB TCF (Transparency and Consent Framework) provides a structured way to encode this via TC strings — a base64-encoded bitfield carrying vendor consents and purpose consents per the TCF specification. If you're running programmatic advertising through an SSP or DSP that requires TCF compliance, your consent infrastructure needs to generate valid TC strings, not just set proprietary cookies. Auditors examining ad tech compliance will ask for TC string records, not just your internal consent log.
For organizations not in the ad tech stack, the simpler path is ensuring your consent purposes map one-to-one to the data processing activities described in your ROPA (Records of Processing Activities). Consent to "analytics" that covers both behavioral analytics and A/B testing platform data should ideally be two purposes, not one, if the data flows to different processors.
4. Withdrawal Mechanism and Confirmation
GDPR Article 7(3) gives data subjects the right to withdraw consent at any time, with effect from withdrawal. Two failures are common here. First, the withdrawal mechanism is buried — typically in a cookie policy page, accessible via a footer link, with no clear "Reopen preferences" option available on the site without navigating there. Second, withdrawal events are not timestamped and stored in the same audit log as the original consent, making it impossible to demonstrate that processing stopped within a reasonable time after withdrawal.
A healthcare information platform that operates with EU visitors illustrates the risk well: a user who originally consented to analytics in January and withdrew in March has a consent lifecycle that spans both events. If the March withdrawal event is not in the audit log — or if analytics continued to fire between the withdrawal click and the next server-side sync — the consent basis for that processing window has a gap. Auditors do check withdrawal events, not just consent events.
5. Geo-Triggered Banner Consistency
If your site serves both EU visitors (GDPR scope) and California residents (CCPA scope), your consent infrastructure needs to serve the correct banner type to each. GDPR requires opt-in consent for non-essential processing; CCPA requires an opt-out mechanism (Do Not Sell or Share) for California residents. These are architecturally different interactions.
Audit evidence here means being able to show that every EU-IP visitor received a GDPR-compliant banner, and every California-IP visitor received a CCPA-compliant opt-out link. Geo-IP matching is not perfect — VPNs, corporate proxies, and IPv6 blocks complicate it — but documented, reasonable-effort geo-targeting is generally sufficient for DPA purposes. What is not sufficient is applying the weaker standard universally because "it's simpler." Showing a CCPA notice-only banner to German visitors is a compliance failure, not a simplification.
6. Audit Log Retention and Export Readiness
The final item is not about what you capture, but about how long you keep it and how quickly you can produce it. GDPR's accountability principle under Article 5(2) requires you to demonstrate compliance. That demonstration requires records. There is no explicit statutory retention period for consent records in the GDPR text, but common guidance from DPAs suggests retention at least as long as the processing it covers — and practically, many teams target 24 to 36 months as a working floor for consent event records.
The export readiness question is operational: if a DPA requests consent records for a specific visitor session, how long does it take your team to produce them? "We'll need to ask the engineering team" is an answer that signals the records exist but are not audit-ready. Audit-ready means: queryable by visitor ID, exportable as a structured file (CSV or JSON), and producible within the response deadline. In a SAR (Subject Access Request) context, that deadline is one month under GDPR Article 12.
Running through all six items as a tabletop exercise — before an audit, not during one — takes a few hours and tends to surface the two or three gaps that are otherwise invisible until a regulator finds them first.
This article is for educational purposes and does not constitute legal advice. Consult qualified legal counsel for your specific GDPR compliance obligations.