Child Safety & Privacy Readiness

Age captured at sign-up

Date of birth is required to register; the age band is derived server-side and the DOB is locked so it can't be edited upward later.

Under-13 gating

Under-13 accounts are created in a 'pending parental consent' state and cannot be used until a guardian confirms via an emailed link.

Legacy age re-confirmation gate

Accounts with no confirmed age (legacy/backfilled) are held as 'age_unknown', never treated as adults, and blocked from the platform until they declare a date of birth. The band is derived server-side, the DOB is locked, under-13s are routed to parental consent, minors have protections applied immediately, and an immutable age-confirmation event is recorded. Ordinary users cannot re-declare to change permissions; only an audited admin correction can.

Age-appropriate privacy defaults

Under-18 profiles default to members-only/private, with location, social links and contact email hidden, and no marketing or non-essential analytics.

Public-web redaction

Only fully public profiles appear on the marketing site and in search; minors' network/private profiles are never exposed publicly.

Minor social usernames never public

Under-18 social handles (Instagram/TikTok/etc.) can never be set to 'public' and never appear on the public media kit, directory, or in search. A single age-aware resolver (unit-tested) is the only code path that decides visibility, so the API and the UI can never diverge.

Opt-in professional sharing to verified partners

A minor may choose to let WFN-verified brands/partners see their social handles for professional purposes. It is off by default (defaults to hidden), requires explicit opt-in, is limited to accounts carrying the WFN Verified badge, every access is written to a safeguarding log, and an anti-scraping cap limits how many distinct minors one partner can view per day.

Social-link kill switches

Safeguarding admins can disable an individual minor's social links, or disable all minor social links platform-wide, instantly and everywhere. Both require an audit-logged reason and only ever restrict, never widen, visibility.

Protected messaging

Adults cannot initiate contact with a minor; a minor must reach out first. Recipients' 'who can message me' setting is enforced server-side.

Blocking

Members can block anyone; blocking is enforced bidirectionally on both starting and sending messages.

Reporting

Report tooling on profiles and conversations, with categories for grooming/CSAE/self-harm auto-escalated to urgent, and any report about a minor prioritised.

Safeguarding queue + RBAC

A moderation dashboard with least-privilege admin roles; sensitive data (reporter identity, DOB, evidence) is restricted to safeguarding roles.

Audit trail

Every moderator/safeguarding action writes an immutable audit-log entry.

Signposting

999, CEOP, NSPCC and Childline are surfaced in the Safety Centre and the report flow.

Legacy accounts moved to age_unknown

Accounts that pre-date age capture were previously assumed 18+. They have now been reclassified as 'age_unknown' — never treated as confirmed adults — and are required to declare a date of birth on next login before they can use the platform. Live progress of this re-consent campaign is shown above.

Self-declared age only

Ages are self-declared, not verified. This is treated as a starting point, not compliant age assurance.

Email-based parental consent

Guardian consent is captured by emailing a confirmation link. This establishes a workflow and audit trail but is not, by itself, a robust verification of parental responsibility.

Band boundaries and permission matrix

The age bands (under-13, 13–15, 16–17, 18+) and what each can do encode a conservative reading of the Children's Code as a product default, not a legal determination.

Sharing minors' socials with verified partners

Letting under-18s opt into sharing social handles with verified brands/partners is a deliberate product decision made privacy-first (off by default, logged, rate-limited, revocable). Whether it should exist at all for minors, what 'verified partner' must legally require, and what consent/parental involvement it needs are decisions for the DPO/legal — see the DPIA item below.

DPO review & sign-off

This entire implementation, the two policy drafts, and the age-band matrix need Data Protection Officer review before going live.

Data Protection Impact Assessment (DPIA)

A DPIA is required for a service likely to be accessed by children. It must be completed and documented — and must specifically assess the opt-in channel that lets verified partners view minors' social handles (necessity, proportionality, consent model, and the verification bar for a 'partner').

Age assurance method

Choose and document a proportionate age-assurance approach appropriate to the risks, per the Children's Code.

Verifiable parental consent

Select a legally robust method of verifying parental responsibility for under-13s (email confirmation alone is likely insufficient).

Retention & deletion schedule

Define how long reports, audit logs, consent records and account data are kept, and automate deletion.

Lawful basis mapping

Document the lawful basis for each processing purpose, including how consent is captured and withdrawn.

Existing-user age campaign

Contact the backfilled accounts to collect a real DOB and apply correct protections; do not assume they are all adults.

Safeguarding policy & DSL

Appoint a Designated Safeguarding Lead, adopt a written safeguarding policy, and define escalation/referral routes to the police and LADO/agencies.

Moderator vetting & training

Ensure anyone with access to children's data is appropriately vetted (e.g. DBS where applicable) and trained.

ICO registration & records

Confirm ICO registration and maintain a Record of Processing Activities (ROPA).