UK Online Safety Act ICO Overlap

The overlap begins when a provider processes personal data to assess or reduce an Online Safety Act risk. Common examples are checking age, profiling users for risk, ranking or suppressing recommended content, detecting illegal content or coordinated abuse, reviewing reports and appeals, sharing child-safety information, and measuring whether a control works. The Online Safety Act supplies the safety duty; it does not automatically settle the UK GDPR lawful basis, purpose, or method.

For age assurance, the March 2026 Ofcom-ICO joint statement says all methods process personal data. An in-scope service may use personal data where the method is necessary and proportionate to its risks and complies with data protection law. Where the Online Safety Act requires highly effective age assurance, the service must meet Ofcom's effectiveness criteria as well as UK GDPR requirements. Self-declaration alone is not effective for preventing underage access.

The Children's Code is a statutory data-protection code for information society services likely to be accessed by children. It can apply even where the service is outside the Online Safety Act. If the provider cannot establish age with confidence appropriate to its data-processing risks, ICO guidance says it should apply the Code's standards to all users rather than assume they are adults.

The product or safety owner should define the Online Safety Act risk and required outcome. The controller should assign a privacy owner who can change the processing design, with legal, security, data, accessibility, child-safety, and engineering review. A vendor can operate the tool, but outsourcing does not remove the provider's safety duties or the controller's data-protection accountability.

Keep the Online Safety Act assessment and the data protection impact assessment linked but distinct. The first explains the service risk and proportionate safety measure; the second explains the personal-data processing, lawful basis, necessity, rights risks, safeguards, and residual risk. Record any disagreement and who accepted or escalated it.

An Online Safety Act duty can require highly effective age assurance without prescribing one technology. The provider must choose a method that meets Ofcom's standard and separately complies with data protection law. Conversely, a service outside the Online Safety Act can still need age assurance or child-appropriate design to avoid unlawful processing and meet the Children's Code.

A minimum age in terms does not prove that younger children are absent. The 2026 joint statement says self-declaration is not effective to prevent underage access and gives facial age estimation, digital identity, and one-time photo matching as current examples for enforcing a minimum age of 13; these are examples, not mandatory methods or regulator endorsements.

Safety analytics can be personal data even when names are removed, and a processor's score can still affect a user. Pseudonymisation reduces some risk but does not take data outside UK GDPR where re-identification remains possible. A provider should also separate legal obligations from optional product analytics or reuse for advertising, because those purposes can need different lawful-basis and compatibility analysis.

Start with the service-scope and child-access decisions, then identify the exact safety duty and risk. Describe the personal-data processing needed to meet that outcome, screen for a data protection impact assessment, compare methods, approve the least intrusive effective design, and test it before release. Where unmitigated high data-protection risk remains, consult the ICO before processing.

After launch, monitor both sides of the decision. Safety metrics should show whether users encounter less illegal or harmful content; privacy metrics should show error, exclusion, complaints, rights requests, incidents, retention, vendor performance, and unexpected reuse. Update the connected records rather than treating approval as permanent.