COPPA, PPRA and who consents for a nine year old

This describes how these rules shape product decisions. It isn't legal advice.

A nine year old can't agree to a privacy policy. Everything about consent in K-12 follows from that, and the arrangements the law makes instead are narrower than most product teams assume.

COPPA and the school exception

The Children's Online Privacy Protection Act and its implementing Rule (16 CFR Part 312) govern collection of personal information from children under 13 by operators of online services directed to children, or who have actual knowledge they're collecting from them.

The default requirement is verifiable parental consent, obtained before collection. Obviously no district gathers signed forms from every parent before enabling software.

What resolves this is school-authorised consent. The FTC has long taken the position that a school may provide consent on behalf of parents where the service is used for a school-authorised educational purpose, and the 2025 amendments put that on firmer footing while attaching conditions.

The boundaries are the part worth internalising, because they're narrow:

• It covers the educational purpose only. It isn't general consent to process a child's data however your terms allow.
• It does not extend to commercial purposes. No behavioural advertising, no profiles for anything other than the educational service, no selling or sharing for another party's purposes.
• The school is relying on your description of what you do. If your actual processing exceeds what you told them, their consent doesn't cover it.

What the 2025 amendments changed

Finalised in January 2025, published that April, effective from June 2025, with full compliance required by 22 April 2026. Four changes have direct engineering consequences.

A written children's information security programme. Not a paragraph. A documented programme with a designated responsible person, risk assessments and safeguards. If you have SOC 2 work in flight most of this exists; the specific requirement is that it addresses children's data and is written down.

A published data retention policy. Publicly available, stating what you retain and for how long. Your privacy page has to carry it.

No indefinite retention. Children's personal information may be kept only as long as reasonably necessary for the purpose it was collected for. "We keep everything forever in case it's useful" is now a finding rather than a design choice. Which means a deletion job that actually runs, on a schedule, with evidence: the same job FERPA for engineers asks for, now with a second statutory reason to exist.

Separate consent for third-party disclosure. Consent to your service isn't consent to pass a child's data to third parties for their own purposes. Disclosure for targeted advertising needs its own consent, which in a school context you simply won't get, so the practical answer is not to do it.

The definition of personal information also expanded to include biometric identifiers. If you do voice capture for reading fluency, face detection for proctoring or engagement, or anything similar, that data is squarely in scope now.

Age gates don't work here, and shouldn't

The instinct from consumer products is an age gate. In K-12 it's both useless and counterproductive.

Useless, because you already know. The district gave you a roster with grade levels on it. A second grader is under 13, and you have that from the system of record. Asking the child produces worse data than what you already hold.

Counterproductive, because a self-declared age the child gets wrong doesn't protect you. The standard turns on actual knowledge, and a roster stating grade 2 is actual knowledge.

The workable design: derive the protection level from the roster's grade level, apply the strictest applicable treatment when it's unknown, and make the treatment a property of the account rather than a question in a flow.

PPRA: the one that catches wellbeing features

The Protection of Pupil Rights Amendment (20 U.S.C. 1232h) is much less discussed than FERPA and catches teams building anything survey-shaped.

PPRA governs surveys, analyses and evaluations revealing information in any of eight protected areas:

1. Political affiliations or beliefs of the student or their parent
2. Mental or psychological problems of the student or their family
3. Sex behaviour or attitudes
4. Illegal, anti-social, self-incriminating or demeaning behaviour
5. Critical appraisals of others with whom the student has a close family relationship
6. Legally recognised privileged relationships, such as with lawyers, physicians or ministers
7. Religious practices, affiliations or beliefs
8. Income, other than as required to determine programme eligibility

Where such a survey is funded by the US Department of Education, prior written parental consent is required. Otherwise districts must notify parents and offer the right to opt out.

Here's why this matters to product teams. Social-emotional learning check-ins, wellbeing pulse surveys, "how are you feeling today" widgets, self-reported behaviour questions, and reflection prompts asking about home life can all land in area 2 or area 5 without anyone intending it. A feature designed as pastoral care is, legally, a survey.

What to build:

Flag instruments at item level, not feature level. One question in a twenty-question reflection can bring an instrument into scope, and the district needs to know which one.

Make the opt-out suppress the item, not hide the result. If a parent opted out, the child shouldn't be asked. Presenting the question and discarding the answer isn't an opt-out.

Give the district visibility of the instrument. They have to notify parents what's being asked. They can't do that if the questions live only in your codebase.

Open text from students

Not COPPA or PPRA, but it arrives in the same review and appears in more district RFPs than teams expect.

If students can type freely, in a reflection, a chat, an answer box, some of them will eventually write something indicating harm. Self-harm, abuse, a threat. At any meaningful scale that isn't hypothetical, it's a certainty.

Districts will ask what happens then. The answer they need is a defined escalation path to a named human at the district, with a stated response time. Not a support queue and not a nightly report.

Some districts run their own monitoring across everything on their network. Some expect the vendor to escalate. Ask which, build the hook, document it.

Getting this wrong is worse than a compliance failure.

The checklist

• Protection level derives from roster grade level, not from asking the child.
• No behavioural advertising. No profile building outside the educational purpose.
• A written children's data security programme exists.
• A retention policy is published, and a deletion job enforces it on a schedule.
• Nothing is retained indefinitely, and there is evidence of expiry.
• Third-party disclosures are enumerated, minimal, and never for the third party's own purposes.
• Voice and face capture are identified and treated as personal information.
• Survey-shaped features are reviewed against the eight PPRA areas at item level.
• Open text has a defined escalation path to a named person at the district.