What GDPR requires for children's data and edtech
There is no fixed price and no certificate for GDPR compliance, and the regulation requires no audit. If a customer or regulator now asks an edtech product or school platform to comply, the cost and effort depend on what personal data the service processes, how consent is designed, and which minimum age applies in each country where children use the service. The core duties for services offered directly to children are an age check, parental consent for children below 16 or the lower national age set between 13 and 16, information written so the child can understand it, erasure of data collected from children on request, and a data protection impact assessment (DPIA) where the processing involves vulnerable people. Under Article 8, the controller must also make reasonable efforts to verify that a parent has given or authorised consent, using available technology.
The organization owns these controls. Its legal team, data protection officer (if one is designated) and product owners decide the lawful basis, the age thresholds for each market, the wording of notices and the retention rules. An implementation partner such as DeployOpen can prepare the systems and evidence: the consent flow and its logs, the account and age-gate settings, the erasure path for children's records and the DPIA inputs. DeployOpen does not decide whether the processing is lawful and does not issue reports or certificates. Regulators and national supervisory authorities enforce the GDPR, and certification under Article 42 is voluntary and issued only by accredited bodies. The reader should confirm with counsel which national age applies to each market before building the consent flow, because a single global setting can be wrong for some users.
Start with three checks. First, list every country where a child can register and record the age threshold that applies there. Second, confirm that the consent record can show who consented, to what, and when, because the controller must be able to demonstrate consent under Article 7(1). Third, map every store of children's data so that an erasure request, under the sixth ground listed in Article 17(1), can reach each one without undue delay. Under Article 12(3), the response is due within one month of receipt, extendable by two months only if the child's representative is told the reasons within the first month. A DPIA should be started early if the product profiles pupils, scores learning progress or makes automated decisions about them, since these are among the criteria in WP248 rev.01 and processing that meets two of them will in most cases require a DPIA.
How the consent age changes what you build
Under Article 8, where no national age has been set, a child's consent to information society services offered directly to children is valid from age 16. Below that age, a parent or guardian must give or authorise consent. This is the baseline your product must meet in any market where no lower age applies, so it is the safest default to build against until local rules are confirmed.
In practice, this means the platform needs an age signal at sign-up and a branch in the flow for users below 16. The controller must make reasonable efforts to verify that parental consent was given or authorised, using available technology. Self-declared birth dates alone are weak evidence, so product teams should decide early which verification method fits the data involved.
- Age capture: Ask for age or date of birth before any account is created, and store the result separately from profile data.
- Branching logic: Route users below 16 to a parental consent step before any optional processing begins.
- Consent records: Log who consented, when, for which processing and through which method, so you can demonstrate consent.
- Consent withdrawal: Let the parent withdraw consent and link that action to the erasure ground for data collected from children.
Before launch, confirm with your counsel or supervisory authority that the age-16 baseline is the correct answer for each market in which the service is offered.
Member States may lower the age for consent to information society services, but not below 13. A service offered to users in several countries therefore has to apply the age that matches each user's market, which may be 13, 14, 15 or 16. The lower limit of 13 is fixed by the regulation, so no national age can allow a younger child to consent alone.
The operational consequence is that the age test is no longer a single rule. The system must know the user's country or applicable national rule and apply the matching threshold to the account. A user who moves between markets, or a service that changes its country of operation, can change which threshold applies, so the rule should be tied to a documented market determination and not hard-coded once.
- Per-market configuration: Store the applicable age threshold as a configuration value keyed to each market, with an owner and a review date.
- Market determination: Document how you decide a user's market, such as account country, language or billing address, and explain the method in your records.
- Threshold changes: Track national changes and test the flow when a threshold changes, rather than relying on a single launch-day check.
- No going below 13: Reject any configuration that sets a consent age under 13 for information society services.
Confirm each national age with your supervisory authority or counsel before you rely on it, because the threshold you set in configuration is only as accurate as the legal analysis behind it.
The Article 8 consent rule applies to information society services offered directly to children. A service that is not offered directly to children does not automatically trigger the age-based consent rule, so the age test changes shape. Whether a service is offered directly to children depends on its design, content, marketing and actual audience, not only on the terms of service. Adult-only services can still attract child users, so the question must be answered by looking at how the service is built and promoted.
For product teams, the key step is a documented decision about target audience. If the service is aimed at adults and the team has taken reasonable steps to keep children out, the consent-age flow may not be needed. If the service is likely to attract children, the team should treat the Article 8 rules as applicable and build the age branch anyway. Relying on a checkbox that states the service is for adults does not settle the question on its own.
- Audience analysis: Record the intended audience, marketing channels and features that would appeal to children.
- Age gating decision: Document why an age test is or is not included, and when that decision will be reviewed.
- Monitoring signals: Watch for account creation patterns, school-linked sign-ups or search terms that show child users are present.
- Fallback path: Plan what happens if a user self-identifies as a child, including a move into the parental consent flow.
Before relying on this position, ask your counsel to confirm the analysis, because the classification determines whether the age-based flow is legally required.
How a children's data compliance project runs
The sequence moves from identifying which services children can reach to a documented evidence pack that a customer or regulator can test. Each phase hands a defined output to the next, so the organization can show how its age, consent, notice, erasure and risk decisions were reached.
Scope which services are offered to children
The organization lists every service, feature and app that a child can reach directly, including free tiers, learning tools, chat, social features and third-party embeds. The privacy or product lead confirms which ones are information society services offered directly to children, since Article 8 turns on that question. The output is a scoped service inventory with a named owner for each service and a short note on why each one is in or out of scope.
Map age and national rules for each market
For each country where children use the service, the team records the age of digital consent that applies, using the default of 16 or the lower national age that Member States may set no lower than 13. Legal counsel confirms each national position against the current text, because the rule is set by the Member State and not by the regulation alone. The output is a market matrix that lists the age threshold, the source checked and the date it was confirmed.
Design age checks and parental consent flows
Engineers and product owners design how the service makes reasonable efforts to check age, and how it obtains and verifies parental consent where a child is below the applicable age. The design should record what the controller can demonstrate, since consent must be provable under Article 7(1), and should avoid collecting more identity data than the check needs. The output is a tested consent journey, a log of each consent event with its version and the consent text shown, and a written rationale for the verification method chosen.
Rewrite notices for child readers
Privacy notices are rewritten so a child can understand what is collected, why, and what rights they and their parents hold, and a parent-facing version covers the consent decision. Content owners test both versions with representative readers in each target age group where the organization can do so. The output is approved notice versions for each age band and language, linked from the sign-up and consent screens, with the version history kept in the documentation set.
Build erasure and retention paths
Engineers map every store that holds child data, including analytics, logs, backups, search indexes and processor systems, and define how each one is erased when Article 17(1) applies, including the ground for data collected from children for information society services. Retention periods are set per data type and enforced by scheduled jobs rather than manual cleanup. The output is an erasure runbook, a retention schedule and a test record showing a sample erasure request traced through each system.
Run the DPIA for the service
The team runs a data protection impact assessment against the nine WP248 rev.01 criteria, and records vulnerable data subjects as a criterion where children are involved. Most child-facing services meet at least two criteria, so a DPIA is usually required, and the assessment should cover profiling, recommendations, monitoring and any third-party analytics. The DPO, where designated, reviews the result and the controller signs off residual risk. The output is a dated DPIA with mitigations assigned to owners and a review trigger tied to product changes.
Assemble the evidence pack
The organization collects the evidence a customer, school partner or supervisory authority would ask for: the service inventory, market matrix, consent logs, notice versions, erasure test records, retention schedule and DPIA. Each item is cross-referenced to the principle or article it supports, so an assessor can trace a claim to a record. The output is a versioned evidence index, reviewed before release. Note that this pack demonstrates compliance and does not constitute a certificate, since the GDPR requires no certification and any audit must come from an independent party.
Verifying parental consent with reasonable effort
Article 8 requires controllers to make reasonable efforts to verify that a parent has consented before a child under the applicable age uses an online service. The options below range from a simple age question to independent verification, and each trades verification strength against the personal data it collects.
Age gate at sign-up
An age gate asks the user for a date of birth or an age band before any account is created. It is the cheapest control to build and it sorts users into those who need a parent and those who do not. Its weakness is that a child can enter any date, so it is weak evidence on its own. Check that the gate is neutral in wording, does not suggest a more convenient answer, and that the answer is recorded so the controller can show how the decision was made. Illustrative: a child who enters an adult birth year still passes the gate, so the controller needs a second control.
Parent email confirmation
The parent is asked for an email address, and the service sends a message that the parent must confirm before the child's account becomes active. This shows that someone with access to that mailbox agreed, but not that the person is the child's parent. Keep the parent's address only for the consent record and for the parent's own rights requests, and do not use it for marketing unless the parent separately agrees. Confirm that the confirmation link expires and that the consent record stores the time, the wording shown and the version of the notice.
Verified parent account
A parent creates their own account, verified through a stronger method such as a checked payment card or a multi-factor login, and then approves the child's account from that account. This gives stronger evidence that an adult with parental responsibility is involved. The cost is more personal data about the parent, including identifiers and login records that now need a retention rule and a security review. Ask whether the parent account can be used for one child only and whether the parent can withdraw consent as easily as they gave it.
Third-party verification service
An external provider checks the parent's identity or age and returns a yes or no result, or a short token, to the service. This can reduce what the service itself holds, because the service may not need to store identity documents. The trade-off is a processor relationship, a contract under Article 28, a check of where the provider processes data, and a dependency on its availability. Ask the provider to return the minimum result, to delete raw documents promptly, and to document how each check was performed so the controller can show what happened.
Consent records that prove consent
Article 7(1) requires the controller to be able to demonstrate that consent was given. The consent record should hold the child's account identifier, the parent's approval event, the notice version shown, the verification method used, the time, and any later withdrawal. Store the record separately from marketing data, restrict who can read it, and set a retention period that matches the account's life. Test the record by asking whether a supervisory authority could reconstruct a single parental approval from it.
Erasure of data collected from children
Article 17(1) gives children's data its own erasure ground, which sits alongside five others. Systems that collected a child's data for an online service must be able to find it, delete it on time and show the deletion reached every copy.
The child data erasure ground
Article 17(1) lists data collected from a child for information society services as one of six grounds that require erasure without undue delay. The other five cover data no longer needed, withdrawn consent, a successful objection, unlawful processing and a legal obligation to erase. For a children's service, this ground applies even where the child's data would otherwise remain useful to the product. Check that your data model records which records were collected from a child, so the ground can be identified when a request arrives.
One-month response window
Under Article 12(3), the controller must act on a request under Articles 15 to 22 without undue delay and within one month of receipt. The period can be extended by two further months for complex or numerous requests, but only if the person is told of the extension and its reasons within the first month. Start the clock at receipt, not when the request reaches the right team. Confirm how your ticketing system timestamps requests that arrive through a parent, a school or a support form.
Implementation gaps flagged by the EDPB
In February 2026 the EDPB published observations on the challenges that hinder full implementation of the right to erasure. Read them as a checklist of where controllers commonly fall short, including finding data across systems and confirming deletion at third parties. Use the EDPB's points to test your own process against a realistic regulator view. Ask your team which of these gaps your current runbook already closes.
Backups and restore paths
Deleted records often survive in backup sets that are restored later, which can bring erased children's data back into production. Decide how long backups keep personal data, whether erased identifiers are excluded at restore, and how the restore runbook re-applies pending erasures. Confirm with the platform team that restores are tested against an erasure list, not only against integrity checks.
Logs, analytics and search copies
Application logs, event streams, search indexes and analytics warehouses frequently copy user identifiers and activity. Map which of these hold a child's identifiers, set retention on each, and decide whether identifiers are pseudonymised before they are written. Erasure has to reach these copies, or the log retention itself must be short enough that no residual copy outlives the request. Confirm both approaches with the team before relying on either.
Processor and sub-processor propagation
When a vendor such as an email, analytics or hosting provider holds a child's data for your service, the erasure has to be passed on to them. Your processor contract should set how erasure instructions are sent, how quickly they must be actioned and how confirmation returns to you. Ask each processor how it handles erasure in backups and sub-processor chains, and keep the answers in your records.
Who owns the controls and who prepares the evidence
The organization that offers the service to children is the controller, and it stays accountable for every decision about why and how children's data is processed. Product, legal, the data protection officer and engineering each hold part of that accountability, and none of them can hand it to a vendor. The operator decides the age threshold it relies on, the wording of child-adapted notices, the lawful basis for each feature and the retention periods for learner records.
- Product owners decide which features collect data from children and whether a feature needs a parental consent path at all.
- Legal sets the national age of digital consent for each market where the service is offered and approves the notice wording.
- The data protection officer reviews DPIA outcomes for vulnerable data subjects and records whether a DPO designation is required.
- Engineering leads own the production configuration, the consent records and the erasure workflow, and they sign off on test results.
- Management accepts residual risk and funds the reviews that keep the evidence current.
Before any outside party starts work, confirm in writing which named person signs each control decision and where each decision is recorded.
An implementation partner such as DeployOpen works inside the operator's own cloud accounts, data centers or air-gapped networks to build the technical side of the controls. Its scope covers system configuration, the consent flow build, erasure tooling and evidence packs, all of which the operator then reviews and adopts. The partner does not decide the lawful basis, set the age threshold or accept risk on the operator's behalf.
- System configuration covers access controls, logging, retention jobs and encryption settings on self-hosted open-source platforms.
- Consent flow build covers age gates, parental authorization steps and the stored record that shows consent was given.
- Erasure tooling covers the mechanisms that find and delete learner data across databases, backups and connected services.
- Evidence packs collect configuration exports, test results, access reviews and change records in a form the operator's assessor can read.
- Handover documentation explains how each control runs, who operates it and how it is tested after go-live.
Ask the partner to state in the written scope which deliverables are configuration, which are documentation and which, if any, depend on a decision the operator must still make.
No body can certify GDPR compliance for a service. Supervisory authorities enforce the regulation, and their investigations can examine consent records, age checks, DPIAs and erasure handling after a complaint or breach. Article 42 certification exists, but it is voluntary, issued for at most three years by accredited certification bodies or supervisory authorities, and it does not reduce the controller's responsibility. An independent auditor may test controls against a chosen framework, but that report is not a GDPR certificate.
- Supervisory authorities receive complaints, investigate and can impose the fines set out in Article 83.
- Certification bodies may issue Article 42 certificates where a scheme exists and the body is accredited.
- Independent auditors test controls and issue their own reports, which the operator must not present as regulator approval.
- Implementation partners do not issue reports, attestations or certificates, and their evidence packs are inputs to the assessor's work.
- Customers and schools may request evidence under their own contracts without making the operator's compliance an official finding.
Before engaging any assessor, confirm whether it is accredited for the scheme you need, and ask the regulator's guidance for your country if the children's service crosses borders.
What delays children's data projects
Most delays in children's data and edtech projects come from decisions made late or assumed too early: which country's age rule applies, how consent is recorded, where erasure stops, and when privacy assessment begins. Each card names one of these points and the check that prevents it.
Wrong national age applied
Article 8 lets Member States set the age of digital consent anywhere from 13 to 16, so a single platform serving several countries can face several thresholds. Teams often configure one age for the whole product and discover the mismatch during a pilot or a complaint. Map the market mix by country of each user before the sign-up flow is designed, then set age gates per market and record which rule each account was checked against. Confirm the current national age with the relevant supervisory authority or national legal advice rather than relying on a memory of the rule.
Consent that cannot prove who agreed
Where processing relies on consent, the controller must be able to demonstrate that the data subject consented, and for a child that means showing that a parent or guardian authorised it. A checkbox that a child can tick without any adult involvement fails this test. Build the consent flow so that it stores the consent event, the verification method used, the identity of the adult, and the version of the notice shown. Ask vendors what evidence their parental consent tool keeps, and test that the record survives account transfer and deletion requests.
Erasure paths that skip backups and processors
Article 17(1) requires erasure without undue delay when data was collected from a child for information society services, and that duty reaches copies held elsewhere. Schools and edtech vendors often delete the live account while logs, analytics exports, backups and subprocessor stores keep the data. Map every location where a learner's data is written, including learning tools, messaging and analytics, and define how each one is erased or expired. Test the full path with a sample learner account before go-live and document the result.
DPIA started after launch
WP248 rev.01 lists vulnerable data subjects as a criterion, and children are a typical case, so processing that combines children's data with another criterion such as systematic monitoring or profiling will in most cases need a DPIA. Teams that launch first and assess later must redesign features under pressure or pause rollouts. Start the assessment during product discovery, record the decisions on data minimisation and profiling, and schedule a review when the feature set or the market changes. Ask the DPO or privacy lead to sign off before the build freezes.
Schools signing without processor terms
When a school or trust uses an edtech product, the school is usually the controller and the vendor a processor, and Article 28 requires a written contract setting out instructions, security, subprocessors and deletion at the end of the service. Procurement teams that sign click-through terms or a generic licence leave the data flows undocumented. Before onboarding, confirm that the agreement covers the processing purposes, the subprocessor list, breach notice timing, return or deletion of pupil data, and the locations where data is hosted. Ask for the vendor's standard data processing terms early so legal review does not become the critical path.
Unclear hosting and access locations
Edtech tools often route learner data through support desks, analytics services or tools hosted outside the EEA, which creates transfers the school never reviewed. Teams that discover this after a contract is signed face re-papering and sometimes a change of vendor. Ask each vendor and subprocessor where data is stored and from which countries support staff can access it, then record the answer in the processing register. Confirm the transfer basis for any non-EEA access before pilot users are added.
Questions edtech teams ask about children's GDPR compliance
Is there a fixed cost for GDPR compliance work on a children's edtech platform?
No fixed price applies. DeployOpen does not publish a price list, and the cost follows from a written scope that lists the services, the platforms involved and the markets where the product is offered. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Cost drivers include the number of systems that collect child data, whether age assurance and parental consent flows need to be built or changed, how many Member States apply a different age of digital consent, and whether a DPIA is needed for the product. Ask for a quote that lists each deliverable separately, and note which items are one-time setup and which are recurring support or testing.
How long does children's GDPR work take on an edtech product?
Duration depends on the services in scope and the number of markets, so confirm the timeline with the partner against your written scope. The main variables are how many platforms, integrations and third-party tools handle pupil or student data, whether the parental consent flow exists or must be rebuilt, and how much information must be adapted for younger users. Erasure logic for data collected from children, DPIA work and review of processor contracts each add time. Ask the partner to break the timeline into phases with named deliverables, and ask which parts depend on your staff, such as legal sign-off or access to test environments.
Can our team handle children's GDPR compliance without an outside partner?
Yes, the GDPR does not require an outside partner, and an internal team can do the work if it has the legal, product and security skills involved. The controller always owns its compliance decisions, including the lawful basis, the age thresholds applied in each country and the retention rules. An implementation partner can prepare systems, configuration and evidence, such as access logs, deletion workflows and consent records, but it does not replace the controller's responsibility. Teams often bring in outside help for technical work on self-hosted platforms, while keeping legal interpretation in-house or with counsel.
Do we need a GDPR certificate to show that our edtech platform complies?
No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. What regulators look for is evidence: documented age checks, parental consent records that the controller can demonstrate under Article 7(1), child-adapted privacy information, erasure records and a DPIA where the processing triggers one. If a customer or school contract asks for a certificate, confirm exactly which document or assessment it means, because DeployOpen prepares systems and evidence but does not issue reports or certificates.
What does our team need to provide before compliance work starts?
The partner needs enough access and information to see how child data moves through your product. Prepare a list of services and databases that store user or pupil data, the sign-up and login flows, the current parental consent process, your data retention rules, and the processors and sub-processors you use. Access to staging environments, configuration of identity and logging systems, and a named technical contact help the work move quickly. Your legal or DPO function should confirm the target markets and the age of digital consent that applies in each one, since the GDPR allows Member States to set a lower age between 13 and 16.
How could the Omnibus proposals change GDPR obligations for children's data?
As of October 2026 the GDPR text has not been amended, so current obligations for children's data still apply. Two proposals are in progress: the Omnibus IV proposal (COM(2025) 501, procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 and awaits Parliament's first-reading vote, and the Digital Omnibus proposal (COM(2025) 837, procedure 2025/0360(COD)) awaits a committee decision. Track both in the European Parliament Legislative Observatory). Build consent, age-check and erasure controls so they can be adjusted through configuration, and ask your legal team to review any change before it affects your product.
Which parts of children's GDPR work can we outsource, and which must stay with us?
Technical preparation is the part most often outsourced. An implementation partner can configure self-hosted open-source platforms inside your own cloud or data center, add logging and access controls, build erasure workflows for data collected from children, and document the evidence that shows how those controls work. The controller keeps ownership of the lawful basis, the decision to rely on parental consent, the choice of retention periods and the DPIA conclusions. Make the split explicit in the written scope so that each deliverable has a named owner on both sides.
How DeployOpen prepares children's data systems and evidence
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so age gating, parental consent records, erasure workflows and DPIA inputs can be built and evidenced in the environment where children's data actually sits. We prepare the systems and evidence; the controller owns the decisions and any independent assessment is carried out by others.
How we scope
- Written scope agreed before work starts, listing the child-facing services, age groups and national age thresholds in use
- Mapping of which personal data is collected from children and which processing relies on parental consent
- Confirmation of which decisions remain with your legal and privacy team, such as the lawful basis and the chosen national age
How we build
- Configuring consent capture and parental authorization flows in the self-hosted platform, with records that can show who consented and when
- Setting up erasure workflows for data collected from children, including deletion across databases, logs and backups
- Testing the platform's access controls, logging and data flows against the DPIA risks identified for vulnerable data subjects
How we hand over
- Documentation of configuration, consent records, retention settings and erasure procedures for your compliance and privacy teams
- Evidence packs showing how each safeguard operates, ready for an independent auditor or supervisory authority to review
- Runbooks for operating the platform after handover, so your staff can run age checks, consent audits and erasure requests
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Periodic review of consent flows and erasure workflows when national age rules or guidance change
- Security testing of child-facing applications and APIs, delivered as a separate scoped engagement
Sources and further reading
- Regulation (EU) 2016/679 (GDPR), EUR-Lex ↗
- EDPB data protection guide for small business: Process personal data lawfully ↗
- EDPB-EDPS Joint Opinion 2/2026 on the Digital Omnibus proposal ↗
- Article 29 Working Party: Guidelines on DPIA (WP248 rev.01) ↗
- EDPB Guidelines 05/2020 on consent under Regulation 2016/679 ↗
