Consent Management: Capture, Storage & Enforcement

Consent Management

Consent is the weakest lawful basis under GDPR and the one teams reach for by default, usually to their cost. It must be freely given, specific, informed, and unambiguous; it must be as easy to withdraw as to give; and when it's withdrawn you must stop the processing and usually delete what you collected under it. For anything genuinely necessary to deliver your service, contract is the correct and far more robust basis.

Where consent genuinely applies — marketing, non-essential cookies, optional analytics, sharing with third parties — the engineering problem is not the banner. It's that consent is state that must be enforced everywhere, forever, at the moment of every relevant operation. A consent record in a database that no code path checks is decoration. A user who withdraws analytics consent and continues to appear in your product analytics is a violation regardless of what the record says.

The other commonly underestimated piece is propagation. Consent applies to your processors too, so withdrawal must reach your email provider, your analytics vendor, your ad platform, and your CRM — each with its own API and its own latency.

TL;DR

Consent is the weakest lawful basis. Use contract for core functionality.
Consent must be specific and granular — one purpose per toggle, no bundling.
Opt-in, not opt-out. Pre-ticked boxes and implied consent are not valid consent.
Withdrawal must be as easy as giving — if consent was one click, so is revocation.
Store a complete record: who, what purpose, when, which policy version, and how.
Version your consent text. A material change requires re-consent.
Enforce at the point of processing, not just at the banner.
Propagate to processors — your vendors must honor withdrawal too.

Quick Example

A consent record schema and an enforcement decorator:

Three properties carry the weight here. The store is append-only, so the full history is provable rather than just the current state. The default is deny — absence of a record means no consent, not implied consent. And enforcement is a decorator, so the check is structural rather than something each caller must remember.

Core Concepts

When consent is the right basis

The test for whether consent is even valid: could the user say no and still use the service? If refusing means the service doesn't work, the consent isn't freely given and isn't valid — you needed a different basis. Bundling consent for marketing into the terms of service is the classic version of this mistake and has been enforced against repeatedly.

Validity requirements

The last one has teeth. A one-click "Accept all" paired with a withdrawal buried three levels deep in settings behind five toggles is a violation that regulators have specifically targeted. If accepting is one click, rejecting must be one click.

Cookie banners

The most common technical violation is loading tags before the choice is made. Server-side tag management or a consent-gated loader is what actually prevents it — a banner that appears while the tracker is already reporting is worse than no banner, because it documents the violation.

Google Consent Mode and the IAB TCF are industry frameworks for signaling consent to ad and analytics vendors. They reduce integration work considerably and don't themselves make you compliant — the underlying consent still has to be validly obtained.

Versioning

A material change — a new purpose, a new recipient, a substantially different scope — invalidates prior consent for that purpose. Cosmetic rewording does not. Recording the exact text shown, not just a version identifier, is what lets you demonstrate later what a user actually agreed to.

Propagation to processors

This needs to be a durable, retried, monitored pipeline — not a best-effort loop of API calls in a request handler. A withdrawal that silently fails to reach the email provider results in the user continuing to receive marketing, which is the exact outcome the regulation exists to prevent and the one users complain about.

Consent vs. preferences

Keeping these separate matters. A user who consents to marketing and sets frequency to "monthly" has given one consent and one preference; collapsing them means either treating a preference change as a consent withdrawal or losing the consent record when preferences are updated.

Best Practices

Use contract, not consent, for core functionality

Consent is revocable and creates an obligation to stop. Processing genuinely necessary to deliver the service the user signed up for should rely on contract, which is more robust and doesn't create a withdrawal path that breaks the product.

Make the consent store append-only

A withdrawal is a new record, never an update to an existing one. You need to prove what was consented to and when, and an overwritten record proves only the current state.

Default to deny

Absence of a consent record means no consent. Never treat missing data, an error, or a cache miss as permission — a consent check that fails open is a violation waiting for its first outage.

Enforce with a decorator or middleware

Structural enforcement at the point of processing, not a check each caller must remember to write. A code path that skips the check is a violation you'll discover from a complaint rather than a test.

Record the exact text shown

Not just a version identifier — the actual wording. When a regulator or a user asks what they agreed to, reproducing the exact screen is the difference between a defensible position and an argument.

Make withdrawal exactly as easy as consent

One click to accept means one click to reject and one click to withdraw later. This is explicitly required and specifically enforced, and it's also the right product decision.

Build propagation as a durable pipeline

A queue with retries, dead-lettering, and alerting — not fire-and-forget API calls. Monitor the lag: a withdrawal that hasn't reached your email provider after an hour is an active violation.

Test the enforcement, not just the storage

An automated test that withdraws consent and then asserts the relevant processing does not occur. Testing that the record was written proves nothing about whether anything reads it.

Common Mistakes

Bundled consent

Pre-ticked boxes

Loading trackers before consent

Storing consent as a mutable boolean

Withdrawal that doesn't propagate

Checking consent only at the boundary

FAQ

Do we need a cookie banner?

Only if you set non-essential cookies or similar technologies. Strictly necessary cookies — session, authentication, load balancing, CSRF tokens — need no consent, though a privacy notice should still describe them. Analytics, advertising, and session recording do need consent in the EU and UK. The banner is not the compliance measure; the consent-gated loading behind it is.

Should we use a consent management platform?

For a marketing site with many third-party tags, yes — OneTrust, Cookiebot, Osano, and similar handle vendor discovery, TCF signaling, geo-specific rules, and the banner UI, all of which are tedious to maintain. For a product application with a handful of purposes and no ad tech, a well-designed consent table plus an enforcement decorator is straightforward and gives you more control. Many organizations use a CMP for the marketing site and their own implementation in the product.

How is consent different under CCPA/CPRA?

The model is inverted. GDPR is opt-in — you need consent before processing. CCPA/CPRA is largely opt-out — you may process by default, and consumers can opt out of the "sale" or "sharing" of personal information, with the Global Privacy Control browser signal legally binding in California. Practically, most organizations serving both build for the stricter GDPR model and honor GPC on top of it.

Does consent expire?

GDPR sets no fixed period, and regulators have indicated it shouldn't be indefinite — refreshing every 6 to 24 months is common guidance, with some national authorities specifying 6 or 12 months for cookies. Also refresh when the purpose materially changes or when a user has been inactive for a long period. Storing an expiry with each record makes this enforceable rather than aspirational.

What if a user withdraws consent for data we've already processed?

Withdrawal is prospective — it stops future processing, and it doesn't retroactively make past processing unlawful. However, you generally must delete the data collected under that consent, since you no longer have a basis to hold it. Derived aggregates that are genuinely anonymous can usually remain. Document which is which per purpose. See Data Retention & Deletion.

Can we infer consent from continued use?

No. Implied consent, browsewrap terms, "by continuing to use this site you agree," and scrolling as acceptance have all been rejected. Consent requires an unambiguous affirmative action. This is one of the clearest and most consistently enforced points in the regulation.