When children's data appears in the product: what to do first
The first step is not deletion. Confirm the scope first: how the data entered the product, which systems hold it now, and whether processing is still active. Only then choose between suppression, deletion, or preservation for a possible notification. Acting before scope is confirmed usually creates a second problem instead of closing the first.
Why this sits on a different track
General data protection rules treat a child's personal data as a separate category, with tighter consent standards and less tolerance for ambiguity about age. An internal fix rarely closes the file on its own. Once the data is confirmed as belonging to a minor, the organisation is expected to show that it identified the issue, assessed the exposure, and made a documented decision — not simply that it deleted a record afterwards.
If an automated system, rather than a human reviewer, is doing the profiling or scoring of the affected users, the position changes again. Regulation (EU) 2024/1689 (AI Act) treats uses that touch a child's vulnerabilities as a separate risk category, and the relevant obligations become binding from 2 August 2026 (position as of 3 March 2025). A product already live before that date is not exempt once the obligations start to apply; it is simply on a countdown that has not yet reached zero.
First steps, in order
Each step below has an owner and a fixed order. Skipping the map to go straight to deletion is the most common way to lose the evidence needed for the next decision.
| Step | Action | Who does it |
|---|---|---|
| Freeze | Stop whichever process is still adding or using the data | Engineering lead, same day |
| Map | List every system, backup and log that holds a copy | Data protection lead |
| Classify | Confirm the data belongs to a minor and how it arrived | Legal, with product |
| Assess | Decide whether a notification duty is triggered | Data protection lead |
| Decide | Choose suppression, deletion, or preservation as evidence | Legal |
| Record | Log the decision and the reasoning, dated | Whoever leads the response |
Where the data came from changes the next step
There are usually three sources: direct sign-up without an age gate, a third-party dataset bought or licensed for another purpose, or a dataset absorbed through an acquisition. Each source points to a different remedy: fix the intake flow, revisit the wording of the licence, or check what the earlier owner represented at the point of transfer.
When a licensed dataset is the source, read the licence again before deleting anything: When a term sheet promises more than the licence gives is a familiar pattern, and it usually changes who is responsible for the record in the first place.
If the fix means changing the product itself
Sometimes suppression is not enough, because the feature keeps recreating the exposure — an analytics pipeline that re-collects the same signal, or a recommendation engine trained on it. If removing the data means redesigning the feature that collects it, treat that as a separate workstream with its own timeline. The situation runs in parallel with, but is not identical to, When the product is redesigned mid-dispute and its limits become clear once the rebuild starts.
Who decides, and on what evidence
The first decision is internal: the data protection lead and legal decide together, based on the map and the classification from the steps above. If the exposure is material, the decision moves outward to the relevant supervisory authority, which reviews the same evidence — how the data arrived, how long it was live, and what the organisation did once it found out.
If a regulator or a commercial partner exercises an audit right over the same pipeline, treat that separately from the assessment above: When an audit right is invoked without notice and the pipeline is still live, the response follows its own clock, not the one described here.
Three branches worth separating
If the age of the affected users cannot be confirmed either way, treat the data as a minor's until proven otherwise; the burden of proof runs the other way once the question has been raised at all.
If the data already trained or fed a live model, the removal decision has to reach the model, not only the source table, or the exposure continues after the original record is gone.
If your organisation falls within scope of Directive (EU) 2022/2555 (NIS2) as an essential or important entity, a security incident touching this data can trigger an incident-notification duty under that framework as well, running alongside any data-protection notification, not instead of it.
What this page does not cover
This page does not fix the intake flow that let the data in, and it does not draft the notification itself. It also does not cover situations that only look similar from the outside. A challenged token peg, for instance, sits on a completely different regulator and clock: When a stablecoin peg is challenged step by step is a separate track from the one described here.
Verified
Reviewed 3 March 2025. Primary sources for this page: Regulation (EU) 2024/1689 (AI Act); Directive (EU) 2022/2555 (NIS2).
Related situations
A related situation starts one step earlier, before the product is even built: When a data set is bought without provenance in the deal, the same triage sequence applies to the sourcing decision itself.
FAQ
What is the first step when children's data appears in the product?
Confirm the scope before acting on anything. Establish how the data entered, which systems hold it now, and whether it is still being processed. That map decides whether the right move is suppression, deletion, or preservation for a notification.
Which deadline is already running?
The internal assessment clock starts at the moment the organisation becomes aware, not at the moment it confirms every detail. If the exposure turns into a notifiable event, a separate notification deadline begins from that same moment, and under most applicable frameworks it is measured in hours rather than days.
Who decides, and on what evidence?
Internally, the data protection lead and legal decide together, based on the map of where the data lives and how it arrived. If the exposure is material, the relevant supervisory authority reviews the same evidence from the outside.