Consent fatigue is a compliance risk, not just a UX problem

Most teams treat the consent banner as a design problem: how do we make it disappear as fast as possible without annoying the user? Under DPDPA, that framing misses the actual risk. A rejected or ignored consent request isn't just a lost signup — it's a Data Principal whose choice you're now obligated to honor, record, and be able to prove later.

The banner is the easy part

Getting a yes or no on a cookie banner is trivial. The hard part is what happens after: storing that decision against a specific version of your notice, making it retrievable if a Data Protection Board asks for it, and honoring a withdrawal the moment it's requested — not at the next deploy.

If you can't show which notice a user consented to, and when, you don't have consent — you have a UI interaction.

What actually reduces fatigue

• Granular purposes shown up front, not buried behind a 'Manage preferences' click
• A withdrawal path that's exactly as easy as the original consent flow
• Remembering a user's choice across sessions so they're never asked twice for the same purpose
• Versioning notices so a policy update doesn't silently invalidate old consent records

None of this requires a heavier banner. It requires a consent record behind the banner that's structured correctly from day one — which is the part most teams bolt on after the fact, once an audit forces the question.