Consent failures rarely start with a bad record. In most cases, the customer’s choice was captured correctly and stored with a timestamp. The problem comes later, when a campaign goes out to someone who has opted out, because the system that built the audience was working from an old copy of the data.
That was the central argument of a recent webinar, Can You Trust Your Consent Data?, moderated by Dave Cohen, Director at Myna Partners, with James Marshall, Head of Product at Syrenis, and Scott Campbell, Solutions Manager at Myna Partners.
Marshall and Campbell agreed that the failure rarely sits in the record itself. It sits somewhere between that record and the systems that use it.
Consent Quality is Usually a Synchronization Problem
Consent management is the practice of capturing what a person has agreed to and making sure every system that uses their data respects that choice. Most organizations have the first half in place. The second half is where things go wrong.
Campbell said people outside the privacy team tend to assume a consent failure is a data quality problem. In his experience, it is almost always a synchronization problem.
The record is correct. A downstream system either never received the latest decision, received it and failed to process it, or processed it after the campaign had already been built.
Campbell offered one question for testing how much an organization can trust its consent data. If a customer changes a preference right now, how many systems need to know, and how quickly does that change take effect in all of them?
Most organizations can answer the first part. The second part is trickier: In many companies, systems only share data with each other once a day, usually overnight, in a scheduled update. A preference changed at 10 am doesn’t reach the email platform until the following morning, and marketing sends campaigns all day.
Capture Is an Event and Consent Is a State
Marshall’s starting point is that consent is captured once but changes continuously.
- A person starts as a prospect in one system.
- They become a customer in another.
- They move into a post-purchase journey in a third.
Their data spreads across all of them, and their consent has to travel the same route.
An organization that treats capture as the finish line ends up with a record that was true on the day it was taken. That record says nothing about whether it is still true now.
What a Central Consent Record Has to Do
Marshall gave a two-part definition of “trusted consent”:
- A record that shows the customer’s current choice across every system where consent is captured
- An audit trail that shows how that record was built
A consent and preference management platform does both jobs.
The first job is working out the customer’s current choice. The platform collects the consent records from every system and finds the most recent one. That sounds simple, but a system does not always pass on a choice at the moment the customer makes it.
A short example shows why this matters:
- A customer opts out of marketing in a company’s app on Monday
- On Tuesday they buy something on the website and tick the box to receive offers
- The customer’s latest choice is to receive marketing
If the app reports its data less often than the website, the Monday opt-out can arrive after the Tuesday opt-in. That’s why a platform needs to order choices by when the customer made them, not by when each system reported them.
The second job is the audit trail. Each system keeps its own history of consent changes, usually in its own format. The platform brings those histories together into one record. Without that, a compliance team has to log into six systems and pull six exports, and none of them shows the whole picture.
Activation Sends the State Back Down
Consolidating the record is half the job. The commercial value, in Marshall’s view, comes from sending the central record back out to the systems that use customer data.
Some of those systems never ask the customer anything. An analytics tool, a call center platform, or a partner feed may have no consent capture of its own, yet each one acts on the customer’s data.
When the central consent state reaches these systems, teams in those channels can see what each customer has agreed to before they act, because the permission arrives with the data.
Marshall’s expectation is simple: Wherever customer data can be delivered, the consent should follow.
The Stakes of the Overnight Batch
The common failure is treating the moment of capture as the end of the consent process. The systems that act on the data learn about a customer’s choice hours or days after it is made, and compliance failures can occur in that gap.
Since January 1, 2026, California’s revised CCPA regulations require a business to display on its website whether it has processed a consumer’s opt-out signal, so the state of each opt-out is now visible to the consumer and to anyone testing the site.
A consent record on its own proves what the customer chose, but it does nothing to stop a campaign going out to the wrong people. When every system is kept in sync with that record, each message a customer receives is one they agreed to, and marketing can send messages in the confidence that nobody on the list has opted out.
The full webinar, including the discussion of real-time enforcement and the business case for consent governance, is available to watch. Download the Webinar here.