The Consent Banner That Remembers Too Much

Finding 1 - consent validity / provenance defect. A consent timestamp predating the platform that supposedly captured it is internally inconsistent. Either the record was migrated or backfilled, or the timestamp is wrong. Either way the organization cannot demonstrate when and how consent was obtained, which is the core evidentiary requirement. This is a validity/provenance defect even if the users genuinely consented on web.

Finding 2 - consent validity defect (the most serious). Pre-enabled legitimate-interest toggles for advertising, combined with 'by continuing you accept' copy, do not constitute an affirmative, specific action. Continued browsing is not a clear affirmative act, and bundling advertising into a default-on setting fails specificity. Under an opt-in regime, this is the finding that most directly undermines lawfulness, because it affects the entire population exposed to that banner, not just a sample subset. The 9 sampled users are a symptom; the defect is systemic.

Finding 3 - technical enforcement defect. Consent withdrawal was recorded but not propagated to downstream ad systems for 11 days. The record is fine; the control failed. This is a processing-without-basis gap for those 5 users during the 11-day window.

Finding 4 - records/retention defect. Storing full IP and user-agent indefinitely with no limit is a storage-limitation and minimization issue. It does not invalidate consent, but it creates secondary exposure.

Ranking: Finding 2 is the most damaging because it is systemic and definitional - it means consent was never validly obtained for the advertising purpose across the whole user base. Finding 1 is next because it destroys the audit trail. Finding 3 is serious but bounded and remediable. Finding 4 is a hygiene issue that compounds the others.

No. Changing the copy while keeping a single 'Accept all' button does not cure the specificity problem. A valid opt-in requires granular, purpose-specific choice. A lone 'Accept all' with no equally prominent reject or granular options means the user cannot consent to advertising specifically while declining other purposes.

Additional problems with the proposed fix:

• 847 partners is not meaningful transparency. Users cannot form specific consent to 847 unnamed recipients. The vendor should surface categories and a partner list, not a number.
• No reject path means the only way to use the site is to accept advertising - that is closer to forced consent than free consent.
• The underlying toggle logic (pre-enabled legitimate interest) is untouched. If the backend still defaults advertising personalization on, the copy change is cosmetic.

What a defensible design looks like: a first-layer banner offering 'Accept all', 'Reject non-essential', and 'Manage preferences'; purpose-level toggles that default to off for advertising; a partner list link; and a logged record of the specific choices made. The audit test is not 'is the copy clearer' but 'can a user decline advertising and still use the service, and is that choice recorded and enforced?'

Objective: estimate the rate and distribution of withdrawal-to-suppression lag, not just confirm the 5 observed cases.

Population definition: all withdrawal events in the review period, stratified by channel (web vs. mobile), by downstream ad system, and by whether the user had an active ad identifier. These strata matter because the lag likely lives in a specific integration (e.g., one DSP sync job), and a flat random sample would under-sample the affected stratum.

Sampling approach:

1. Attribute-based targeting first. Pull all withdrawals where the first post-withdrawal ad event is more than 24 hours later. This is a census of known failures, not a sample - cheap and high-yield.
2. Stratified random sample of the remaining withdrawals - e.g., 60 per stratum - to estimate the baseline lag and detect failures the attribute query missed (e.g., events logged under a different identifier).
3. Negative control: sample users who never withdrew and confirm their ad events continue, validating that the query logic distinguishes the two groups.

Evidence to capture: the withdrawal timestamp, the suppression job's run log, the downstream event timestamp, and the identifier mapping used. Preserve the raw logs with hash values and a chain-of-custody note.

Metrics: median and 95th-percentile lag per stratum, plus the count and percentage exceeding the contractual or policy SLA (e.g., 24 hours).

Conclusion logic: if the attribute query returns failures concentrated in one stratum and the random sample shows baseline lag under SLA elsewhere, the defect is a specific integration bug, not systemic. If the random sample also shows multi-day lags broadly, escalate to a systemic control failure.