Indonesia Is Starting to Enforce PP TUNAS: Why Child Protection Must Begin in Product Design

For years, child online safety was often treated as something to manage after digital products had already been built.

Platforms created the experience.

Children used it.

Parents were then expected to manage screen time, activate controls, inspect messages and teach children how to avoid strangers.

Indonesia’s Government Regulation No. 17/2025, known as PP TUNAS, changes part of that responsibility.

It pushes child protection further upstream—toward the organisations designing and operating digital products, services and features.[1]

Six months into implementation, that shift is becoming visible.

By September 6, 252 products, services and features from 94 electronic-system providers had completed self-assessments. The government had verified 60: 38 low-risk and 22 high-risk.[2]

This is no longer purely a legal-policy discussion.

It is becoming a question of product management, engineering, privacy and corporate governance.

“Our product is not for children” may not be enough

PP TUNAS applies not only to products designed specifically for children.

It also addresses products, services and features that may be used or accessed by children.[1]

That distinction matters.

A marketplace may not be a children's product.

Neither is a messaging service or general video platform.

But if children can reasonably access it, risk cannot simply be ignored.

The relevant product question becomes:

Could children foreseeably use this feature?

Risk goes beyond harmful content

The regulation identifies several risk dimensions.

They include contact with unknown people, exposure to harmful content, exploitation of children as consumers, threats to child data security, addiction, psychological harm and physiological harm.[1]

That broadens child safety significantly.

A product can moderate explicit content reasonably well while still exposing children to unsafe contact.

Or over-collect data.

Or create engagement loops that generate other risks.

Safety is therefore not one feature.

It is an emergent property of product design.

Risk assessment moves before launch

Ministerial Regulation No. 9/2026 provides the implementation framework.

Providers must document self-assessments, with that documentation established before a product, service or feature becomes accessible to children. Assessments must also be updated when relevant risks change.[3]

For product organisations, this changes the typical sequence.

Instead of:

build → launch → observe → fix,

child-sensitive products increasingly need:

assess → design safeguards → launch → monitor → reassess.

Compliance therefore cannot sit only at the end of the release process.

High risk does not mean prohibited

Of the 60 products and features verified, 22 received high-risk results.[2]

Forty-two profiles had already been formally determined, including 14 high-risk. Another eight high-risk results remained in the formal determination process.[2]

High-risk classification should not automatically be read as a ban.

It indicates that one or more risk dimensions require stronger protection.

That makes it more useful to think of the system as risk-tiered governance.

Age assurance becomes part of architecture

The regulation requires technical and operational measures for age verification that are proportionate to the product’s risk.[1]

That sounds straightforward until privacy enters the picture.

Verifying age can tempt companies to collect more identity data.

PP TUNAS places limits on that.

Data collected for age verification should be used for that purpose and deleted once the purpose has been fulfilled unless other law requires retention.[1]

This creates a meaningful design challenge:

How do you know enough about age without building an unnecessary identity database about children?

High privacy must be the default

For products designed for or potentially used by children, PP TUNAS requires high privacy settings by default.[1]

That is important because defaults shape behaviour.

An adult-oriented product may assume broader sharing unless the user changes settings.

A child-sensitive product should begin from the safer position.

This is privacy-by-default in practice.

Profiling and precise location face strong restrictions

The regulation also prohibits covert or non-transparent practices, collection of precise child geolocation, and generally prohibits child profiling, subject to limited exceptions.[1]

This brings child protection directly into growth design.

Modern digital products optimise engagement, personalisation, conversion and retention.

But a mechanism appropriate for adults may not be appropriate for children.

Product teams therefore need a second question after:

“Does this increase engagement?”

They need to ask:

“What kind of engagement are we creating, and what does it do to a child?”

Children are not smaller adults

This is the central design principle.

Children may not have the same capacity to understand advertising, persuasion, privacy settings, in-app purchases, social pressure, recommendation systems or long-term consequences of sharing information.

A long terms-and-conditions page does not necessarily create meaningful protection.

Legal disclosure and safe experience are different things.

Defaults often matter more than warnings

If a child account is public by default, privacy education must fight the product itself.

If messages from strangers are open by default, safety warnings fight the architecture.

If autoplay never stops, screen-time guidance fights engagement mechanics.

That is why safety-by-default matters.

Product teams need a child-risk review

Before launching a feature, teams can ask:

Could a child access it?

Can strangers contact them?

Can location be inferred?

Are we collecting unnecessary data?

Are we creating commercial pressure?

Could reward mechanics encourage excessive use?

Can recommendation systems lead toward increasingly harmful material?

Is the safest reasonable setting the default?

These questions move safety from legal review into product governance.

Roblox illustrates an operational response

In the government’s September evaluation, Roblox was cited as implementing age gates and age-based feature classification.

Komdigi said about 23 million accounts belonging to users under 16 were automatically moved into more protective settings.[2]

That number is based on the government’s implementation report rather than an independent GATICORP audit.

But the example is useful because protection changed at the configuration level—not merely in disclosure text.

Government says around 28 million children are covered

Komdigi estimated that approximately 28 million Indonesian children had received protection through the implementation of PP TUNAS obligations.[2]

This should be understood as an implementation-coverage estimate.

It is not independent evidence that 28 million children are now free from digital harm.

Future evaluation will need outcome measures.

Did unwanted contact decline?

Did harmful-content exposure decrease?

Did privacy incidents fall?

Did reporting improve?

Coverage is only the first stage.

Self-assessment is not self-certification

Providers perform self-assessment.

The government verifies the submission and determines the risk profile.[1][3]

This distinction matters.

A platform cannot simply classify itself as low-risk and consider the question closed.

Regulators can seek clarification or additional evidence and may reach a different result.[3]

Documentation therefore becomes critical.

Why was a feature designed this way?

What controls exist?

What evidence supports the risk rating?

These questions need traceable answers.

The self-assessment deadline is approaching

Komdigi has allowed providers until December 31, 2026 to complete self-assessments.[2]

It has stated that products that fail to meet the requirement may be directly designated high-risk.[2]

For companies that have not inventoried child-accessible products and features, the implementation window is narrowing.

The proposed 6% penalty is not yet final

A separate September headline concerns a proposed penalty of up to 6% of global revenue for large/global platforms violating PP TUNAS.[4]

For domestic private providers, Komdigi has described proposed maximum levels of Rp1 billion for micro enterprises, Rp5 billion for small businesses and Rp10 billion for medium-sized businesses.[4]

But accuracy matters:

the formula is not yet final.

Komdigi said it has gone through consultation and been submitted for further discussion and formalisation through the PNBP framework.[4]

It should therefore not be described as an already-effective automatic 6% fine.

Compliance cannot be a one-off December project

Digital products evolve continuously.

Recommendations change.

AI features appear.

Messaging is added.

Monetisation changes.

The risk profile can change with them.

The 2026 implementing regulation requires reassessment when risk changes.[3]

Child safety therefore needs to follow the product lifecycle.

Smaller companies are not irrelevant

The debate often focuses on the largest platforms.

But child-risk questions also apply to local games, edtech platforms, marketplaces, fintech products, communities and other services that children may access.

Scale changes implementation resources.

It does not eliminate the design question.

Build child safety into product governance

A useful lifecycle might look like this:

Discovery: could children use the product?

Design: what should the safest default be?

Data: what information is genuinely necessary?

Development: which controls belong in the code itself?

Pre-launch: has risk been assessed?

Monitoring: has behaviour or incident data changed the risk?

Retention: are child data kept only as long as justified?

This is a fundamentally different approach from adding parental controls at the end.

Safety and innovation do not have to be opposites

Regulation is sometimes framed as the enemy of innovation.

That is too simple.

Constraints shape design.

Payment authentication did not destroy digital commerce.

Data minimisation does not eliminate useful services.

The question is how to innovate without requiring users—especially children—to be perfect risk managers.

The real product question

The most useful question for a founder or product leader is therefore not only:

“Are we compliant?”

It is:

“If a child uses our product exactly as we designed it to be used, does that design reasonably protect them?”

If safety still depends entirely on a parent noticing a problem at exactly the right moment, the product may not yet be genuinely safe by design.