Your AdTech product is almost ready to launch in a new market. Then the privacy review comes back: “We need to respect users’ choices.”
Engineering needs specifics. How are user choices communicated? Which requests should change? What data should be removed? What happens when a privacy signal is missing? Meanwhile, the product needs to know whether the launch can go ahead.
Everyone is working toward the same goal, but the requirement still leaves each team with a different question.
This is the challenge Liz Tokareva, CEO and co-founder of BidSafe One, and Olena Rozenvasser, Chief Privacy Officer and co-founder, explored in their DMEXCO 2026 session, “It Takes Two to Tango: Speak AdTech and Privacy Fluently.”
So how do teams move forward? Start with what the product actually does: what data it collects, how it uses that data, and who receives it. That gives privacy, product, and engineering a shared basis for deciding which requirements apply, what the system should do, and how to test it.
Why the Handoff Breaks Down
Legal and engineering often describe the same product at different levels. Privacy specialists discuss purposes, legal bases, and recipients. Engineers describe specifications, frameworks, services, and data flows. Product teams think in features, dependencies, and release dates.
“Legal can't explain it to tech. Tech can't implement what legal is asking. And leadership is stuck in the middle wondering why nothing is moving.”
— Liz Tokareva, DMEXCO 2026
We understand that each perspective answers a different question. However, trouble starts when a handoff leaves those questions disconnected.
Consider a requirement to stop using certain data for a particular purpose after a user changes their choice. Before engineering can implement it, someone needs to identify the affected processing, the decision point, the downstream recipients, and the behavior expected on subsequent requests.
A statement such as “support consent withdrawal” leaves all of that unresolved. An API diagram alone leaves the legal meaning unresolved, too.
The fix is to make the interpretation a joint task. Privacy explains the applicable obligation. Engineering describes what the system actually does. Product turns the agreed change into a scoped piece of work with an owner and acceptance criteria.
Scope the Requirement Around the Product
Before adding another framework to the roadmap, describe the processing you need to assess.
“The starting point is your data map — who you are in the ecosystem, what data you process, where your users are located, and what role you play.”
— Olena Rozenvasser, DMEXCO 2026
To put this into practice, choose one feature or integration. Identify the personal data involved, its source, the purpose of each use, the recipients, and the markets concerned. Include enrichment, storage, and reuse where they occur. A diagram that ends at “send to partner” still leaves an important part of the assessment open.
Then establish your role for that processing. Under the GDPR, a controller determines the purposes and means of processing; a processor acts on the controller’s behalf. That distinction depends on the actual activity. It should be assessed for the relevant operation, rather than assumed from a company-wide label.
Keep three kinds of requirements distinct:
Legal obligations: what applicable law requires for the processing.
Framework rules: the policies and specifications relevant to your participation in an industry framework.
Partner requirements: the conditions an integration or commercial relationship imposes.
They can overlap, but the source matters. It helps teams explain why a change is needed and what would trigger a reassessment.
A smaller company can keep this process lean. Its size alone does not establish which obligations apply; the assessment still needs to reflect its activities and applicable law.
TCF, GPP, and CMPs Affect Product Behavior
These terms describe different parts of the privacy workflow.
IAB Europe’s Transparency and Consent Framework, or TCF, combines policies and technical specifications for communicating disclosures and users’ choices. A consent management platform, or CMP, manages those choices and communicates their status. IAB Tech Lab’s GPP provides a protocol for transmitting privacy and consumer-choice signals across supported contexts.
None of those definitions tells your product team everything it needs to build. Your implementation still has to determine where a signal enters, which component reads it, and which processing decisions depend on it. Framework participation also does not replace your own legal assessment.
Liz connects these implementation decisions to business outcomes:
“How you implement a consent management platform directly affects your fill rates, your bidstream, and your partnership eligibility.”
— Liz Tokareva, DMEXCO 2026
Product reviews need to follow the signal through the relevant processing. Ask what happens before it becomes available, when it changes, and when it cannot be interpreted. Define those cases against the applicable requirements instead of silently treating uncertainty as permission.
These decisions can affect request routing, partner integrations, targeting, and measurement. Their commercial consequences depend on your setup. Receiving a signal is one step; applying the resulting restrictions is another.
Turn the Interpretation Into a Development Task
Bring privacy into feature discovery while the team can still change the design. For each affected workflow, document the decision in a form engineering can implement and QA can verify.
Imagine a new audience-enrichment integration. A useful specification would identify the incoming data, the intended purpose, the recipient, the applicable conditions, and the point at which the platform decides whether that enrichment can run.
It should also explain the outcome when the conditions are not met.
Does the integration stop?
Can a reduced data payload serve a permitted purpose?
What happens to retries and cached decisions?
The answer requires review of the specific use case.
An illustrative acceptance criterion might read:
“When the applicable privacy decision prohibits enrichment for this purpose, the enrichment service must not receive the identifier used for that operation. Verify the outbound request and subsequent retry behavior.”
This is an example of how to write a testable requirement, rather than a universal rule for every platform.
Give the task a named owner. Record the interpretation, the affected components, and the evidence needed for approval. Revisit that decision when a new partner, purpose, market, or framework change alters the assumptions behind it.
Not sure how to turn a privacy requirement into an engineering task? Explore how BSO can help with technical specifications.
Start Your Review With One Complete Workflow
You can begin with a working session between the tech lead, product owner, and privacy owner. Pick a workflow that matters to the business, such as an outgoing bid request or a new data integration.
Walk through it together:
Identify the data and purpose. What information enters, what is added, and why is each use needed?
Establish the applicable conditions. Which legal basis, user choice, framework rule, or partner requirement affects the operation?
Locate the control. Where does the system apply the decision, and which components depend on it?
Inspect the output. What actually leaves the platform, and does it match the agreed behavior?
Assign the follow-up. Record the gap, owner, next action, and evidence needed to close it.
Tests changed choices and missing or invalid signals alongside the expected path. Capture enough evidence to explain the result without unnecessarily reproducing personal data in tickets or logs.
This first review helps scope the work. More complex findings may need a deeper assessment, but the team should leave knowing which decision is unresolved and who will take it forward.
At BidSafe One, we help AdTech teams put privacy requirements into practice through privacy audits, legally required privacy documentation, and technical specifications.
Have a privacy requirement your team isn’t sure how to implement? Tell us what you’re working on, and we can help define the next steps for your product and engineering teams.
You can also watch Liz and Olena’s DMEXCO session.
