IEEE 2089-2021 is a voluntary standard, not a law. No regulator can fine you for ignoring it. That framing matters, because it changes what the standard is for: it is the engineering companion to the principles that binding children's codes — most obviously the UK Age Appropriate Design Code — assert but do not operationalise. The codes tell you children's best interests must come first. IEEE 2089 is one attempt to say what "first" looks like in a backlog.
If you build a product that children can reach — not only one aimed at them — this is a standard worth reading before your first design review, not after your first incident. Below is what its fifteen obligations actually ask of an engineering team, grouped into the four themes they fall into once you stop reading them as legal prose and start reading them as work.
What the standard is, and what it is not
IEEE 2089 organises itself around a service lifecycle and a set of numbered principles. It repeatedly anchors itself in the UN Convention on the Rights of the Child — evolving capacities, the right to play, the right to privacy, the right to be heard. What makes it useful to engineers is that it does not stop at "respect children's rights." It expects you to recognise a child user, differentiate your behaviour by developmental stage, and keep evidence that your design choices actually protect the children using them.
It is not a certification, not a safe harbor, and not a substitute for a lawyer's read of the regulations that bind you. Treat conformance as a discipline that produces evidence, not as a shield.
Theme 1 — Recognising and serving children
The foundation is IEEE-2089-RECOGNIZE-CHILD: implement mechanisms to identify child users and adapt the service to their developmental needs and rights. In practice that is an age-assurance signal feeding a configuration layer — the moment you believe a user is a child, content filtering, privacy defaults, and safety features change.
Recognition is only step one. IEEE-2089-RIGHTS-CAPACITY tells you not to treat all children identically: respect evolving capacities by giving graduated autonomy, protection, and participation rights that match developmental maturity. Concretely, that is age-banded user segments — a seven-year-old and a sixteen-year-old are not the same user — each mapped to a defensible set of capabilities.
Two obligations make the service legible to the children in it. IEEE-2089-AGE-APPROPRIATE-TERMS asks for layered, age-appropriate terms, privacy policies, and community standards in clear language and accessible formats — not one wall of legalese, but summaries a child of the relevant age can actually parse. IEEE-2089-DIGITAL-LITERACY goes further and recommends (the standard's softer register) that you promote digital literacy by weaving age-appropriate education about safety and privacy into the experience itself, rather than bolting on a help page nobody reads.
Theme 2 — Data protection by design
IEEE-2089-DATA-PROTECTION-DESIGN is the obligation most engineers will recognise: embed data protection by design and by default for child users, with the most privacy-protective settings on out of the box and data collection minimised to what is strictly necessary. If you have implemented GDPR Article 25, you have the muscle memory; the standard asks you to point it specifically at children — disable behavioural tracking and profiling by default for child accounts, and treat maximum privacy as the shipping default rather than a setting a child has to discover.
Sitting alongside it is IEEE-2089-ECONOMIC-EXPLOITATION: protect children from economic exploitation. That means auditing your monetisation for manipulative patterns — loot boxes, pay-to-win mechanics, undisclosed in-app purchases, pressure-selling — requiring parental gatekeeping for younger children's purchases, and ensuring advertising aimed at children is clearly identifiable and does not exploit their credulity. This is a design-defaults obligation as much as a commercial one: the dark pattern and the checkout flow are the same code.
Theme 3 — Safety and redress
The highest-severity obligation in the set is IEEE-2089-ONLINE-SAFETY: proactively protect children from contact risks (grooming, bullying, harassment), content risks (harmful or age-inappropriate material), and conduct risks (being led into harmful behaviour). The standard is explicit that safety measures must be proportionate to the risks you identify and must not rely solely on user reporting — you are expected to detect and intervene, not just to add a "report" button.
Where your product ranks or recommends, IEEE-2089-CONTENT-DELIVERY applies: classify content by age-suitability and configure recommendation systems to present age-appropriate material — and, critically, not to amplify harmful or age-inappropriate content algorithmically. The recommender is in scope, not just the moderation queue.
When something does go wrong, children need a way out. IEEE-2089-ACCESS-REMEDY requires accessible, child-friendly complaint mechanisms and effective remedies — content removal, account restoration, data correction or deletion, and human review of automated decisions — reachable, where developmentally appropriate, without forcing a child to go through an adult. IEEE-2089-COMPLAINT-MECHANISMS sharpens the operational expectation: reporting must be easy to find, simple to use, age-appropriate, and backed by clear response times and escalation paths.
Rounding out the theme, IEEE-2089-PARENTAL-ENGAGEMENT asks for parental tools that balance guidance with a child's evolving autonomy and privacy — and it insists that where monitoring is active, the child is told, in age-appropriate terms. The standard's preference is for dialogue over covert surveillance. "Done" here is a parental-controls model that graduates with age and always surfaces an active-monitoring indicator to the child.
Theme 4 — Governance and lifecycle
The remaining four obligations are what separate a product that feels safe from one that can show it is. IEEE-2089-RISK-ASSESSMENT asks for age-group-specific assessments across four domains — privacy, safety, wellbeing, and developmental impact — conducted before launch and repeated at intervals. IEEE-2089-DESIGN-VALIDATION then asks you to document and validate the design decisions those assessments drive, with evidence that protective measures achieve their intended outcome and records available for review.
IEEE-2089-LIFECYCLE is the organising idea of the whole standard: apply age-appropriate considerations at every stage from requirements through decommissioning, with a child-safety checkpoint at each phase of your SDLC. And IEEE-2089-IMPLEMENTATION-GUIDE offers the adoption path — maturity assessment, gap analysis, roadmap, and a conformance register — explicitly scaled to the size and risk of your organisation.
How 2089 sits next to binding law
Read the obligations above and you will notice they rhyme with codes that are enforceable. Data protection by design mirrors GDPR Article 25; the risk-assessment duty maps onto the UK AADC's DPIA expectations and the Online Safety Act's risk-assessment duties; the safety obligations echo the same three-risk (contact, content, conduct) framing regulators use. That overlap is the point: implementing IEEE 2089 well produces exactly the documentation and design decisions a regulator asking about the UK Age Appropriate Design Code would expect to see.
Phrase this carefully, though. Conformance with a voluntary standard is evidence of good-faith, principled design — not a safe harbor and not a defence. A regulator evaluates your actual implementation, not your adoption of a framework. IEEE 2089 makes your case more credible; it does not make it for you.
What the standard leaves open
IEEE 2089 is deliberately outcome-oriented in places. It tells you to recognise child users but is technology-neutral about how — self-declaration, estimation, third-party verification are all left to your risk judgement. Its content-delivery and parental-engagement provisions read more as principled guidance than prescriptive method, and its digital-literacy and implementation sections use the softer "should." That flexibility is a feature for a standard meant to fit products from a small game to a global platform — but it means the standard hands you the what and expects your risk assessment to justify the how.
If you want to see the fifteen obligations in their structured form — each with its citation, category, and severity — browse the IEEE 2089 framework in the obligation explorer. It is the same corpus this article is grounded in.