How Ofcom and the ICO want platforms to build effective, data-minimizing age assurance Written on 05 Aug 2026

How Ofcom and the ICO want platforms to build effective, data-minimizing age assurance

The false choice between child safety and privacy is becoming a compliance risk of its own. Ofcom and the ICO now expect services to show that age assurance is both effective and no more intrusive than necessary. The strongest UK architecture treats those goals as one design problem. Purpose-specific evidence, limited retention, and risk-based escalation deliver better safety and privacy together.

In a nutshell

The March 2026 Ofcom and ICO joint statement helps services reconcile Online Safety Act duties with UK data protection law.
Highly effective does not mean maximally identifying. Services should choose the least intrusive method that addresses the assessed risk.
A DPIA, clear controller and processor roles, purpose limitation, retention controls, user transparency, and challenge routes are operational requirements, not legal appendices.
The safest architecture usually returns a narrow age fact and escalates only uncertain or higher-risk cases.

The industry keeps framing the wrong trade-off

Age assurance is often framed as a contest between protecting children and protecting privacy. In that story, a service either collects strong identity evidence and keeps children out, or it preserves anonymity and accepts weak protection. The framing is convenient because it excuses poor architecture on both sides.

Ofcom and the Information Commissioner's Office reject that binary. Their March 2026 joint statement sets out how services under the Online Safety Act and the UK data protection regime should comply with both. A method that is too weak can fail online-safety duties. A method that collects more personal data than necessary can fail data protection duties. The goal is not to maximize one value and apologize for the other. It is to select proportionate evidence and minimize the data needed to make a reliable decision.

What should a risk assessment start with?

Start with the harm, not the data you already hold. A risk assessment should identify the content, feature, or behavior being controlled, the ages affected, the likelihood and severity of harm, and the consequence of a wrong decision. That assessment sets the confidence you need. An adult-content service, a social platform tailoring direct messaging, and a retailer pre-screening an alcohol delivery do not all need the same evidence.

Starting from the data a company already holds reverses the process. A platform may be tempted to infer age from browsing, contacts, purchases, or language because those signals exist. But availability does not establish necessity, fairness, or transparency. A purpose-specific estimate or trusted attribute can reach the same outcome with far less profiling.

What does highly effective age assurance mean?

Ofcom's framework emphasizes accuracy, robustness, reliability, and fairness. Those criteria apply to the whole age-assurance process, not just to a machine-learning model. A technically accurate estimator can still fail through poor image capture, unlimited retries, account sharing, missing liveness, or a threshold tuned for adult conversion rather than child protection.

The service stays responsible even when it uses a third party. It should understand the method's evidence, configure it for the use case, monitor outcomes, and keep a route for challenge. Outsourcing the computation does not outsource the statutory decision.

Data minimization begins with the output

Many services do not need a date of birth, an identity document, or an exact age. They need a statement such as "meets 18+ threshold" or "requires child-safe experience." The narrower the output, the smaller the downstream data surface. A threshold token can be designed so the relying service never receives identity or an exact birth date.

Facial age estimation can minimize disclosure further because it can operate without learning identity. It still processes a face image, so the data flow has to be clear. The service should know whether the image reaches its own systems, a vendor, or both, whether a template is created, whether logs hold images or identifiers, and whether the result is kept longer than the access decision requires.

What should a DPIA actually describe?

A Data Protection Impact Assessment cannot stay a generic description of "biometric processing." It should map the journey users actually take: capture, transmission, image validation, age estimation or verification, liveness, fallback, logging, support access, deletion, model monitoring, and appeals. It should flag special-category biometric processing where it applies and separate biometric identification from other forms of face analysis.

The DPIA should also address alternatives. If a user cannot or will not provide a face, what happens? Is a document the only fallback? Can a trusted digital identity or age attribute be used instead? Does a human reviewer see the original image? A method is not truly optional when every other route is unusable.

Who is responsible when you use an age-assurance vendor?

Contracts should define who determines purposes and means, who processes data on instructions, which sub-processors are involved, where data is stored, and how security incidents are reported. But responsibility has to match the architecture. A vendor may decide model-development purposes independently of the customer's access decision. A platform may decide to keep results for fraud analytics long after the vendor has processed the check and discarded the data.

Due diligence should therefore examine both parties' purposes rather than assume one simple controller and processor relationship covers every activity. The service should also keep audit rights, model-change notification, deletion evidence, and the metrics needed to assess fairness and effectiveness.

Transparency has to work for children and adults

Users should understand why the check exists, what method is used, what data is processed, whether a third party is involved, what result is returned, how long information is kept, and how to challenge a decision. That explanation should not be buried in a privacy policy or written as though every user is a lawyer.

Child-friendly communication is not a lighter coat of paint on the adult notice. It should explain what the service is trying to protect, avoid implying that a facial estimate knows the user's identity, and say what happens after a failed or uncertain result. Adults who are wrongly classified need an equally clear path to recovery.

Treat retention as a design decision

Operational teams often keep request and response data because logs are useful. Age assurance makes that habit risky. Images, confidence values, device identifiers, and challenge outcomes can reveal sensitive information or harden into a persistent age profile.

Keep only what you need to operate, secure, audit, and improve the service, with different periods for different data categories. An anonymous aggregate metric can be kept longer than a face image. A dispute record may need a defined evidence window. Raw capture should not survive indefinitely just because someone might want to analyze it later.

Design a privacy-preserving waterfall

The best synthesis of safety and minimization is a waterfall. Clear low-risk cases receive a narrow age result. Poor-quality images trigger recapture rather than storage. Uncertain cases can present a reusable wallet proof or another independent method. High-risk cases escalate to identity verification. Liveness is applied where the attack model calls for it.

No single data-intensive method is forced on every user. Proportionality becomes a routing rule rather than a line in a policy.

Conclusion

Ofcom and the ICO are converging on a mature idea. An age-assurance system is effective only when it protects children, resists realistic attacks, treats adults fairly, and limits personal data. Privacy is not what remains after safety has been designed. It is one of the conditions that make the system legitimate and sustainable.

UK services should stop asking whether they can justify collecting more evidence. They should ask what minimum evidence supports the required decision, what happens when that evidence is uncertain, and how they will prove the system works without turning age assurance into a permanent identity dossier.

Where Youverse stands

Youverse builds age assurance for a world where safety and data minimization have to hold at the same time. YouAge returns a purpose-specific age estimate in under a second without storing biometric data, so most users clear a check without ever handing over identity. YouLive adds ISO/IEC 30107-3 certified liveness and attack detection, so a check resists photos, masks, and injected video rather than only performing in a lab. YouID and YouAuth handle higher-assurance and re-verification cases at the end of the waterfall, so escalation is reserved for genuine uncertainty or risk. The result is one architecture that routes each user to the least intrusive method that fits the decision.

Frequently asked questions

Does the Online Safety Act override data protection law?

No. In-scope services must comply with both regimes. The joint Ofcom and ICO statement is designed to help organizations build age assurance that satisfies both sets of duties at once.

Is facial age estimation biometric identification?

Not necessarily. Estimating apparent age does not inherently identify a person, but it still processes facial data and may involve special-category biometric processing, depending on purpose and implementation. Legal analysis should follow the actual data flow.

How long should age-assurance data be retained?

There is no universal period. Retention should be purpose-specific, documented, and limited. Raw images, result logs, and aggregated metrics can each call for very different treatment.

What is the least intrusive method?

It depends on the decision. The rule is to choose the least intrusive method that still addresses the assessed risk, rather than the strongest evidence available. Facial age estimation may be proportionate for a low-risk check, while a higher-risk decision may justify a trusted identity attribute or full verification.