These questions landed in my inbox last week after our team ran a workshop on lawful basis selection. Every one came from a practitioner who'd hit the same wall: consent sounds clean on paper, but it's a mess in practice.
The questions below reflect what I'm hearing from consent managers across sectors. Some are wrestling with GDPR Article 7 requirements. Others are trying to reconcile what their legal team wants with what users will actually tolerate. Most are just tired of consent interfaces that satisfy nobody.
Where Does Consent Break Down Most Often?
Three places, consistently.
First: the consent request itself. You're asking users to parse legal concepts while they're trying to complete a task. GDPR requires that consent be "freely given, specific, informed and unambiguous" (Article 4(11)), but you're delivering that in a modal that interrupts checkout or blocks content. The user clicks "Accept All" because you've made rejection harder than agreement. That's not freely given consent. It's design coercion.
Second: consent withdrawal. Article 7(3) says it must be "as easy to withdraw consent as to give it." But your preference center is buried three clicks deep, and the withdrawal button is styled differently than the acceptance button was. You're compliant on paper. You're non-compliant in practice.
Third: consent refresh. User context changes. Your processing purposes expand. The consent you collected eighteen months ago doesn't cover what you're doing now, but you haven't built a system to detect that gap or re-prompt appropriately. You're processing on stale consent, which is no consent at all.
Can We Use Legitimate Interests Instead?
You can, but you're trading one compliance risk for another.
Legitimate interests (Article 6(1)(f)) works when you can demonstrate a balanced interest that doesn't override the user's rights. That means you need a documented Legitimate Interests Assessment showing you've weighed your business need against user expectation and impact. It's not a free pass. It's a different test.
Consent is harder to execute, but it's clearer to audit. Legitimate interests is easier to implement, but it's harder to defend if challenged. The European Data Protection Board has made clear that you can't use legitimate interests as a fallback when consent is too difficult to obtain properly. If the processing requires consent under the ePrivacy Directive (cookies, direct marketing via electronic means), legitimate interests won't save you.
The real answer: fix your consent mechanism so it actually meets Article 7 requirements, or redesign your processing so legitimate interests genuinely applies. Don't just relabel the lawful basis and hope.
Are Our Consent Rates Normal?
That number tells me you're probably doing consent more honestly than most, but it also means 60% of your intended audience isn't accessible under that lawful basis.
Consent rates vary wildly by sector and request context. A financial services app asking for transaction analysis consent at account opening might see 70%. A media site asking for ad targeting consent from anonymous visitors might see 15%. Neither number is inherently wrong.
What matters: are you designing the request to be genuinely optional? If you're seeing high acceptance rates because you've made rejection require five clicks and a CAPTCHA, your consent isn't freely given. If you're seeing low rates because you're asking for everything at once instead of just-in-time requests, you're leaving legitimate consent on the table.
The diagnostic question: what happens to users who decline? If your product is still useful and your business model still works, your consent rate is honest. If decliners hit a dead end, you've built a take-it-or-leave-it offer, which isn't consent.
How Do We Handle Consent with Multiple Tools?
You're describing consent fragmentation, and it's a design failure, not a legal requirement.
GDPR requires that consent be specific (Article 4(11)), meaning you can't ask for blanket permission to "process your data however we want." But specific doesn't mean you need a separate toggle for every vendor. You need separate consent for each distinct purpose.
If you're using three analytics vendors to accomplish the same purpose (understand site usage), that's one consent question: "We'd like to analyze how you use our site to improve it." The fact that you're using Vendor A, Vendor B, and Vendor C to do that is a transparency obligation (Article 13), not a consent-splitting obligation.
If you're asking users to consent to analytics, marketing, personalization, and social media sharing, those are four purposes. Four questions. But you present them in a single, well-designed interface, not as a gauntlet of sequential pop-ups.
The test: can the user understand what they're agreeing to and make a meaningful choice? If your consent interface requires a law degree to parse, you've failed the "informed" requirement.
What's the Path Forward?
It's not unsolvable, but it requires you to treat consent as a product feature, not a compliance checkbox.
Start with purpose minimization. Every consent request you don't have to make is a problem you don't have to solve. If you're asking for consent to process data you don't actually need, stop collecting that data.
Next: build consent as a capability, not a form. That means infrastructure that tracks consent state per user per purpose, honors withdrawal in near-real-time, and triggers re-consent when your processing changes. If you're still managing consent in a spreadsheet or a static database table, you're not equipped for this.
Then: design for the user, not the legal team. Your consent interface should take fifteen seconds to understand and five seconds to complete. If it takes longer, you're asking for too much at once or explaining it poorly.
Finally: test your consent mechanism against Article 7 requirements as written, not as you wish they were. Is consent freely given? Can users refuse without penalty? Is withdrawal as easy as acceptance? If you can't answer yes to all three, you're carrying compliance risk.
Where to Go for More
The European Data Protection Board's Guidelines 05/2020 on consent remain the authoritative interpretation of Article 7 requirements. Read them. They're clearer than most vendor whitepapers.
If you're rebuilding consent infrastructure, look at the IAB Transparency and Consent Framework not as a solution to adopt wholesale, but as a reference architecture. It shows what granular, user-controlled consent looks like at scale.
And if you're still trying to figure out whether consent is the right lawful basis for a specific processing activity: it probably isn't. Consent is the right choice when the user genuinely benefits from opting in and suffers no penalty from opting out. Everywhere else, you're better off with a different Article 6 basis and a better transparency story.
