By business type

Privacy Policy Generator for edtech

Written for student data, children’s privacy, school contracts and age-appropriate design.

Generate your privacy policy Read the privacy policy guide

An edtech privacy policy usually needs to be two documents: one for schools explaining your processor role, and one written so a parent or an older pupil can understand it. The design code expects child-facing transparency, not a legal notice pointed at adults.

Education technology processes data about children, which changes almost every default. COPPA applies to under-13s in the US, the UK Age Appropriate Design Code applies to services likely to be accessed by under-18s, several EU member states set the digital age of consent at 16, and India’s DPDP Act treats everyone under 18 as a child.

The school relationship adds a second complication. When a school buys your product, the school is usually the controller and you are the processor - which means consent for your processing comes from the school on the pupils’ behalf, and your ability to use the data for product improvement or marketing is sharply limited.

FERPA in the US layers on top for education records held by institutions receiving federal funding, and the school official exception that vendors rely on comes with conditions about direct control and limited use.

What a privacy policy for an education or edtech business has to cover

Your role per deployment model, with the school as controller where that applies
Categories of pupil data, including assessment and behavioural analytics
Age thresholds per market and the parental consent mechanism
A clear statement on advertising - ideally that there is none
Deletion at the end of a school contract, with the window stated

How an education or edtech business actually moves personal data

Pupil accounts and rosters

Names, year groups, class assignments and sometimes identifiers issued by the school, usually synced from a school information system.

Learning and assessment data

Progress, scores and behavioural analytics, which can constitute profiling of children.

Parent and guardian records

Contact details and consent records, held under a different relationship from the pupil data.

Teacher and staff accounts

Employment-adjacent processing with the school as employer.

Product analytics inside a children’s service

Ordinary telemetry becomes a design-code question when the user is a child.

Safeguarding disclosures

Where the product surfaces a welfare concern, the disclosure route and its basis need defining in advance.

Third parties the draft will ask you about

Google Workspace for Education or Microsoft 365 Education · AWS or Azure · Wonde or Clever for roster sync · Stripe · Zendesk · Sentry

The rules that apply

COPPA

Verifiable parental consent before collecting personal information from under-13s, with restrictions on behavioural advertising and disclosure.

Age Appropriate Design Code

Fifteen standards including data minimisation, high-privacy defaults, no nudge techniques and detrimental use restrictions, for services likely to be accessed by children.

FERPA and the school official exception

Education records may be shared with vendors performing an institutional service, under the institution’s direct control and for limited purposes.

School as controller

For most classroom deployments the institution determines purposes and means, making the vendor a processor with instruction-limited rights.

Digital age of consent variation

From 13 to 16 across the EU, 13 under COPPA, and 18 in India - which makes a single global age gate impossible.

What the generated privacy policy contains

Identity and contact details of the controller
Your legal entity, trading name, registered address and a working contact route - plus a representative or DPO where one is required.
Categories of personal data and their sources
What you collect directly, what you observe automatically, and what you receive from third parties such as payment providers or ad platforms.
Purposes and lawful basis, purpose by purpose
A table that pairs each processing purpose with its lawful basis rather than listing all six bases and hoping one fits.
Recipients and sub-processors
The categories of recipient, and for the ones that matter to users - payment, hosting, analytics, support - the named provider.
International transfers and their safeguards
Where data leaves its home jurisdiction, and the mechanism relied on: adequacy, standard contractual clauses, the UK addendum or IDTA.
Retention periods per data category
Concrete periods or the criteria used to set them, which is what regulators ask for first when a complaint lands.
Rights and how to exercise them
Access, rectification, erasure, portability, objection and restriction, with the actual route to make a request and the deadline you work to.
Complaints and supervisory authority
The regulator a user can escalate to, named, with a link - not a generic "your local authority".

Edtech compliance essentials

Decide your role per deployment
School-purchased is usually processor; direct-to-consumer is controller. The documents differ completely.
Complete a DPIA before launch
Children’s data at scale requires one in the UK and EU.
Build a market-aware age gate
With verifiable parental consent flows for the thresholds that apply.
Turn off behavioural advertising entirely
It is the simplest defensible position for a children’s product.
Set high-privacy defaults
The design code requires them, and defaults are what regulators test first.
Document deletion at contract end
With a defined window and evidence you can produce.

Where this usually goes wrong

Using pupil data for product improvement without instruction

As a processor you act on the school’s instructions. Product analytics on pupil data needs to be authorised, not assumed.

Behavioural advertising in a children’s service

Prohibited or heavily restricted under COPPA, the design code and India’s DPDP Act.

One global age gate

The threshold varies from 13 to 18 by market, so a single number is wrong somewhere.

Nudge techniques and engagement mechanics

The design code specifically targets techniques that encourage children to weaken their privacy settings or stay engaged longer.

No data protection impact assessment

Processing children’s data at scale is on every regulator’s mandatory DPIA list.

Retaining pupil records after a contract ends

Article 28 requires deletion or return, and school contracts usually specify a window.

Frequently asked questions

Is my edtech company a controller or a processor?

For school deployments, usually a processor acting on the institution’s instructions. For direct-to-consumer products, a controller. Many companies are both, and the documents have to distinguish them.

What age counts as a child?

It varies: 13 under COPPA, 13 to 16 across EU member states, 16 in Ireland, and 18 under India’s DPDP Act and for parts of the UK design code. A single global threshold will be wrong in some markets.

Can I show ads in a children’s education product?

Behavioural advertising is restricted or prohibited under COPPA, the Age Appropriate Design Code and the DPDP Act. The defensible position is not to run it at all.

Do I need a DPIA?

For processing children’s data at scale, yes - it appears on the mandatory list published by UK and EU regulators.

Is a privacy policy legally required?

If you process personal data, in almost every market yes. GDPR and UK GDPR require the disclosure at the point of collection, CCPA/CPRA requires a notice at collection plus an annually reviewed policy, and app stores and payment processors require a public policy URL before they will list or onboard you.

Can I copy another company’s privacy policy?

It is both a copyright problem and a compliance problem. A copied policy describes someone else’s data flows, processors and retention periods, so it is inaccurate the moment you publish it - and an inaccurate transparency notice is itself a breach of GDPR Article 13.

How often does a privacy policy need updating?

Whenever your processing changes - a new analytics tool, a new payment provider, a new market - and as a backstop, review it annually. CPRA makes the twelve-month review explicit.

Does PolicifyAI give legal advice?

No. PolicifyAI is a technology provider, not a law firm. The output is a structured, jurisdiction-aware draft that a qualified adviser should review before you rely on it.