Singapore PDPA Rules for Children's Data: 2026 Guide

Short answer: what the PDPA expects for children's data in 2026

If your app, game, learning platform or connected device is likely to be accessed by anyone under 18 in Singapore, the Personal Data Protection Act (PDPA) applies to that data with a higher standard of care than you would apply to adult users. In practice that means parental or guardian consent for children under 13, plain-language notices for 13- to 17-year-olds, privacy-protective defaults (geolocation off, profiles not publicly searchable), a Data Protection Impact Assessment before launch, and a breach plan that reaches parents, not just the child.

None of this is a new statute. It comes from the Personal Data Protection Commission's (PDPC) Advisory Guidelines on the PDPA for Children's Personal Data in the Digital Environment, issued on 28 March 2024, read alongside the existing PDPA obligations. The guidelines are advisory rather than binding, but the PDPC has said it will interpret the PDPA consistently with them — so for a product team, they function as the compliance bar. If you are building or operating a consumer product for the Singapore market, our Singapore technology and compliance hub sets out how these obligations land in engineering work, and our Singapore PDPA compliance implementation page covers the controls themselves.

Stratgik is a technology firm, not a law firm. What follows is an implementation view for founders, product managers and engineering leads. Confirm your specific obligations with qualified Singapore counsel before you rely on any of it.

Who the children's guidelines actually apply to

The trigger is not "did you build this for kids". The trigger is whether your online product or service is likely to be accessed by children. The PDPC gives social media, technology-aided learning (EdTech), online games, and smart toys and connected devices as examples, but the test is broader than those categories.

That catches teams who assume they are out of scope: a fitness app with a 13+ rating, a D2C loyalty programme, a tuition-centre booking platform, a multiplayer game with no age gate. If a reasonable person would expect under-18s in your user base, you are in scope — and a terms-of-service line saying "you must be 18" does not help if your traffic says otherwise.

Note the definition mismatch that catches people out: in these guidelines a "child" is anyone below 18. The PDPC's older Advisory Guidelines on Selected Topics treat a "minor" as anyone under 21 for some purposes. If your policies were written against the older guidance, they need a second look.

Consent by age band

This is the part most product teams get wrong, because it is not a single age gate — it is two regimes in one flow.

Three practical consequences. First, the onus of proving valid consent sits with you, which makes the consent record an engineering artefact, not a legal one — timestamp, version of the notice shown, age band asserted, and the method used to establish it. Second, you may set a higher age of consent where your context justifies it; the PDPC's own example is requiring parental consent for 13-year-olds in an education setting. Third, withdrawal must be as easy as giving consent, which rules out the common pattern of a one-tap signup and an email-support-only deletion path.

Defaults, minimisation and what counts as an unreasonable purpose

The guidelines convert several abstract principles into concrete product requirements:

• Geolocation off by default. Precise location should not be collected automatically for a child's account. Where location is genuinely needed, prefer approximate location.
• Child accounts not public and searchable by default. Discoverability is an opt-in, not a default state.
• Children's data treated as sensitive. The PDPC says it must be accorded a higher standard of protection, pointing to the Basic and Enhanced Practices in its Guide to Data Protection Practices for ICT Systems.
• Profiling has a line through it in one direction. Using a child's data or profile to target content that is harmful or age-inappropriate — as described in the Code of Practice for Online Safety — is treated as an unreasonable purpose. Profiling for age assurance, or to steer a child away from harmful content and towards safety resources, is treated as reasonable.
• Data minimisation throughout. Including on the age-assurance data itself: establishing an age range is not a licence to retain identity documents.

The app-store layer: age assurance from 2026

The PDPA sits inside a wider Singapore child-safety regime, and 2026 is the year the platform layer tightened. IMDA issued its Code of Practice for Online Safety for App Distribution Services in January 2025. It took effect on 31 March 2025, with the age assurance obligations following after a grace period that ran to the end of March 2026, as tracked by Digital Policy Alert.

The Code designates the major app stores — Apple App Store, Google Play Store, Huawei AppGallery, Microsoft Store and Samsung Galaxy Store — and requires them to establish a user's age or age range with reasonable accuracy, give children differentiated accounts with more robust settings, and warn children and their parents about the implications of opting out of those defaults, per Rajah & Tann's summary.

Why this matters even though you are not an app store: the age signal now exists upstream, your app's age rating has distribution consequences, and "we had no way of knowing our users were children" weakens every quarter. None of it transfers your PDPA obligations to the platform.

DPIAs: the accountability obligation in practice

The PDPC advises organisations to conduct a Data Protection Impact Assessment to meet the accountability obligation, and specifically encourages one before releasing a product or service likely to be accessed by children. Annex A of the guidelines provides sample questions, which is the most useful free artefact in the document.

DPIAs usually fail for process reasons, not legal ones: run once, by a consultant, after the architecture is frozen. A DPIA that changes nothing is a document, not a control. The version that works is short, owned by the product lead, versioned alongside the feature spec, and re-run whenever data flows change — a new analytics SDK, a new processor, a new storage location. If you are weighing building that governance in-house against buying it, our build vs buy calculator is a reasonable starting point.

Breach notification when the affected individual is a child

Singapore's mandatory breach notification regime applies as normal: a notifiable breach must be reported to the PDPC, and affected individuals must be notified where the breach is likely to result in significant harm. The children's guidelines add a layer on top.

The operational implication is unglamorous: if your breach runbook has one notification template, written for adults, you have a gap. You need a second at a reading level a 12-year-old can follow — and your data model needs to know which accounts are child accounts before the incident.

What this costs if you get it wrong

Since 1 October 2022, the maximum financial penalty under the PDPA is the higher of S$1 million or 10% of an organisation's annual turnover in Singapore, where that turnover exceeds S$10 million — a change confirmed when the increased penalties came into force, as summarised by DLA Piper. Separately, the PDPC updated its advisory guidelines and enforcement guide at the same time to explain how it sets penalty amounts.

For most startups and mid-market firms the realistic exposure is not the headline cap. It is the remediation order, the published enforcement decision carrying your company name, and the enterprise or government deal that stalls in security review for two quarters.

A practical checklist

1. Decide, in writing, whether you are in scope. Look at actual analytics by age band, not your intended audience. Record the conclusion and the date.
2. Implement an age band signal at account creation, stored as a first-class field, with the method and timestamp. Minimise what you keep to establish it.
3. Build the parental consent path for under-13s — and the notice to the parent of the purposes, which is a separate requirement from the consent itself.
4. Rewrite the child-facing notice in plain language. Test it on an actual teenager. Infographics and short video are explicitly encouraged.
5. Flip the defaults: geolocation off, profile not publicly searchable, discoverability opt-in, the most protective settings pre-selected.
6. Audit your ad and recommendation stack for any path that could surface age-inappropriate content to a profiled child account.
7. Run a DPIA before launch, using Annex A of the guidelines, and make it a living document owned by the product lead.
8. Apply the higher security standard: encryption in transit and at rest, least-privilege and logged access to child records, and a vendor list you can produce on request.
9. Write the second breach template, child-readable, plus the parent/guardian notification path.
10. Check your processors and re-check withdrawal: it must be as easy as giving consent, in-product rather than by email ticket.
11. Review annually, and on any change to data flows, SDKs, processors or storage locations.

If you also transfer this data outside Singapore, read the above together with the transfer limitation obligation. And if the architecture is still movable, getting the data model right before launch is far cheaper than retrofitting it — our app cost estimator helps size that work.

Frequently asked questions

Does the PDPA set a hard minimum age for using an online service in Singapore?

No. The PDPA does not set a minimum age to use a service. What the PDPC's guidelines set out is who can give valid consent: under-13s need a parent or guardian, while 13- to 17-year-olds can consent themselves if they can readily understand your policies and the consequences. Other Singapore laws and platform codes may impose their own age restrictions, and where those conflict with the guidelines, those laws prevail.

Our app is not designed for children. Are we still in scope?

Possibly. The test is whether the service is likely to be accessed by children, not whether it was designed for them. If your analytics show under-18 users, or your category typically attracts them, assume you are in scope and document your reasoning either way.

Are the children's guidelines legally binding?

They are advisory and not exhaustive. But the PDPC is likely to interpret the PDPA's existing obligations consistently with them, so in enforcement terms they set the practical standard. Treat them as the bar, and take legal advice on your specific facts — Stratgik is a technology firm, not a law firm.

How do we verify a parent is actually a parent?

The guidelines do not mandate one method, and the data minimisation expectation cuts against collecting identity documents. Most teams settle on a proportionate approach: a verified parental email or mobile confirmation for low-risk services, stronger assurance where the data or risk is more sensitive. Document why your method is proportionate.

What changed for app stores in 2026, and does it affect our app?

IMDA's Code of Practice for Online Safety for App Distribution Services took effect on 31 March 2025, with the age assurance obligations applying after a grace period that ran to the end of March 2026. It binds the designated app stores, not individual developers, but it makes your app's age rating and your own age signals more consequential for distribution.

Where should we start if we have done none of this?

Start with the scope decision and the age band signal, because every other control depends on knowing which accounts are child accounts. Then the consent path, then the defaults, then the DPIA. Our Singapore PDPA compliance implementation work follows roughly that order, and the Singapore hub covers how it fits with the rest of a Singapore market entry.

Related reading and next steps

For a second opinion on where your product stands — in scope or not, which gaps matter most, and what closing them costs — book a free 30-minute session with the Stratgik team via our contact page. We will walk your data flows, mark the gaps against the PDPC guidelines, and say plainly which are urgent. No obligation, and you keep the notes.