Acceptable Use Policy Generator for edtech
Written for student data, children’s privacy, school contracts and age-appropriate design.
An acceptable use policy in education has to be readable by the people it governs, which frequently includes children. It also has to give teachers and administrators something they can enforce consistently across a class.
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 acceptable use policy for an education or edtech business has to cover
Conduct rules written in language the youngest intended user can understand
Account sharing, impersonation and misuse of another pupil’s login
What happens to work that breaches the rules, and who decides
Reporting routes for pupils, parents and staff, with response expectations
How enforcement is escalated to the school rather than handled unilaterally
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 acceptable use policy contains
Prohibited content and conduct
The categories you will not host, written specifically enough to enforce and narrowly enough to defend.
Technical restrictions
Rate limits, scraping, load testing, resource abuse and circumvention of quotas.
Security research boundaries
What testing is permitted, how to report a finding, and what will not be treated as an attack.
Reporting and moderation
How abuse is reported, what happens next, and the timescales you work to.
Enforcement ladder
Warning, throttle, suspension, termination - with the emergency route for genuinely urgent harm.
Appeals
How someone contests a decision, which several online-safety regimes now require rather than merely encourage.
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.
Do I need an acceptable use policy separate from my terms?
A separate AUP is easier to enforce and easier to update. It also gives moderation staff and automated systems a single reference to cite, which matters when a suspension is challenged.
Does an AUP help with platform liability?
It is part of the picture. Intermediary liability protections generally depend on acting on notice, and both the EU Digital Services Act and the UK Online Safety Act expect published rules, a reporting route and an appeals process.
How specific should prohibited-use lists be?
Specific enough that a moderator can apply it consistently, with a residual catch-all. Lists that are only catch-alls get challenged; lists that are only specific leave gaps.
Acceptable Use Policy Generator for edtech
Answer a short questionnaire and get a draft written for an education or edtech business. Free to start, no card required.
Generate your acceptable use policyOther documents an education or edtech business needs
Each one is written for the same context, not a generic template.
The same document, by business type
Go deeper
PolicifyAI is a technology provider, not a law firm, and this page is not legal advice. Generated documents are a structured starting point that a qualified adviser should review before you publish or rely on them.