Teams should treat data protection as a design requirement, not a later review step. Build proposals around transparency, user choice, purpose limitation, and accountability from the start, then test whether the model reduces tracking rather than reproducing it. If the design still depends on intrusive profiling or hidden data sharing, it does not satisfy the expectation for meaningful control.
Design the proposal as a privacy posture, not a media plan
Adtech proposals meet data protection expectations when they are designed around lawful, explainable processing rather than around maximum data extraction. That means defining the data flows, the roles of each party, the intended purpose, the retention period, and the user-facing choice model before the product decision is locked. If those elements are missing at proposal stage, the later compliance review is already too late.
For adtech, the practical test is whether the proposal can still work with less tracking, less cross-site correlation, and less data sharing. A design that only functions by defaulting to broad profiling or opaque onward transfer usually signals that the proposal is optimising for monetisation first and data protection second.
That is why a privacy-first proposal should describe what data is collected, why it is needed, who receives it, and what users can actually control. The more the model depends on inferred audiences, hidden partnerships, or persistent identifiers, the harder it becomes to show that the proposal was built with meaningful control from the outset.
Where proposals usually fail the data protection test
The most common failure is not a missing policy document, but an architecture that bakes in collection and sharing by default. When teams postpone decisions about consent, retention, or disclosure until after the adtech stack is chosen, they often inherit a design that cannot easily support limitation of purpose or minimisation of exposure.
Another weak point is uncertainty about accountability across the supply chain. A proposal may appear simple on paper, yet still route data through multiple processors, bidders, measurement partners, or data brokers. Without a clear statement of controller and processor responsibilities, it is difficult to explain who is accountable when data is reused beyond the original context.
Transparency is also often treated as a notice problem rather than a design problem. A disclosure that is technically accurate but too complex for users to understand does not create meaningful control, especially if the processing model relies on layered sharing or real-time profiling that users cannot reasonably anticipate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | PR.AC-1 — Account Management | Adtech proposals need defined access and accountability for who can process and share user data. |
| PR.DS-1 — Data Management | The question centers on designing collection, purpose and sharing around data protection expectations. | |
| GV.RM-1 — Risk Management | The proposal must assess privacy and compliance risk before the design is committed. | |
| Recommendation — Define account and access responsibilities for every party handling adtech data. Minimise collected data and restrict it to the stated purpose. Assess privacy risk during proposal design, before approval and implementation. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Proposals should embed privacy risk treatment into the design decision, not after launch. |
| PR.DS-01 — Data-at-Rest is Protected | Adtech designs should constrain storage and retention of user data from the outset. | |
| PR.PT-01 — Protective Technology is Managed | The proposal must ensure tracking and sharing mechanisms are intentionally bounded and governed. | |
| Recommendation — Embed privacy risk decisions into the proposal governance process. Limit retention and protect stored adtech data by design. Bound tracking and data-sharing mechanisms to the approved design. | ||
| NIST SP 800-63 | Digital Identity Guidelines | User choice and transparency depend on trustworthy identity and authentication flows in consent experiences. |
| Recommendation — Design user-facing consent and account flows so choices are attributable and understandable. | ||
| EU AI Act | Article 5 — Prohibited AI Practices | If adtech proposals use manipulative profiling, the prohibition boundary helps frame acceptable design. |
| Recommendation — Avoid proposal features that rely on deceptive or manipulative user profiling. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets Sprawl | Adtech stacks often fail when data sharing and tracking depend on uncontrolled tokens and keys. |
| NHI-05 — Overprivileged Non-Human Identities | Proposal governance must limit machine access that can expand sharing beyond the intended purpose. | |
| Recommendation — Control secrets and data-sharing credentials that enable third-party adtech integrations. Restrict machine and service access to the minimum needed for the approved data flow. | ||
Practitioner Guidance
What to prioritise: Lock the data map, purpose statement, and decision on user control before commercial optimisation is finalised. If those elements are still changing, the proposal is not yet mature enough for a data protection sign-off.
What to verify: Confirm that the proposal can be explained in one clear path from collection to use to sharing, with no hidden dependency on persistent tracking to preserve core functionality. If the value proposition collapses when tracking is reduced, the design needs rework rather than a disclaimer.
Common mistake: Treating consent text or privacy notices as a retrofit for a data-hungry architecture. Notices can support transparency, but they do not fix a design that is built around intrusive profiling or unnecessary onward disclosure.
Practitioner takeaway: The strongest proposals are the ones that remain credible when you strip away excess data collection, because that is usually the clearest indicator that privacy was built in rather than negotiated later.
Related resources from NHI Mgmt Group
- How should organisations implement data discovery and classification to meet New York SHIELD Act requirements across SaaS, cloud, and endpoint environments?
- How should organisations evaluate cryptography events when they are deciding whether to strengthen data protection controls?
- How should organisations secure APIs to meet PCI DSS 4.0 requirements without leaving gaps in cardholder data protection?
- How should organisations implement data protection when they rely on digital certificates for online communication?
