What should companies do first to improve safety for children online?

The first step is to review what data is truly necessary and remove any fields that are not required for the service. From there, companies should implement age-appropriate access controls, simplify privacy notices, and design the user journey so children are not expected to self-protect alone. Safety works best when platforms share responsibility for it.

Start with data minimisation, not extra controls

The first move is to reduce the amount of child data the service collects, keeps, and exposes. If a field is not required for the user journey, safety decision, legal obligation, or abuse prevention, it should not be collected in the first place. That keeps the product easier to explain, easier to secure, and less likely to create hidden risk later.

Data minimisation also shapes the rest of the safety design. Fewer fields means fewer places where consent becomes confusing, fewer records to protect, and fewer ways for a child to be profiled, tracked, or nudged into sharing more than they should.

Build safety into access and privacy design

Once unnecessary data is removed, companies should put age-appropriate access controls around what remains. That usually means defaulting to the safest usable experience, limiting features that create exposure, and making sure children do not need to understand complex settings to stay protected. Age verification and age assurance matter here because the platform cannot apply proportionate controls unless it can make a reasonable age-based decision.

Privacy notices should be short, direct, and written for the actual audience. If a child or parent cannot understand what data is collected and why it matters, the notice is failing its safety purpose. The design goal is not just legal disclosure, it is informed participation with the least possible cognitive burden.

Design the service so children are not left to self-protect alone

The strongest child-safety products do not assume that young users will recognise risk, choose the safest option, or navigate complex opt-outs. Responsibility has to be shared across product design, policy, moderation, and account controls. That means safer defaults, limited data exposure, and flows that do not pressure a child to reveal more information than necessary.

For platforms that operate globally, age-related controls need to align with the relevant regulatory and standards environment. The practical test is whether the product can still function safely if the child does the minimum reasonable thing, rather than the most careful thing.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	A.5.15 — Security of processing	Minimising child data and protecting it by design directly supports GDPR processing safeguards.
	A.5.1 — Policies for information security	Child-safety design needs clear policy rules for collection, access, and disclosure.
Recommendation — Minimise collected child data and apply protective controls to the remaining processing. Define child-data collection and access rules in policy before product rollout.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Age-appropriate access controls rely on limiting what each user or process can reach.
	PL-8 — Information Security and Privacy Architecture	Safe child journeys depend on privacy and security being designed into the service architecture.
	DM-1 — Data Minimization and Retention	The question starts with removing unnecessary fields, which is a direct minimisation control.
Recommendation — Restrict child-facing features and data access to the minimum necessary. Embed privacy and child-safety controls into the service architecture from the start. Collect only the child data required for the service and discard the rest.
ISO/IEC 27001:2022	A.5.12 — Classification of information	Child-related data needs clear handling rules so sensitive fields are not overexposed.
Recommendation — Classify child data before deciding how it may be collected and displayed.
NIST SP 800-63	Digital Identity Guidelines	Age assurance depends on choosing an identity assurance approach proportionate to the service.
Recommendation — Use proportionate identity and age-assurance methods for the risk level of the service.

Practitioner Guidance

What to prioritise: Start with a data inventory for child-facing journeys, then remove any field, permission, or retention path that is not clearly necessary. If a control only exists because the product team has always collected the data, it is a candidate for deletion.

What to verify: Check whether age-based protections are actually enforced in the live flow, not just documented in policy. The main failure mode is a product that says it protects children but still lets them complete the journey through a generic adult path.

What good looks like: A child-facing service should be understandable at a glance, minimise disclosure by default, and avoid making a child responsible for anticipating abuse, tracking, or oversharing. Safety should be visible in the design, not hidden in settings.

Practitioner takeaway: The best first step is to remove unnecessary collection, because privacy, access control, and safer defaults are far easier to get right when the product only handles data it truly needs.