Depth in a consent system isn't the same thing as over-compliance — shallow consent handling is under-compliance wearing a simpler-looking interface.
February 2026 · 5 min read
Depth is not over-compliance. Shallow compliance is under-compliance. Consent was never meant to be a banner, or a static legal artefact you show once and forget — it's a system, and systems break when they're designed to look right rather than to work.
There's a pattern worth noticing here. Nobody today calls encrypting every PII field "over-engineering." Nobody calls authenticating every API call excessive. Those became table stakes, and consent is moving down the same path.
Going forward, every instance of personal data processing is going to be expected to carry a consent context alongside it — not a screenshot, not a stored PDF, but a machine-readable signal that other systems can actually read and act on. That requires a shift a lot of teams are still resisting: consent can't live only at the edge, in the banner, at the moment of collection. It has to become a centralised control layer that every processing system checks against. That's not regulatory caution for its own sake — it's ordinary systems hygiene finally catching up with what the law already expects.
This is the part that makes teams uncomfortable, because it sounds technical and therefore feels like scope creep. It isn't.
Consent configuration usually fails in practice not because the notice text was wrong, but because the organisation has no reliable picture of where consent-dependent logic actually lives in the codebase. The usual suspects: purposes hard-coded somewhere nobody remembers, API calls nobody mapped to a purpose, conditional collection paths that only trigger under specific conditions, and feature flags that silently change what data gets collected without legal ever finding out.
Relying on documentation or institutional memory works fine — until the first refactor, and then it quietly stops matching reality. Code-level discovery and mapping is the only reliable way to make sure your consent configuration reflects what the system actually does, not what everyone assumes it does. Done well, it also reduces the ongoing effort of keeping configuration current. This isn't about optics. It's about closing the gap between what the system does and what the organisation believes it does — because that gap is exactly where violations live.
Now the part most teams put off. Legacy data doesn't get retroactively cleaned up just because a new law arrives — at some point, every organisation has to answer honestly: why do we still have this data?
Discovery paired with lineage gives visibility. Reverse mapping gives control. Whatever the source — schemas, table names, service names, metadata — you need a working way to trace existing data back to the purpose it was originally collected for. Without that, you can't decide whether legacy data can be retained, trigger a refresh-consent flow correctly, or defend the decision if it's ever challenged. Legacy consent handling without discovery isn't a decision — it's a confident-sounding guess.
Refresh consent exists for real reasons: recurring uses that were never covered by the original consent, consent that's simply aged past a reasonable point, and purposes that evolved — in scope, in downstream use, in the categories of data involved, or in processing context. Handling it correctly needs both code-level understanding of what's actually happening and data-level context about what was originally agreed to.
Without both, refresh workflows swing between two equally bad outcomes: refreshing so often that users learn to click through without reading, or refreshing so rarely that real expiry and material changes get missed entirely. Refresh needs to be triggered by actual impact, not by a calendar date.
Data isn't always collected directly from the person it's about. Employee referrals, emergency contacts, business-correspondent-driven collection — in every one of these, notice still has to reach the actual Data Principal, even though someone else entered the data. A consent system has to support these assisted workflows natively, triggering notice even when the data arrives through an intermediary. This isn't an edge case tucked away in a corner of the spec. It's a routine part of how enterprises actually collect data, and skipping it creates non-compliance that stays invisible until someone asks the right question.
These sound complicated. They aren't, structurally — parental consent, consent flows for people with disabilities, and nomination workflows all follow the same underlying consent logic, with a handful of specific variations layered on top. What matters is that a platform supports these natively, rather than forcing teams into parallel systems or manual workarounds. Handled properly, they reinforce consistency across the whole consent system instead of fragmenting it into special cases.
None of this contradicts the case against over-compliance — it completes it. Over-compliance is real. So is under-compliance dressed up as simplicity. Depth in the core consent system isn't excessive; it's how you avoid both failure modes at once.
Consent is becoming infrastructure. Platforms that treat it as a UI problem will keep generating friction for themselves and their users. Platforms that treat it as a system primitive will quietly get it right. Good compliance is still boring — but it's also deliberate, defensible, and proportionate. That's the actual bar.
Treating consent as infrastructure rather than a banner is exactly the premise behind our technology practice — source-owned, built for the long run rather than rented one renewal at a time.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation