Purpose of the Template
If your platform hosts user-generated content accessible to minors, you need an age assurance policy that meets regulatory expectations under frameworks like the UK's Online Safety Act. This template provides the foundation for documenting your age verification approach, explaining your methodology to regulators, and demonstrating compliance with effective verification standards.
You'll use this policy to:
- Document your transition from age inference models to verification methods recognized as compliant
- Establish clear procedures for identifying, verifying, and segregating underage users
- Create an auditable record of your age assurance controls for regulatory investigations
- Define escalation paths when verification fails or users attempt circumvention
This is not a marketing document. It's your technical control specification for age assurance, written for regulators, auditors, and your internal compliance team.
Prerequisites
Before customizing this template, confirm you have:
Technical capabilities mapped: Know which verification methods your platform can implement (document upload, biometric verification, third-party identity services, payment card validation). Don't list methods you can't operationalize within 90 days.
Risk assessment completed: Document what harmful content categories apply to your service (the Online Safety Act references pornography, suicide, eating disorders, and self-harm content). Your age assurance rigor should scale with content risk.
Vendor evaluation finished: If you're using third-party age verification providers, document their compliance certifications, data processing agreements, and accuracy rates. Regulators will ask.
Data protection impact assessment: Age verification processes personal data. Your GDPR Article 35 assessment should cover biometric processing, data retention periods, and lawful basis (typically legitimate interest or legal obligation).
Baseline metrics: Establish your current false-negative rate (children incorrectly verified as adults). You'll need this to demonstrate improvement post-implementation.
The Template
AGE ASSURANCE POLICY
Version: [X.X]
Effective Date: [Date]
Review Cycle: Quarterly
Owner: [Chief Compliance Officer / Trust & Safety Lead]
1. SCOPE AND APPLICABILITY
This policy applies to [platform name] services accessible in jurisdictions requiring
age verification for [content categories: user-generated content / social features /
age-restricted material]. Specifically covers:
- User registration and account creation
- Content access controls for age-restricted categories
- Periodic re-verification for existing accounts
- Age-up transitions (users turning 13, 16, 18)
2. REGULATORY FOUNDATION
This policy implements age assurance requirements under:
- [UK Online Safety Act / EU Digital Services Act / state-level requirements]
- [General Data Protection Regulation](/glossary/general-data-protection-regulation) (Article 8 for children's consent)
- [Jurisdiction-specific child protection laws]
3. AGE VERIFICATION METHODOLOGY
We do NOT rely solely on age inference models (behavioral analysis, device patterns,
browsing history) as primary verification. Our methodology combines:
PRIMARY VERIFICATION (one required at registration):
□ Government-issued ID verification via [vendor name]
- Acceptable documents: [passport / driver's license / national ID card]
- Verification process: [document authenticity check / facial comparison / liveness detection]
- Accuracy standard: [X]% true positive rate for age determination
□ Biometric age estimation via [vendor name]
- Technology: [facial age estimation / voice analysis]
- Accuracy threshold: [X]% confidence interval
- Fallback: Document verification if confidence < threshold
□ Third-party identity service integration
- Provider: [name and certification status]
- Data shared: [minimal dataset for age verification only]
- Retention: [verification result only, not underlying documents]
SECONDARY CONTROLS (applied in combination):
□ Payment card validation (cardholder age verification)
□ Mobile network operator age data (where available and consented)
□ Parental consent workflow for users under [age threshold]
AGE INFERENCE USAGE:
We use age inference models ONLY as supplementary signals to:
- Flag accounts for re-verification when behavior suggests misreported age
- Prioritize manual review queues
- Identify circumvention patterns
Inference models do NOT satisfy our verification requirement.
4. VERIFICATION TIMING AND TRIGGERS
- At registration: All new accounts undergo PRIMARY VERIFICATION before content access
- Periodic re-verification: Every [12 months] for accounts created before [policy date]
- Triggered re-verification when:
* User reports age misclassification
* Automated systems flag behavior inconsistent with stated age
* Content moderation identifies potential underage user in restricted areas
* User attempts to access age-gated features
5. FAILURE HANDLING
When verification fails or user refuses:
- Account access limited to [age-appropriate content only / read-only mode / suspended]
- Re-verification allowed after [24 hours / 7 days]
- After [3] failed attempts: [manual review / account suspension / parent contact]
- Appeals process: [describe escalation to human review]
6. DATA PROTECTION CONTROLS
Age verification data handling:
- Retention: Verification RESULT retained indefinitely; supporting documents deleted within [24 hours / 30 days]
- Storage: [encrypted at rest / segregated database / third-party processor only]
- Access: Limited to [compliance team / trust & safety investigators] via access logs
- Cross-border: [verification processed in EEA only / standard contractual clauses]
- User rights: Data Subject Access Requests include verification method and date, not biometric templates
7. MONITORING AND EFFECTIVENESS
Quarterly metrics reported to [Board Risk Committee / Chief Compliance Officer]:
- False negative rate: Children incorrectly verified as adults
- False positive rate: Adults incorrectly age-gated
- Verification completion rate: Users who complete vs. abandon
- Re-verification trigger frequency
- Manual review volume and outcomes
Threshold for policy review: False negative rate exceeds [X]% for two consecutive quarters
8. VENDOR MANAGEMENT
Third-party age verification providers must demonstrate:
- [[ISO/IEC 27001](/glossary/isoiec-27001)] certification
- Published accuracy rates for age determination
- GDPR Article 28 data processing agreement
- Incident notification within [24 hours]
- Annual SOC 2 Type II audit covering age verification controls
9. CIRCUMVENTION DETECTION
Automated monitoring for:
- Multiple accounts from same device with different ages
- Age changes inconsistent with time passage
- Shared verification documents across accounts
- VPN/proxy usage during verification (flagged for manual review)
10. REGULATORY REPORTING
In event of regulatory inquiry:
- Compliance team provides this policy + implementation evidence within [5 business days]
- Metrics package includes: verification methods used, accuracy rates, re-verification frequency
- Incident log: verification failures, circumvention attempts, manual review outcomes
Customization Instructions
Section 1 (Scope): List your actual content categories that trigger age requirements. If you host user-generated video, specify whether that includes live streaming (higher risk). If you're a gaming platform, note whether you offer in-game purchases or chat features.
Section 3 (Methodology): Delete verification methods you don't use. If you're implementing document verification, name your actual vendor and their certification status. Ofcom expects you to explain why you chose specific methods over alternatives.
Data protection (Section 6): Your retention periods must align with your legitimate interest justification. If you're retaining verification results indefinitely, document why (typically: ongoing obligation to prevent underage access). If you're processing biometric data, confirm you have an Article 9 GDPR lawful basis (explicit consent or substantial public interest).
Metrics (Section 7): Set your false-negative threshold based on your risk assessment. Platforms hosting content about self-harm or eating disorders should set lower tolerance than general social networks. The Online Safety Act doesn't specify acceptable error rates, but regulators will compare your performance to industry benchmarks.
Vendor requirements (Section 8): If your verification provider can't produce a SOC 2 Type II report covering their age determination controls, that's a red flag. You're accountable for their failures.
Validation Steps
Before you publish this policy internally:
Legal review: Confirm your verification methods satisfy jurisdictional requirements. The Online Safety Act's "highly effective" designation isn't defined by specific technologies; it's outcome-based. Your legal team should validate that your chosen methods meet the effectiveness standard.
Technical validation: Can your platform actually enforce the controls you've documented? If Section 5 says accounts are suspended after three failed verifications, your engineering team must confirm that workflow exists and functions correctly.
Data protection officer sign-off: Your DPO should validate Section 6 against your GDPR Article 30 processing records and any existing Data Protection Impact Assessments. Age verification often triggers DPIA requirements because it processes children's data and may include biometric processing.
Test the appeals process: Before regulators ask, verify that users can actually request manual review and that your trust and safety team responds within your documented timeframe.
Audit your metrics pipeline: Section 7's quarterly reporting requires automated data collection. Confirm you can actually measure false-negative rates (this typically requires test accounts with known ages or comparison against subsequent manual reviews).
The UK regulator can fine companies £18 million or 10% of qualifying worldwide revenue for Online Safety Act violations. Your policy needs to demonstrate not just compliance, but systematic, measurable effectiveness. Write it as if Ofcom will read it during an investigation, because they will.
