What belongs in an age assurance audit pack before the regulator asks Written on 20 Aug 2026

If you lead compliance or legal at a social platform, dating app, or adult site, or you supply age or identity evidence to the platforms that do, you will be asked to show your work. Ofcom, a data protection authority, or a major customer wants more than your word that the age checks are accurate. They want to see why you chose the method, how it performs on real users, what happens when it fails, and who owns each decision. That evidence is your audit pack, and the time to assemble it is before anyone asks.

In a nutshell

Accuracy alone does not make an age check defensible. A defensible pack links legal duty, risk, method, evidence, and accountability into one case a regulator can follow from end to end.
Begin from your own legal obligations and risk assessment, then choose the technology. A vendor's certificate is evidence you add along the way, not the place you start.
Document the whole system: data flow, threshold rationale, attack controls, alternatives, appeals, and retention.
A NIST benchmark or an ISO certificate proves one narrow thing about one component, tested one way. Record what each test actually covered rather than treating it as blanket proof that your whole system works.
Keep the pack alive with versioning, dashboards, incident records, and periodic revalidation.

An audit pack is your architecture in evidence form

Age assurance touches legal, product, engineering, security, data protection, accessibility, and support. A DPIA (data protection impact assessment) and a vendor brochure are a useful start, but a couple of documents cannot stand in for a system that spans all of those teams. Your pack has to show how they reached one decision together and how you keep it current.

The clearest way to organize it is as an assurance case. Your service makes a claim, such as keeping under-18s out of a defined feature, then backs it with arguments and evidence. Every limitation, dependency, and exception is written down, so a reviewer sees the gaps before they go looking for them.

What belongs in the audit pack?

Eleven records make up a complete pack. Each one maps to a named owner and a specific piece of evidence.

Record	What it captures
1. Scope and legal map	Everything in scope, mapped to an owner. Services, countries, user groups, features, and age thresholds, each tied to a regulatory source and review date The ages that differ: access, data-consent, contractual, and age-appropriate design Multi-country services: a matrix of national differences in scope, accepted methods, session rules, third-party independence, privacy, and redress
2. Risk assessment and assurance objective	Why the control is needed and what it must achieve. The harm you are reducing, its likelihood and severity Why age assurance is proportionate when lighter measures are not The objective in measurable terms, not "verify age" Failure modes to weigh: false acceptance, false rejection, circumvention, exclusion, privacy, free expression, account sharing, and displacement
3. Method and architecture decision	Every step in the waterfall, and why you chose it. Quality checks, age estimation, liveness, wallet proof, document check, human review, and appeal Routing rules, retry limits, and the alternatives you rejected The trade-offs behind the call: privacy, protection, accessibility, cost, and operational impact
4. Vendor and component due diligence	What you know about each supplier. Ownership, subcontractors, processing locations, security controls, and incident history Update policy and audit rights Whether each proof matches the version you deployed
5. Independent performance evidence	Lab results and your own testing, side by side. NIST, national-trial, and lab results with the exact algorithm, date, dataset, and metric Your own testing on your users, devices, and threshold Sample composition, ground truth, confidence intervals, and disaggregated outcomes
6. Threshold and policy rationale	The threshold you set and who signed it off. Challenge age, quality gates, and escalation logic The trade-off between minors passing and adults being challenged, plus the residual risk you accepted The decision body, approval date, and model version, with evidence that policy matches production
7. Security and abuse testing	How the system holds up under attack. Threat model and red-team results for printed photos, screen replays, masks, injected video, account sharing, and credential theft What you fixed and what still stands open Testing across the complete transaction and the handoffs between suppliers, not only a penetration-test summary
8. Privacy and data governance	What data you touch and how you govern it. DPIA, lawful basis, data-flow diagram, and retention schedule Any biometric special-category processing and the lawful condition for it Deletion you can prove, and what you keep for fraud, audit, or appeal
9. Accessibility, alternatives, and redress	Whether everyone can get through, and get a fair second chance. Accessibility testing, supported devices and languages, and fallback methods Who can overturn an automated decision Whether a fallback quietly excludes the people most likely to need it
10. Operational monitoring and incident response	What you watch, and what you do when it breaks. A live dashboard and alerts tracking selection, quality, challenge, fallback, abandonment, attacks, fairness, and appeals, not only throughput A plan for vendor outages, mass false decisions, data exposure, and regulator notification Who can roll back a threshold, and how emergency calls are reviewed
11. Change control and revalidation	Proof of what was running, and when. A version inventory of model, SDK, policy, and UI Triggers for retesting, DPIA review, and regulator engagement Prior versions kept, so you can show which system was live during an incident

Treat certifications as scoped evidence

A certificate proves one thing about one component, tested one way, on one version. A liveness certification might cover presentation attacks, where someone holds a printed photo or a screen up to the camera, yet say nothing about injection attacks, where fake video is fed straight into the pipeline. A benchmark might test the age model without ever touching your signup flow.

So when you file a NIST result or an ISO certificate, note exactly what it covered and where your live product differs from what was tested. That honest scoping is what makes the evidence hold up.

Lead with a one-page executive index

The first page should let an executive or regulator move quickly: the claim, the duties it meets, the owner, the architecture version, the key metrics, the known limitations, the last review date, open actions, and links to the underlying evidence.

A short index also surfaces your own gaps. If you cannot name your ground truth, your fallback owner, your retry policy, or your deletion proof, that hole shows up on page one, while you still have time to close it.

How often should you update the audit pack?

Continuously, not once a year. Undated evidence describes a system that may no longer be running, so give every record a date and a version. Log every material change to your model, SDK, threshold, or user journey, and revalidate when any of them move. Feed incidents back into the pack as they happen.

A dating app that quietly ships a new liveness SDK, or a social platform that lowers a challenge threshold to reduce signup friction, has changed the exact system a regulator will ask about. The pack earns its keep only if it still describes what is running today.

Where Youverse stands

No vendor can hand you a finished audit pack, and we do not pretend otherwise. What Youverse gives you is clean, scoped evidence to put in it. YouAge estimates age from a single selfie in under a second and stores no biometric data, which keeps your data-flow diagram short. YouLive confirms a real person is present at capture and detects presentation attacks, replay, injection, and deepfakes, with its presentation attack detection independently tested to ISO/IEC 30107-3 Level 1 and 2, so your security section can cite a real report and name exactly what it covers. We supply the model identifiers, processing descriptions, and contractual controls. The threshold, user journey, fallback, and monitoring stay yours to own and to document.

Talk to us about audit-ready evidence

Book a walkthrough and we will map the Youverse evidence, from model identifiers to independent test reports, to the records your pack needs.

Frequently asked questions

Is a vendor certification enough for compliance?
No. A certification is scoped evidence for one component, one version, and one test method. Your service still has to prove suitability, integration, threshold policy, privacy, and real-world performance.

Who should own the audit pack?
One accountable leader, with legal, privacy, security, product, engineering, accessibility, and support each contributing controlled evidence. When responsibility is shared but no one is truly accountable, gaps slip through the cracks between teams.

How often should the pack be updated?
Continuously for incidents and material changes, with a scheduled formal review on top. Regulatory, model, SDK, threshold, and user-journey changes should all trigger revalidation.

Can the pack hold confidential technical evidence?
Yes. Keep restricted material behind access controls and prepare a shareable subset for regulators and customers. The index should note where restricted evidence sits and who can authorize access.