The CDEI and ICO recently completed stakeholder interviews across the Privacy-Enhancing Technologies ecosystem. Their findings clarify why adoption remains slow despite regulatory pressure and what governance teams need to do differently.
What the Research Shows
The CDEI's responsible data access program interviewed stakeholders working with homomorphic encryption, secure multi-party computation, differential privacy, synthetic data, federated learning, and trusted execution environments. Despite the technical diversity, adoption barriers clustered around three consistent themes: cost uncertainty, regulatory ambiguity, and misaligned procurement processes.
This research informed a joint CDEI-ICO initiative to develop a cost-benefit analysis tool for PETs adoption, announced alongside the ICO's new guidance on using PETs to support data protection by design under GDPR requirements.
Key Findings
Organizations solve problems, not deploy technologies. Teams don't wake up wanting to implement differential privacy. They're trying to enable cross-border data collaboration, share internal insights publicly, or access sensitive datasets without violating purpose limitation requirements. The CDEI found that successful adopters started with information flow problems, then identified which PET addressed their specific constraint. Your governance framework should map PETs to data access patterns (internal analysis, external sharing, multi-party computation) rather than cataloging technologies.
Quantitative ROI doesn't capture strategic value. Computing costs for homomorphic encryption are measurable. The value of unlocking a previously inaccessible dataset for fraud detection isn't, at least not until you've built the model and measured lift. Interviews revealed that organizations need both quantitative cost estimates and qualitative narratives about competitive positioning, regulatory risk reduction, and data partnership opportunities. If your business case template only accommodates NPV calculations, you're filtering out the cases where PETs matter most.
Regulatory uncertainty blocks procurement more than technical complexity. Even with the ICO's new guidance, legal teams ask: Does applying differential privacy to training data satisfy data minimization requirements? Can we transfer homomorphically encrypted data outside the EEA without a Data Protection Impact Assessment? These questions don't have yes/no answers, and procurement cycles stall when contracts can't specify compliance outcomes. The CDEI noted this as a primary cost driver, not the technology itself, but the legal review cycles and conservative risk postures it triggers.
Current use cases don't reflect potential scope. The research highlighted a gap between where PETs are deployed today (financial crime, pandemic forecasting in the UK-US PETs Prize Challenges) and where they could address data access barriers across sectors. Your team needs to articulate the narrative: PETs aren't niche tools for cryptographers, they're infrastructure for responsible data collaboration under GDPR's data protection by design requirement (Article 25).
What This Means for Your Team
You're likely facing the same adoption friction the CDEI documented. Your data science team wants to train models on sensitive datasets. Your legal team won't approve transfers. Your procurement team doesn't have a budget for "experimental" privacy tools. And your board asks why you can't just anonymize the data.
The ICO's guidance gives you regulatory air cover for the "why." The forthcoming cost-benefit tool will help with the "how much." But neither solves the organizational challenge: integrating PETs into your AI governance framework requires changing how you scope data access problems.
If you're treating PETs as a compliance checkbox ("we applied differential privacy, so we're GDPR-compliant"), you'll underinvest and get marginal value. If you're treating them as enablers of new data partnerships and model capabilities, the business case shifts.
Action Items by Priority
Map your data access constraints first. Before evaluating specific PETs, document where your teams can't access data they need: cross-border transfers blocked by adequacy decisions, internal datasets too sensitive for broad access, external partnerships stalled by confidentiality concerns. These constraints define your PET requirements more precisely than any technology survey.
Engage with the CDEI's cost-benefit tool during development. The CDEI is seeking input from organizations considering PETs adoption (contact: [email protected]). If you're in scoping mode, participate. The tool will be more useful if it reflects your sector's cost structures and benefit metrics. The updated adoption guide will include a use case repository maintained by the Open Data Institute ([email protected]), contribute your scenarios even if you haven't deployed yet.
Reframe your business case template. Add sections for: data access opportunities currently blocked, regulatory risk reduction (quantify the cost of not being able to use certain datasets), and strategic positioning (competitive advantage from data partnerships). When the CDEI says "qualitative information," they mean your legal team's assessment that PETs reduce Data Protection Impact Assessment scope, or your product team's view that federated learning enables a model you can't build any other way.
Align your legal and technical reviews. The ICO's guidance addresses how PETs support data protection by design, but it doesn't pre-approve specific implementations. Your legal team needs to review PET architectures alongside your technical team, not sequentially. If differential privacy parameters are set after legal review, you'll end up with either excessive privacy guarantees (degraded model performance) or insufficient ones (legal team rejects the approach). Co-design the privacy-utility tradeoff.
Start with internal data access problems. The lowest-risk PET adoption path is enabling your own teams to work with sensitive data they already control. Homomorphic encryption for internal analytics, differential privacy for releasing aggregate statistics, or synthetic data for development environments. These use cases build organizational capability without introducing vendor or cross-border complexity.
