Your app is in scope for the Children's Online Privacy Code if it is a social media service, a relevant electronic service or a designated internet service that is likely to be accessed by children, whether or not children were ever the intended audience. That is the test in the exposure draft the Office of the Australian Information Commissioner (OAIC) released on 31 March 2026, and the Code must be registered by 10 December 2026. The commencement date and any transition period have not yet been confirmed, so the sensible assumption for anything being built or maintained now is that the obligations arrive with the registration rather than years later.
This article is an engineering brief rather than a legal memo. It takes each obligation in the draft and describes what has to exist in the product for the obligation to be met. It is not legal advice, and the final Code may differ from the draft.
Where the Code comes from and where it stands
The Privacy and Other Legislation Amendment Act 2024 received Royal Assent on 11 December 2024 and gave the OAIC a mandate to develop a Children's Online Privacy Code. The exposure draft, titled the Privacy (Children's Online Privacy) Code 2026, went out for consultation from 31 March to 5 June 2026 and drew 135 written submissions. The OAIC is now considering those submissions and running a regulatory impact analysis ahead of the 10 December 2026 registration deadline.
It is worth separating this from the law covered in our earlier explainer on Australia's under-16 social media law. That Act is an age ban on named service types: it says who may not hold an account. The Code governs how any in-scope service handles children's personal information once children are on it.
The scope test: likely to be accessed by children
The draft applies to entities already covered by the Privacy Act 1988 that provide a social media service, a relevant electronic service (messaging, or a game with chat) or a designated internet service (broadly, a service that lets people access or receive material online), where the service is likely to be accessed by children or primarily concerns the activities of children. Health services are excluded.
The phrase doing the work is "likely to be accessed". A study app, a fitness community, a family-oriented marketplace or a general social product does not need to market to children to meet that test. The first engineering task is therefore a written assessment of who actually uses the product, backed by whatever age data you hold, so that the scope decision is a documented finding rather than an assumption.
Best interests of the child becomes a design record
Every collection, use and disclosure of a child's personal information must be consistent with the best interests of the child. The draft asks entities to weigh exploitation risk, developmental impact, effects on freedom of association and play, disproportionate effects on vulnerable groups and the evolving capacity of children at different ages. The principle also overrides some familiar exceptions: the draft prevents relying on the APP 6.2 exceptions or on personal information sourced from third parties for direct marketing to children.
Inside a product this becomes a decision record attached to each data flow. For every field collected and every downstream use, the team writes down why it is in the child's interest, who signed it off and when. That record is what an independent reviewer will ask for, and it is far cheaper to produce as features are built.
High privacy by default becomes a settings matrix
The draft requires high privacy by default, with personal information collected only where it is strictly necessary to provide the service, a higher bar than the reasonably necessary standard most Australian products are built to. Anything reasonably necessary but not strictly necessary needs a transparent and active choice from the user. The requirement applies to existing accounts as well as new ones when the Code commences.
Translated into engineering, that is a settings matrix: every toggle in the product, its default for a child account, its default for an adult account, and the justification for each. Analytics, personalisation, contact discovery, public profiles and location sharing all sit in that matrix. The migration to apply the child defaults to existing accounts is a job that needs to be built and tested, not a flag flipped on launch day.
Age assurance scaled to risk
Entities must take steps that are reasonable in the circumstances to ascertain a user's age before collecting personal information, with the required certainty rising with the risk of harm the service carries. A date-of-birth field may be defensible on a low-risk service and plainly inadequate on one with open messaging. The draft also requires that sensitive information collected for age assurance is deleted once it has served its purpose, unless an exception applies.
The build implication is an age gate designed to the risk profile of the product, a record of the method chosen and why, and a deletion job for whatever the age check collected. The design question for user onboarding is how to do this without turning the first ninety seconds into a form.
Notices, geolocation and the audit trail
Privacy notices for children must be age appropriate: written for the youngest child in the target age range, or otherwise suitable for a child aged 10 to 12, clear, concise, and free of legal jargon, using graphics or video where that helps. Where a mechanism allows a parent to monitor a child's geolocation, the child must be notified as soon as practicable that the monitoring is happening.
Both of these are product work. A layered notice that a ten-year-old can follow is a writing and design task, and the geolocation notification is a real-time event in the app, not a paragraph in a policy. Underneath everything sits an audit trail: which defaults applied to which account, when age was assessed and how, what was deleted and when. A breach of a registered code is an interference with privacy under the Privacy Act, and serious or repeated interferences can attract civil penalties under section 13G, so the ability to show what the system did is not optional.
What to do now, and who verifies it
If there is a reasonable chance your product is accessed by children, start with the scope assessment and the settings matrix, because those two documents drive everything else and neither needs the final Code to begin. Products in the social and community and education categories should assume they are in scope until the assessment says otherwise. The same architectural discipline also keeps a product clear of the privacy grounds that cause rejection at app store review.
On the boundary of our role: we build the platform to the requirements, and we bring in an independent third party to verify it. Legal interpretation of the Code and any certification belong with your lawyers and an independent assessor. Our part is the engineering, and it is work we have done before, including SuspectED for Flinders University with forensic-grade chain-of-custody, and healthcare products built to the Privacy Act 1988 and the Australian Privacy Principles. Across 100+ shipped products we hold a 98 percent first-time app store approval rate. If you want the scope assessment and settings matrix done with an engineering team in the room, book a discovery call.