A consent management platform vendor demonstrates the tool, and it is genuinely good. The cookie banner goes live, legal reviews the wording and signs it off, and the project closes. Six months later an external audit follows the data rather than the banner and finds personal data still flowing to several ad platforms with no enforceable lawful basis behind it. Nobody falsified anything, the banner works. The consent records exist. And yet the company is processing personal data it has no defensible right to process. Nobody did anything wrong. Nobody did anything right either.
The reason is structural, and it is the same reason that recurs across this series. The thing that was bought solved the visible part of the problem. The cookie banner is the part of consent a marketing leader can see, approve, and point to in a board paper. The part that determines whether the company is actually compliant sits behind the banner, in the data flows that were already running before the banner arrived and kept running after it shipped.
Consent is not a policy artefact, it is a runtime data flow problem. A consent platform placed in front of a website governs what a new visitor’s browser is told to do. It does not, on its own, change what the systems behind the website do with the data they already hold and the data they continue to collect. Treating consent as a legal sign-off rather than an engineering control is how a company ends up with a perfect banner and an indefensible data estate. The fix is not a stricter banner, it is engineering.
The audit finding nobody saw coming
The audit did not find a broken banner, it found a banner that worked exactly as designed and a set of data flows that never heard about it.
When the consent platform went in, it was wired to the client-side tag manager. A visitor who declined advertising cookies would not have the advertising tags fire in their browser. That part was tested and it passed. What nobody traced was everything that did not run in the browser. The server-side tagging container, configured eighteen months earlier, kept sending events to the ad platforms directly. The Conversions API integration, set up by the performance team to recover signal lost to browser restrictions, kept posting hashed emails. The nightly reverse-ETL job that pushed audience segments from the warehouse to the ad platforms kept running on schedule, joining on an identity the consent platform had never tagged.
So a visitor could decline advertising in the banner, see no advertising tags fire, and still have their email hashed and uploaded to three ad platforms that night, because the systems doing the uploading read from the warehouse and the warehouse did not carry their consent state. The banner suppressed the visible flow and left every server-side flow untouched.
This is the failure that surprises marketing leaders, because every individual component was doing its job. The banner recorded the choice. The consent platform stored it. The ad integrations moved data efficiently. The only thing missing was a connection between the recorded choice and the systems that acted on the data, and that connection is not something a consent platform installs for you. It is something an engineering team builds.
What consent actually is
Part of the confusion comes from treating consent as a single yes or no on a banner. In a defensible data estate it is neither single nor static.
Consent is a per-person, per-purpose, time-stamped, revocable state. A given individual has consented to analytics but not advertising, as of a specific moment, until they change their mind. That state has to be attached to that person and enforced against every use of their data, for as long as the data is held. A boolean captured once at the banner cannot express this, because real consent is granular and it moves.
It also helps to separate three things that get collapsed into the word “consent”. There is the consent event, which is what the banner captures. There is lawful basis, which is the legal ground for processing under GDPR. And there is enforcement, which is the runtime gating that stops a flow when the basis is absent. Consent is one of six lawful bases for processing personal data, set out at Article 6, under which processing is lawful only where at least one basis applies (European Parliament and Council, 2016, Article 6). The banner produces an event. Whether that event creates a valid basis, and whether the basis is honoured downstream, are separate questions the banner does not answer.
There is also a layer most marketing teams miss. The cookie banner itself largely exists to satisfy ePrivacy rules on storing and reading information on a visitor’s device, a regime distinct from the GDPR basis required to then process the personal data that results. A company can be compliant on the first and exposed on the second. The banner is necessary. It was never sufficient.
Where consent state has to live
If consent is a per-person, per-purpose, revocable state, then the engineering question is where that state lives and what can read it. In the failed audit, it lived in the consent platform’s own store and was read by the client-side tag manager and nothing else. That is the root cause. Consent state that only the banner can see can only govern what the banner controls.
The state has to live where the data lives and travel with it. In practice that means the consent decision is captured at the moment it is given, written to a store that the warehouse, the customer data platform, and the activation pipelines can all query, and keyed to a durable identity rather than a cookie the user can clear on their next visit. When a reverse-ETL job assembles an audience for an ad platform, the consent state for advertising is a column it joins on, not a separate system it forgets to call. When a server-side container posts an event, it checks the same state the banner wrote. Enforcement happens at the point of processing, not at the point of display.
This is the same argument the series has already made about identity and about metric definitions. The control has to sit in the data layer, queryable and joinable, or it does not hold. Readers who want the harder, more technical treatment of how regulatory obligations become enforceable engineering controls will find it in Sakura’s Regulatory Stack series, which runs the same logic for compliance architecture in general.
The test is simple to state. If “every record we are about to send to this ad platform has a current, valid consent for advertising” is one query, consent lives in the right place. If answering it requires exporting from the consent platform, reconciling against the warehouse by hand, and hoping the identities line up, it does not.
How it breaks (four failure modes)
Across the engagements where this goes wrong, the same four failure modes recur. They are independent, so a company can have solved one or two and still be exposed.
- The banner governs the browser, not the back end. Client-side tags respect the consent choice while server-side containers, Conversions API feeds, and warehouse exports keep running, because they were configured before the banner and never wired to read it. This is the most common single cause and the one in the opening anecdote.
- Consent is captured but never propagated. The platform records the choice accurately in its own store, and that store is never read by the systems that process the data. Suppression cannot be enforced at activation, because the activation pipeline has no access to the state that says who to suppress.
- Consent has no purpose granularity. A single “accept” is stored as one flag, so a person who agreed to analytics but not advertising cannot be honoured, because the captured state cannot express the distinction. The system either over-suppresses and loses analytics it was entitled to, or under-suppresses and advertises to people who declined.
- Consent is keyed to a device, not a person. The state is attached to a cookie or browser identifier while activation runs on a hashed email or CRM ID. When the user clears cookies, switches device, or is resolved to a known customer record, the consent state and the person can no longer be rejoined, and the safe default of dropping the record is rarely the one the pipeline takes.
Engineering it properly
Engineering consent properly is less exotic than it sounds. It is the same discipline applied to identity and definitions, pointed at lawful basis.
Consent is captured with the purpose granularity the law actually requires: separate states for analytics, advertising, personalisation, and any other distinct purpose, each time-stamped at the moment it is given and stamped again when it changes. The state is written to a store the whole estate can read, keyed to the most durable identity available and re-keyed as anonymous visitors resolve to known customers. Every system that processes personal data, including client-side tags, server-side containers, the CDP, and the reverse-ETL feeds to ad platforms, checks that state at the point of processing rather than trusting that something upstream already did. Revocation propagates as a cascade, not a quarterly cleanup.
When this is in place, the questions that used to take the privacy team three days become single queries. Which records in this audience have valid advertising consent. Which flows are still sending data for a purpose the subject withdrew. What is the lawful basis for the largest activation segment, by record, today. An audit stops being an archaeology project and becomes a query someone runs in the meeting.
None of this requires abandoning the consent platform. The platform is a good capture mechanism and a reasonable consent record. The work is connecting it to the systems that actually process the data, so that the choice a visitor makes in the banner is the choice every downstream system enforces. That connection is engineering, owned and tested like any other production control, and it is the difference between a company that can defend its data estate to a regulator and one that discovers, six months after the banner shipped, that it cannot.
Building that connection sits across the boundary between privacy obligation and data engineering, which is where Sakura’s Governance, Risk & Compliance service and the Praxis solution for engineered compliance are built to operate. The deliverable is not a better banner, it is consent that still holds when someone follows the data.
Disclosure: Praxis is a Sakura Sky offering and the Governance, Risk & Compliance service referenced is a Sakura Sky service line.
Not legal advice. This article offers general commentary on the EU General Data Protection Regulation for a marketing and engineering audience. It is not legal advice and is not a substitute for advice from qualified counsel. Specific obligations depend on the nature of your data flows, the data you process, your jurisdiction, and your supervisory authority. Readers must obtain independent legal advice on how these regulations apply to their specific products and commercial operations.
References
European Parliament and Council, 2016. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). Official Journal of the European Union, L 119, 4 May, pp. 1-88. Available at: https://eur-lex.europa.eu/eli/reg/2016/679/oj [Accessed 29 June 2026].