What the Online Safety Act Means for Platform Safeguarding Architecture

What is it and what it means for platform safeguarding architecture

The Online Safety Act (OSA) is now the primary regulatory framework for digital platforms operating in the UK. Ofcom is issuing codes of practice, platforms are conducting risk assessments, and compliance teams are working through implementation.

This is progress. For years, platform accountability for child safety was largely voluntary. Now there's a legal framework with enforcement powers.

But there's a risk in how organisations respond. Compliance with the OSA; ticking boxes, completing assessments, documenting policies, is not the same as building safeguarding systems that actually work under pressure.

The OSA places duties on platforms to assess and mitigate risks to children. This includes conducting risk assessments, implementing safety measures proportionate to identified risks, and using age assurance where appropriate.

The Act is deliberately outcome-focused rather than prescriptive. It doesn't tell platforms exactly what systems to build. It requires them to identify risks and demonstrate they're being addressed.

This flexibility is a feature, not a bug. Different platforms have different risk profiles. A gaming platform with voice chat faces different challenges than a photo-sharing app or a marketplace. The OSA allows for approaches tailored to specific contexts.

But flexibility creates risk. Without a clear framework for what good safeguarding architecture looks like, organisations default to what's measurable and defensible: policies documented, tools deployed, assessments completed.

Here's the uncomfortable truth: you can be OSA-compliant and still have safeguarding systems that fail under real-world pressure.

A risk assessment is a document. It describes risks that might exist and measures that might address them. It doesn't tell you whether those measures actually work when a grooming pattern emerges at 2am on a Saturday.

Age assurance reduces some risks by keeping younger users off platforms or away from certain features. But it doesn't eliminate risk. Determined bad actors work around age gates. Users who pass verification can still be harmed. The question of what happens after someone gets through the front door remains.

Content moderation scales policy enforcement. But as I've written elsewhere, enforcement engages after a breach has occurred. The safeguarding question: is this situation developing in a dangerous direction? requires different systems and different capabilities.

If you're responsible for safeguarding at a platform subject to the OSA, here's what I'd prioritise beyond baseline compliance:

First, understand where risk actually forms in your system

Not where policies say it should be managed; where it actually enters and compounds. This usually happens earlier than enforcement systems engage. Account creation, early interaction patterns, permission settings, behavioural changes over time. The Front Door Theory framework provides a structured way to think about this.

Second, examine your escalation pathways

When something concerning is identified, what happens next? How quickly does it reach someone with authority to act? Where does information stall or get lost? Most safeguarding failures aren't caused by absence of policy, they're caused by escalation systems that don't function under pressure.

Third, be honest about the AI-human handover

'Human in the loop' is a phrase that appears in many risk assessments. But at what point does human judgement actually engage? Is that point appropriate to the risk? Can your human reviewers actually make the decisions they need to make with the information and authority they have?

Fourth, stress-test your systems

Not through audits or document reviews; through realistic scenarios that test whether your architecture holds. What happens when multiple concerning signals emerge simultaneously? When a case falls between policy categories? When the person who usually handles escalations is unavailable?

The OSA creates baseline expectations. Meeting them is necessary. But it's not sufficient if your goal is actually protecting users rather than demonstrating regulatory compliance.

The organisations that will navigate this well are those that treat the OSA as a starting point - a floor, not a ceiling - and invest in understanding how their safeguarding systems actually function when things go wrong.

The ones that will struggle are those that treat compliance as the destination, document their way to adequacy, and discover the gaps only when a serious incident exposes them.