The single most effective children's privacy control is the one no child ever has to find. A default that is set correctly protects every child account whether or not the child reads a notice, understands a settings page or resists a prompt. That is why the UK Children's Code devotes five of its fifteen standards to defaults and the influences around them, why the EU Digital Services Act's Article 28 guidelines start with private accounts, and why California's design code, whatever its litigation status, was built around the same idea. This article sets out the defaults feature by feature, for the product, privacy and trust-and-safety leads who own the settings model.
The rule and its exception
Standard 7 of the UK code says settings must be high privacy by default, unless the service can demonstrate a compelling reason for a different default, taking account of the best interests of the child. The exception is real but narrow. "Users expect it" and "engagement drops" are not compelling reasons in the code's sense; a safety feature that only works when on, such as a block list, can be. The test a team should apply: if the reason for the default would embarrass you in a regulator's meeting, it is not compelling.
The DSA's Article 28(1) asks for appropriate and proportionate measures for a high level of privacy, safety and security, and the Commission's July 2025 guidelines describe private-by-default accounts as the baseline for minors. California's section 1798.99.31(a)(6) uses almost the code's words, high level of privacy by default, though the reader should check the current status of that Act.
Visibility and contact
The first default is who can see the account. For a child account, the profile, posts and activity should be visible only to accepted connections, and the account should not appear in public search, in suggestions to strangers or in lists of people nearby. Contact from people the child has not accepted should be off: no direct messages from non-connections, no group invitations from strangers, no comments from outside the connection list. The DSA guidelines point at exactly these features as the ones that expose minors to unwanted contact. Standard 9 of the code, on data sharing, backs the same default from the data side: a child's data is not disclosed, including to other users, without a compelling reason.
Geolocation
Standard 10 of the code is specific. Geolocation options are off by default. When location tracking is active, the child sees an obvious sign. Options that make the child's location visible to others default back to off at the end of each session, so a child who turned location on for one purpose is not tracked indefinitely. California's design code carries the same prohibition on collecting precise geolocation by default. In product terms: location permission is requested at the point of use with a plain explanation, the indicator is persistent while location is in use, and the "share my location" state is not remembered across sessions for child accounts.
Profiling and recommendations
Standard 12 of the code switches profiling off by default and permits it only with measures to protect the child from harmful effects, in particular being fed content detrimental to health or wellbeing. Article 28(2) of the DSA prohibits advertising based on profiling where the platform is aware with reasonable certainty that the user is a minor, and the guidelines ask that recommender systems for minors prioritise explicit choices over inferred interests. The default for a child account is therefore a recommender that runs on what the child has chosen, not on what the system has inferred, and an advertising mode with no behavioural targeting. If the service wants any personalisation on for children, the compelling reason and the harm mitigations must be written down first.
Nudge techniques
Standard 13 prohibits nudge techniques that lead or encourage children to give unnecessary personal data or to weaken or turn off their privacy protections. Article 25 of the DSA prohibits interfaces that deceive or manipulate any user, and the California code names dark patterns explicitly. The defaults above are only as good as the screens around them. A default that is protective but sits behind a prompt that says "Turn on location so friends can find you" with a large green button and a small grey "not now" is a nudge, and it undoes the default. The test: present the protective option and the less protective option with equal weight, use neutral language, do not repeat a declined prompt, and never gate a feature the child already had behind a privacy trade.
Parental controls with transparency to the child
Standard 11 says that where a service provides parental controls, the child must be given age-appropriate information about them, and where a parent can monitor activity or track location, the child must see an obvious sign when monitoring is on. California's code requires the same obvious signal. The DSA guidelines describe parental tools that are transparent to the minor. The design decision is that monitoring is never covert: a persistent indicator in the child's interface, a plain-language explanation of what the parent can see, and controls that loosen as the child's age band rises. IEEE 2089 frames this as balancing guidance with the child's evolving autonomy, and the IEEE 2089 guide covers that framing.
A default settings matrix
A useful artefact is a short matrix of features against age bands. Four columns is enough: the feature, the default for under 13, the default for 13 to 17, and the compelling reason if any default is less than the most protective one. Where the last column is empty, the default is the protective one. The matrix is the evidence for standard 7, the input to the DPIA under standard 2, and the thing a reviewer asks to see. A first version for a typical social feature set reads like this:
- Profile visibility. Under 13: connections only. 13 to 17: connections only. Compelling reason: none.
- Messages from strangers. Under 13: off. 13 to 17: off. Compelling reason: none.
- Precise location. Under 13: off. 13 to 17: off, opt-in per session. Compelling reason: none.
- Behavioural recommendations. Under 13: off. 13 to 17: off. Compelling reason: none.
A worked example
Tidewell, a fictional company, runs a fitness app with social features for teenagers. Its original defaults were a public profile, a "runners near you" map and a feed ranked by engagement. The team rebuilt the child settings model. Profiles became connections-only, the map was turned off with a session-only opt-in and a persistent banner while active, and the feed for accounts under 18 switched to a chronological view of chosen topics. A prompt that asked "Make your profile public to get more kudos?" after every run was removed. The parental dashboard, which had shown a child's activity without telling the child, gained an indicator in the child's app and a page explaining what a parent can see. The matrix above became the first page of the DPIA.
How Landfall helps
Landfall maps the default settings, geolocation, profiling, nudge and parental control obligations from the UK code, the DSA and the California Act onto a project once the questionnaire establishes that children are likely to use it, and groups them into one backlog item per feature rather than one per framework. Answers about age bands and about which features exist decide which items fire, so a service without location features never sees a geolocation item. Each item carries its citations, and the reviewer can record the compelling reason where a default is less than the most protective one. Browse the obligations in the UK AADC and EU DSA explorers, and read the fifteen standards checklist for the rest of the code.