Read the Ofcom age-assurance penalty decisions from the first half of 2026 closely and a pattern emerges that most coverage skips past. Almost every one of them is not a single fine. It is two.
In February, Ofcom fined the adult-site operator 8579 LLC a record £1.35 million for failing to implement highly effective age assurance — and a separate £50,000 for failing to respond to the regulator’s statutory information request, with the site also ordered to deploy age checks under threat of a £1,000-per-day continuing penalty. In May, Youngtek Solutions Ltd was fined £500,000 for the missing age checks and another £100,000 — a fifth of the total — purely for failing to respond to a formal request for information. The action against Kick Online Entertainment ran the same way: £800,000 for the age-assurance failure, plus a further penalty for non-cooperation. AVS Group, registered in Belize, drew a roughly £1 million penalty on the same template.
Strip away the headline numbers and the structural lesson is this: regulators are no longer only punishing the absence of an age check. They are punishing the inability to evidence one and to answer when asked. The information request is becoming the part of enforcement that platforms underestimate — and it is testing a capability that a thrown-together age gate simply does not have. This post is about that capability: what the information request actually probes, why a pass/fail flag in your database is not an answer to it, and what an age layer that can withstand the question looks like.
Two Penalties, One Lesson
The two-fine structure is not an accident of these particular cases. It is baked into how the Online Safety Act enforcement regime works. Ofcom’s age-assurance duties for pornographic services came into force in July 2025, and its enforcement programme — opened in January 2025 — proceeds in two motions. First, the regulator gathers information using statutory powers, issuing a notice that compels the service to explain and demonstrate what age assurance it has in place. Then, on the strength of what comes back (or does not), it decides whether the duty has been met and what penalty applies.
That sequencing is why the second fine keeps appearing. A service that ignores the information request has not just been uncooperative; it has denied the regulator the evidence the whole regime runs on. Ofcom treats that as its own breach, with its own penalty, precisely because the information-gathering power is the spine of the system. You can be fined for having no age check. You can be fined again, separately, for being unable or unwilling to show your working. And while several of these operators were outright no-shows, the principle generalises beyond the defaulters: the moment a regulator asks “demonstrate that your age assurance is highly effective,” a platform whose only artefact is a boolean column is in trouble even if it answers the email promptly.
This reframes the compliance problem. The deliverable is not a gate that returns true. It is a gate that returns true and can later prove, to an evidentiary standard, that it did so correctly, for that user, in that session, by a method that meets the standard.
What the Information Request Actually Tests
“Highly effective age assurance” is not a checkbox; it is a standard with criteria — technically accurate, robust, reliable, and fair — and the information request exists to test your method against them. When Ofcom (or the ICO, or a US state attorney general) asks you to demonstrate your age assurance, it is not asking whether you believe it works. It is asking for the operational evidence that it does: which method was applied, what it concluded, how it performs at the threshold, what happens to users who fail, and how you handle the inevitable edge cases.
Notice what that is not. It is not “send us your privacy policy.” It is not “confirm you have a date-of-birth field.” Ofcom and the ICO made the underlying point explicit in their March 25, 2026 joint statement and throughout the dual ICO/Ofcom compliance picture: self-declaration alone is not effective, and the burden is on the platform to show effectiveness rather than assert it. The request is a “show me,” not a “tell me.” A platform that has treated age assurance as a one-line integration — call an API, store the result, move on — discovers at exactly the wrong moment that it kept the outcome and threw away the evidence.
A Pass/Fail Flag Is Not Evidence
Here is the gap that catches engineering teams. The natural way to implement an age gate is to store, per user, a single fact: age_verified = true. It is clean, it is queryable, and it is almost useless as evidence.
A boolean cannot tell a regulator how the user was verified — whether by a robust biometric estimate, a document check, or a self-declared birthday that should never have counted. It cannot show the method’s accuracy near the threshold, which is the only region where age assurance is actually hard. It cannot reconstruct what happened in a specific challenged session six months ago. And it certainly cannot demonstrate the “evidence of effectiveness” that 2026’s performance-based compliance posture demands — the documented decisioning logic, the monitoring, the fairness across demographics that increasingly make age assurance look less like a feature and more like a regulated onboarding programme in fintech.
What the information request implicitly asks for is closer to session-level evidence: a record that a check occurred, which method ran, what band it returned, whether it was escalated, and when — retained in a form you can export in the structure a regulator expects. Some authorities now want exactly that session-level artefact rather than a pass/fail flag sitting in a production table. The difference between those two things is the difference between answering the request and earning the second fine.
The Evidence–Privacy Paradox
There is an obvious trap here, and it is worth naming before someone walks into it. The instinct, on reading “keep more evidence,” is to log everything — store the face image, retain the document scan, archive the raw biometric — so you can prove what you did. That instinct manufactures a different liability. An age-assurance system that hoards identity documents and biometrics is a surveillance honeypot, and the same regulators demanding evidence of effectiveness will, under data-protection law, fine you for collecting and retaining more personal data than you needed. You cannot resolve a regulator’s evidence request by becoming the next breach headline.
The resolution is to separate the two things that age verification conflates. The decision — a check ran, this method, this band, this timestamp, this outcome — is durable, low-sensitivity metadata you can and should retain. The raw evidence behind the decision — the face, the document, the biometric template — is high-sensitivity data you should never have kept in the first place. The architecture that satisfies both the Online Safety Act and the data-protection regime is one where the sensitive computation happens at the edge and only a result crosses the wire. On-device age estimation means the platform never receives the face image; what it retains is the auditable record of the determination, not the personal data that produced it. You keep the answer to the information request and discard the thing that would have made you a target.
This Is Not Just a UK, Not Just a Porn, Problem
It would be a mistake to file all of this under “Ofcom” and “adult content.” The evidentiary turn is broader, and it is coming for platforms that have nothing to do with pornography.
In the United States, COPPA has long required operators to retain records demonstrating verifiable parental consent — an evidence obligation, not just a behavioural one — and the 2025 rule amendments sharpen the documentation expectations further. The expanding state-law patchwork increasingly turns on whether a platform can show it took reasonable, demonstrable steps, and the wave of platform liability litigation — the Roblox-style negligence suits — makes the evidence trail a litigation-defence asset, not just a regulatory one. In discovery, “we had an age gate” is worth very little without the records to substantiate which users it stopped and how. The Ofcom decisions are simply the most legible early example of a principle every regime is converging on: maintaining a record of your compliance reasoning and your per-session decisions is what separates a defensible programme from a hopeful one.
There is also a quieter expansion in the Ofcom strand itself. The enforcement began with the clearest cases — pornographic services with no checks at all — but the duty and the information-gathering power are not limited to them. Any service in scope can receive the request. The platforms that will struggle are not only the ones with no gate; they are the ones with a gate and no evidence.
What an Answerable Age Layer Looks Like
If the information request is the real test, design backwards from it. An age layer you can defend has a handful of properties that a bolt-on gate lacks.
Age is verified as its own logged step, not inferred as a side effect. Every check produces a structured decision record — method, result band, escalation status, timestamp — so the evidence exists by construction rather than being reconstructed under deadline. The method scales by risk, so most users clear a threshold via privacy-preserving facial age estimation that returns a band, and only users near the line are escalated to stronger evidence such as a document or NFC chip read — and crucially, that escalation decision is itself part of the record, which is exactly what demonstrates the “robust at the threshold” property the standard cares about. The records are exportable in the shape a regulator asks for, not trapped as a flag in a production schema. The sensitive inputs never persist, so the evidence trail is not also a breach surface. And because the proof is a reusable, bound credential, you can re-present a prior determination without re-collecting anything — answering the regulator and serving the user from the same durable artefact.
The test for any vendor, then, is not “does your check pass a demo.” It is “when a regulator sends an information notice, can your system produce session-level evidence of effectiveness, in an exportable format, without exposing the personal data you should never have stored?” That question belongs at the top of any vendor security checklist, and most off-the-shelf age gates answer it badly.
The Honest Limits
Two caveats keep this honest. First, evidence is necessary but not sufficient: a beautiful audit trail will not save a platform that genuinely has no effective check, and several of 2026’s penalties landed on operators whose age assurance was simply absent. The records matter most for platforms that are trying to comply and need to prove it — they convert a good-faith effort into a defensible one. Second, the information request is partly an operational obligation, not only a technical one. Some of the second fines were for not replying at all; no architecture substitutes for having a process that notices a statutory notice and responds to it on time. The right reading is that the technical capability (you can produce the evidence) and the operational capability (you actually answer) are both required, and that the technical side is the one most teams have quietly skipped.
It is also worth being plain that producing evidence does not make a method effective — it makes an effective method provable. The two have to be built together. A system that logs a weak check thoroughly has only documented its own failure.
How Xident Fits
Xident was built around the decision, not the document — which is precisely the posture the information request rewards. We verify age as a first-class, logged step and retain an exportable, auditable record of what was checked, by which method, what band it returned, and when, so that an Ofcom information notice or a US state inquiry can be answered with evidence rather than assertions. We classify across bands (+12, +15, +18, +21, +25) rather than a single binary, and we escalate from on-device facial age estimation to document or NFC verification only near the threshold — and that escalation logic is itself part of the record, which is what demonstrates robustness where it actually matters. Because the face image and document never reach your servers, the evidence trail you retain is metadata about a decision, not a cache of biometrics waiting to become a data-protection penalty. And because the output is a reusable, bound credential, the same artefact that satisfies a returning user satisfies an auditor. If you want the regulator-by-regulator version of this, our breakdown of how Xident meets the UK Ofcom age-assurance requirements walks through the duty in detail.
The 2026 penalty decisions are a preview of how every age-assurance regime will be enforced: not “do you have a gate,” but “show me.” The platforms that treated age verification as a flag to set will find they kept the outcome and discarded the proof. Build the age layer that produces the evidence as it runs, keep the decision and not the data behind it, and the information request stops being the second fine — it becomes the email you can answer in an afternoon.
If you operate a platform that needs an age check you can actually evidence to a regulator, start here.
