When should organisations prioritise privacy-by-design over expanding targeting capabilities in adtech?

Privacy-by-design should take priority whenever a proposal depends on collecting, sharing, or inferring personal data at scale. The ICO’s position is that commercial convenience cannot outweigh lawful and fair processing. If the business model requires maintaining existing tracking practices, organisations should redesign the approach before launch rather than trying to justify it after deployment.

Why privacy-by-design should outrank targeting expansion

Privacy-by-design is the right default when a proposed adtech change only works by increasing the volume, granularity, or shareability of personal data. The core question is not whether the targeting is technically possible, but whether the collection path, inference model, and downstream sharing remain proportionate to the purpose and lawful under the processing rules that govern the product.

That is why this decision should be made before launch, not after a feature is already embedded in campaigns, partner contracts, and measurement pipelines. Once a targeting model depends on broad profiling, the cost of changing direction rises sharply, while the compliance and trust risk created by overcollection tends to persist across bidders, intermediaries, and analytics vendors.

For the privacy baseline, the most relevant reference point is the EU General Data Protection Regulation (GDPR), especially the principles on fairness, purpose limitation, data minimisation, and data protection by design and by default. When a targeting proposal cannot be justified without expanding personal data use, the safer interpretation is to redesign the system so it needs less data, not to hope later documentation will make the design acceptable.

What privacy-by-design changes in adtech architecture

Privacy-by-design is not just a policy stance, it changes the product shape. In practice, it pushes teams toward minimisation, shorter retention windows, narrower audience definitions, clearer purpose boundaries, and stronger controls over disclosure to partners and ad exchanges. It also forces a hard look at whether a proposed signal is genuinely necessary or merely useful for optimisation.

In adtech, the usual failure mode is treating more data as a low-cost substitute for better design. That can mean collecting identifiers that are not needed for the use case, combining datasets in ways users would not reasonably expect, or inferring sensitive traits from behavioural patterns. A privacy-by-design approach asks whether the same commercial outcome can be achieved with contextual targeting, aggregation, on-device processing, coarse segments, or other lower-exposure methods.

The NIST Privacy Framework is useful here because it frames the issue as privacy risk management, not just legal review. The practical test is whether the proposed targeting capability increases the organisation’s privacy exposure faster than it improves a business outcome that can be obtained another way.

Risk and Threat Considerations

Expanding targeting capabilities increases the blast radius of any privacy failure because it creates more personal data, more inferences, and more sharing points across the adtech chain. The risk is not limited to regulatory non-compliance, it also includes reputational harm, loss of user trust, and downstream misuse when profiles, segments, or identifiers are reused outside the original purpose.

Failure mechanism: Teams overfit product design to commercial targeting goals, then distribute personal data through multiple intermediaries before they have proven the collection is necessary, proportionate, and defensible under the processing rules.

Impact: The organisation inherits a larger privacy attack surface, higher compliance exposure, and a much harder remediation path if the feature later proves excessive, sensitive, or incompatible with lawful processing expectations.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while GDPR define the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	Art. 5 — Processing Principles	Adtech targeting must obey minimisation, fairness and purpose limitation.
	Art. 25 — Data Protection by Design and by Default	Directly governs choosing privacy-preserving designs over expansion of tracking.
Recommendation — Minimise data collection and processing to what the ad purpose strictly requires. Build privacy into the adtech design before launch and default to the least invasive setting.
NIST AI RMF	GOVERN — Govern	Requires organisational governance for privacy risk decisions in data-driven systems.
	MAP — Map	Helps identify privacy risks from data flows, profiling and third-party sharing.
	MEASURE — Measure	Supports evaluating privacy impact and residual risk from broader data use.
Recommendation — Set governance criteria that force privacy risk review before expanding targeting scope. Map data flows and inference paths before approving new targeting capabilities. Measure the privacy impact of added collection, inference and sharing before release.
NIST CSF 2.0	GV.1 — Organizational Context	Privacy-by-design decisions should reflect business purpose, risk appetite and obligations.
	ID.IM — Improvements	Requires lessons from privacy incidents or near-misses to improve product design.
Recommendation — Align targeting decisions with the organisation’s stated risk appetite and compliance obligations. Feed privacy findings back into product design rather than repeating the same data-heavy pattern.
CIS Controls v8	6 — Access Control Management	Expanded targeting often depends on broader data access and sharing across systems.
Recommendation — Restrict who can access audience and profiling data to the minimum necessary set.

Practitioner Guidance

What to prioritise: Start with purpose limitation and necessity testing, not with campaign performance targets. If the feature requires broader profiling to function, treat that as a design warning, not an optimisation trade-off.

What to verify: Check whether the same targeting outcome can be achieved with less granular data, shorter retention, fewer third parties, or more contextual signals. If the answer is no, the organisation should be able to show a documented necessity rationale and a privacy impact assessment that is specific to the feature, not generic to the platform.

Decision rule: If the proposed model depends on collecting or inferring more personal data than the minimum needed for the stated purpose, redesign first and launch later. Do not let revenue pressure move the privacy decision to post-deployment cleanup.

Practitioner takeaway: In adtech, “better targeting” is not a sufficient reason to expand personal data use; the more a proposal relies on broad collection and inference, the more privacy-by-design should control the architecture from the start.