children-data-minimization skill

Children's Data Minimisation and Retention Limits

Overview

Data minimisation for children's data requires a stricter interpretation of GDPR Article 5(1)(c) ("adequate, relevant and limited to what is necessary") than the standard adult context. Recital 38 states that children merit specific protection with regard to their personal data, as they may be less aware of the risks, consequences, and safeguards concerned and their rights in relation to the processing of personal data. The UK AADC Standard 8 explicitly requires that services collect and retain "only the minimum amount of personal data needed to provide the elements of the service in which a child is actively and knowingly engaged." COPPA Section 312.7 prohibits conditioning a child's participation on the collection of more personal information than is reasonably necessary. This skill provides a comprehensive framework for applying these heightened standards.

Legal Framework

GDPR Article 5(1)(c) — Data Minimisation Principle

"Personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed."

When applied to children's data, "necessary" is interpreted strictly. The EDPB has confirmed that the vulnerability of children as data subjects (WP248rev.01 Criterion 7) elevates the data minimisation obligation.

GDPR Article 5(1)(e) — Storage Limitation Principle

"Personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed."

For children's data, retention periods should be shorter than for adult data given that: (a) the purposes of processing often have a shorter useful life for children (e.g., educational progress in a specific grade), (b) the risk of harm from data exposure increases with retention duration, and (c) the child may not have meaningfully consented to long-term retention.

GDPR Recital 38 — Specific Protection for Children

"Children merit specific protection with regard to their personal data, as they may be less aware of the risks, consequences and safeguards concerned and their rights in relation to the processing of personal data. Such specific protection should, in particular, apply to the use of personal data of children for the purposes of marketing or creating personality or user profiles and the collection of personal data with regard to children when using services offered directly to children."

UK AADC Standard 8 — Data Minimisation

"Collect and retain only the minimum amount of personal data you need to provide the elements of your service in which a child is actively and knowingly engaged. Give children separate choices over which elements they wish to activate."

Key ICO interpretations:

• "Actively and knowingly engaged" means the child is intentionally using a specific feature, not passively generating data through background collection
• "Separate choices" means children must be able to use core service features without being forced to activate data-intensive optional features
• Background data collection (location, microphone, contacts, gyroscope) is prohibited unless the child actively triggers a feature requiring it

COPPA Section 312.7 — Data Minimisation

"An operator is prohibited from conditioning a child's participation in a game, the offering of a prize, or another activity on the child disclosing more personal information than is reasonably necessary to participate in such activity."

Strict Necessity Test

For each data element collected from a child, the controller must apply the Strict Necessity Test — a more demanding evaluation than the standard proportionality assessment used for adult data.

Test Questions

Application to Common Data Categories

Retention Period Framework

Children's data must be subject to shorter retention periods than adult data. The following framework establishes maximum retention periods for common categories.

Retention Schedule

End-of-Academic-Year Deletion

For educational platforms, the end of the academic year represents a natural data lifecycle milestone. BrightPath Learning implements the following end-of-year protocol:

1. 30 days before academic year end: Parent receives notification that learning data will be archived
2. End of academic year: Learning progress data is exported to a parent-downloadable report (PDF)
3. 14 days after year end: If parent has not requested retention, granular activity data is deleted; only aggregate progress scores are retained for the next year's placement
4. 60 days after year end: Aggregate scores deleted unless the child continues to the next year's service

Parental Dashboard Design

The parental dashboard is the primary mechanism for parental oversight and control over children's data. It must provide meaningful transparency and actionable controls.

Required Dashboard Features

BrightPath Learning — Dashboard Implementation

┌─────────────────────────────────────────────────────────┐
│  BrightPath Learning — Parent Dashboard                 │
│  Child: Alex (Age 11, France — threshold: 15)           │
│  Account created: 2025-09-01                            │
│  Next age review: 2026-09-01 (age 12)                   │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  DATA WE HOLD                                           │
│  ┌──────────────────┬─────────────────┬──────────────┐  │
│  │ Category         │ Purpose         │ Status       │  │
│  ├──────────────────┼─────────────────┼──────────────┤  │
│  │ First name       │ Account ID      │ Required     │  │
│  │ Age band (10-12) │ Content level   │ Required     │  │
│  │ Learning scores  │ Progress track  │ ✓ Consented  │  │
│  │ Game activity    │ Recommendations │ ✗ Not active │  │
│  └──────────────────┴─────────────────┴──────────────┘  │
│                                                         │
│  PRIVACY CONTROLS                                       │
│  [✓] Share progress reports with me (parent)            │
│  [ ] Allow content-based recommendations                │

Automated Deletion Implementation

Technical Architecture

1. Retention metadata: Every data record includes a retentioncategory field mapped to the retention schedule and an expiresat timestamp
2. Deletion scheduler: A daily batch job identifies all records where expiresat < currenttimestamp and executes deletion
3. Cascade deletion: Account deletion triggers cascade deletion across all related tables (activity logs, content, communications, consent records subject to their own retention schedule)
4. Deletion verification: Post-deletion audit confirms that records are removed from primary storage, backup systems, and any caches
5. Backup purge: Backups containing children's data are subject to a maximum 30-day retention cycle. Backup restoration procedures include a re-deletion step for expired children's data.

Deletion Logging

Every deletion event is logged for accountability:

{
  "deletion_id": "DEL-2026-0047821",
  "trigger": "automated_retention_expiry",
  "data_category": "session_data",
  "child_identifier": "child_bp_8f3a2d",
  "records_deleted": 847,
  "deletion_timestamp": "2026-03-14T02:00:00Z",
  "deletion_scope": "primary_database, elasticsearch_index, redis_cache",
  "backup_purge_scheduled": "2026-04-13T02:00:00Z",
  "verified_by": "automated_verification_check"
}

Common Compliance Failures

1. Adult-equivalent retention: Applying the same retention periods to children's data as adult data, without justification for why shorter periods are not feasible
2. Indefinite retention until deletion request: Retaining children's data indefinitely unless a parent specifically requests deletion violates Art. 5(1)(e) storage limitation
3. Background data collection: Collecting device identifiers, location, accelerometer, or microphone data in the background without the child actively using a feature that requires it
4. Contact list access: Requesting access to the child's device contact list for "find friends" features without strict necessity
5. No parental dashboard: Failing to provide parents with a meaningful mechanism to view, control, and delete their child's data
6. Backup retention gap: Deleting data from production systems but retaining it indefinitely in backups

Enforcement Precedents

• TikTok (DPC Ireland, 2023): EUR 345 million fine included findings on excessive data collection from children, including default public profiles exposing children's content to all users, violating Art. 5(1)(c) data minimisation.
• YouTube/Google (FTC, 2019): USD 170 million settlement for collecting persistent identifiers from child-directed channel viewers for advertising purposes — data not necessary for the service the child was using.
• Epic Games/Fortnite (FTC, 2022): USD 275 million for collecting personal information from children beyond what was necessary, including enabling real-time voice communications by default.

Integration Points

• GDPR Parental Consent: Parental consent scope should be limited to data collection justified by the necessity test — parents should not be asked to consent to unnecessary collection
• UK AADC Implementation: AADC Standard 8 is the primary operational standard for children's data minimisation in the UK
• Children's Profiling Limits: Data minimisation directly limits the data available for profiling, reinforcing AADC Standard 12 restrictions
• Children's Deletion Requests: The retention framework defines what data exists to be deleted and when automatic deletion occurs
• EdTech Privacy Assessment: Educational platforms must balance data minimisation with legitimate educational record-keeping needs