Verifiable parental consent, and when the school can give it instead

Verifiable parental consent is consent obtained through a method reasonably calculated, given available technology, to establish that the person giving it is the child's parent. The word doing the work is verifiable: a tick box saying 'I am over 13' or 'I am this child's parent' is not a method, and never has been.

The rule this sits in is the FTC's Children's Online Privacy Protection Rule, which has been amended more than once. Treat any description of its accepted methods, including this one, as dated context to check against the current rule text before you rely on it. This is an engineering reading, not legal advice, and BuildspaceLabs holds no privacy or security certifications.

What 'verifiable' is doing in the phrase

The regulator does not prescribe one mechanism. It recognises families of methods whose common property is that a child would struggle to complete them alone, and it expects the method to be proportionate to what you collect.

• Payment-instrument methods. A transaction that notifies the account holder, rather than a card number merely typed into a form.
• Signed-form methods. A consent form returned by post, fax, or scan, or signed electronically in a way that captures who signed.
• Identity-check methods. Government-issued identification checked against a database and then deleted, or a video call with trained personnel.
• Staffed-channel methods. A call or message to trained personnel, so a human is judging whether the person is plausibly the parent.
• Knowledge-based challenge. Questions difficult for a child to answer, used where the collection is limited.

Pick the method by what you collect, not by conversion rate. A free-text assistant that stores a child's own words is not in the same risk class as a spelling game storing a first name and a score.

When the school can consent instead, and the three limits

For services used in the classroom at a school's direction, the school may provide consent on parents' behalf. That path is narrower than most product teams assume, and all three limits are architectural.

1. Educational purpose only. The consent covers use for the school's educational function and nothing adjacent, so a feature serving your business rather than the classroom falls outside it.
2. No commercial use of the data. Behavioural advertising, profiling for anything other than the service, and sale of the data are all outside what a school can authorise.
3. The school must be able to inform parents. It can only stand in for them if it knows what is collected and why, which means you owe it a plain-language description accurate at the current release, not at signature.

The consent record, field by field

Consent that cannot be produced on request did not happen, as far as a district review is concerned. Six fields make it producible.

Scope is the field that rots

Every consent is scoped to what the product did on the day it was captured. Ship a wellbeing check-in, an on-device credential of the kind discussed in putting a student ID on a phone, or transcript retention as described in a records request that returned chat transcripts, and consent captured in September no longer covers what the product does in March.

So version the scope, keep the disclosure text that was shown alongside the record, and make revocation a first-class path that stops collection and reaches stored data. Who may read the consent record is its own access question, of the kind that drifts at term boundaries — see staff who can see students outside their caseload. We build this ledger as ordinary admin plumbing in internal tools and ops work, under student data privacy, engineered, inside our education and edtech work.

• COPPA
• consent
• K-12
• privacy engineering