Why this exists
A student ships an attendance app the robotics team actually uses. A teacher builds a feedback tool and three colleagues want it. Congratulations — you now have users, and the moment your tool touches other people's information, you've walked into territory with real rules.
The good news, and the honest framing for this whole manual: these laws are easier to design around than to comply with. Most of them only switch on when you collect personal information — so the tool that collects nothing, or nearly nothing, sails past most of this page. That's not a loophole; it's exactly the behavior the laws exist to encourage. Data you never collect can't leak, can't be subpoenaed, can't be mishandled, and can't generate a five-figure fine.
This manual is orientation, written by a teacher-developer so you know the terrain and ask the right questions. It is not legal advice, and laws change. For a real decision — launching a product, signing a school contract, anything with stakes — talk to your school's administration or an actual attorney.
The 60-second map
Five names cover almost everything you'll hear in a school IT meeting. Here's who each one protects, who it binds, and when it touches a builder like you.
| Law | Protects | Binds | Touches you when… |
|---|---|---|---|
| COPPA (US, 1998) | Children under 13 online | Operators of websites & apps | Your app collects personal info from kids under 13 |
| FERPA (US, 1974) | Students' education records | Schools — and vendors they share with | Your tool touches grades, rosters, or anything from a school's records |
| GDPR (EU, 2018) | Everyone in the EU/UK | Anyone offering them services | You deliberately serve users in Europe |
| State student-privacy laws (SOPIPA & cousins) | K-12 students | Ed-tech services of any size | Your app is designed and marketed for K-12 use |
| CIPA (US, 2000) | Kids on school networks | Schools & libraries with federal E-Rate funding | It doesn't bind you — but it's why your app might be blocked at school |
Notice the pattern: COPPA cares about age, FERPA cares about where the data came from, GDPR cares about where the user is, and the state laws care about the school context. One app can trigger all four — or, designed carefully, none.
What counts as "personal information"
Every law on this page hinges on this definition, and it's broader than most builders expect. It's not just names and emails.
- The obvious: name, email, phone number, address, photos, video, voice recordings.
- The less obvious: persistent identifiers — device IDs, account usernames, and in some laws IP addresses and cookies that can track a person over time.
- The school-flavored: grades, attendance, behavior notes, IEP status, student ID numbers — anything from an education record.
- The combination problem: "an 11th grader at Jefferson High who runs the robotics club" identifies one kid as surely as a name does. Data that's harmless alone can be identifying together.
Before adding any field, ask: "Could someone use what my app stores to point at a specific person?" If yes, it's personal information — treat it like it's radioactive: handle as little as possible, for as short a time as possible, with a plan for getting rid of it.
COPPA — the under-13 law
Children's Online Privacy Protection Act
US federal · FTC enforcesCOPPA binds "operators" of websites and online services that are directed to children under 13, or that have actual knowledge they're collecting personal information from kids under 13. If it applies, you need a clear privacy notice and verifiable parental consent before collecting — plus data minimization, retention limits, and real security. Recent updates to the rule tightened all of this, especially around sharing data with third parties and how long you can keep it.
The part that surprises builders: being 16 yourself doesn't exempt your app. COPPA looks at your users' ages, not yours. A middle-school study tool with a signup form is a COPPA conversation even when its developer is in high school. (The FTC pursues companies, not kids learning to code — but a tool that gets real adoption gets real obligations.)
How to design around it: in order of preference — (1) collect nothing: no accounts, no names, nothing stored about the user; (2) build for 13+ and say so honestly, with an age screen that doesn't wink at kids to lie; (3) if under-13 users are genuinely the point, the serious paths are school-mediated consent (the school authorizes it for classroom use) or a real parental-consent flow — at which point you should also be reading section 09 and talking to an adult who signs things.
FERPA — the school-records law
Family Educational Rights & Privacy Act
US federal · Dept. of Education enforcesFERPA gives parents (and students once they turn 18) the right to see their education records and to control their disclosure. It binds schools that take federal funds — meaning nearly all of them — and it reaches tools and vendors indirectly: a school may only share student records with an outside service under specific exceptions, most commonly the "school official" exception, which requires the school to keep direct control over how the data is used. That's why schools make vendors sign data-privacy agreements instead of taking their word for it.
The trap for teachers: you handle education records all day, so the risky move is casual, not malicious — pasting a gradebook export into a consumer AI chatbot, uploading a roster to an unvetted web tool, or wiring your homemade app straight into the SIS. Each of those can be a disclosure of education records that nobody authorized. The school carries the FERPA liability; you carry the awkward meeting.
The compliant pattern (and the one we teach): build and test with sample data — fake names, fake grades, realistic shapes. Get the tool working and demonstrably safe first. Then, if it needs real student data to be useful, take it through your school's approval process (section 09) so the data flows under the school's authority rather than around it.
GDPR — the European one
General Data Protection Regulation
European Union · UK runs a near-twinGDPR is the world's most influential privacy law. It defines personal data broadly (IP addresses count), requires a lawful basis for any processing, and grants users rights your app has to actually honor: see their data, correct it, delete it, take it elsewhere. For children using online services, parental consent is required below an age each member state sets between 13 and 16 (the UK chose 13).
The honest scope question: GDPR applies if you're established in Europe or you target people there — pricing in euros, marketing to EU schools, that kind of deliberate aim. A classroom tool built for your school in the US, that happens to be reachable from Berlin because the internet exists, is generally not what the territorial rules are aimed at. Don't lose sleep; don't pretend it can never matter either — "we got popular in Europe" is a nice problem that comes with homework.
Why it's still worth reading: GDPR's habits are simply good engineering — collect the minimum, say plainly what you collect, delete on request, secure what you keep. Build those in from the start and you're most of the way to every other law on this page. They're the same habits behind our own privacy policy.
State laws — the SOPIPA wave
Since 2014, US states have passed well over a hundred student-privacy laws. You don't need to know them individually — you need to know the template they share, because it started in California and spread.
- SOPIPA (California's Student Online Personal Information Protection Act) set the pattern: if your online service is designed and marketed for K-12 use, you may not show students targeted ads, build non-educational profiles of them, or sell their data — and you must protect what you hold and delete it when the school or district asks. Crucially, there's no small-company exemption: it applies to a two-person app the same as a giant. Dozens of states adopted close copies.
- New York's Ed Law 2-d is the strict end of the spectrum: vendors handling student data from NY schools sign specific contract terms, post a parents' bill of rights, and meet defined security standards. If you sell to NY districts, you'll meet it by name.
- CCPA/CPRA (California's general privacy law) mostly binds larger businesses, but its minor-specific rule is worth knowing: personal information of consumers under 16 can't be sold or shared without opt-in consent — the minor's own consent at 13–15, a parent's below 13.
- CIPA isn't about your data at all — it requires schools and libraries taking federal E-Rate funding to filter their networks. It's in this manual because it answers a question every student builder eventually asks: "why is my app blocked at school?" Often: because the filter hasn't categorized your brand-new domain yet. The fix is asking IT to allowlist it, which goes better if you can answer the questions in section 09.
Every state law in the wave bans roughly the same three things: ads targeted at students, profiles built on students, and selling student data. If your tool does none of those — and a classroom tool never should — state law compliance is mostly about security basics and being able to delete data on request.
The builder's checklist
Privacy by design, in the order that actually saves you work. This is the checklist we run student and teacher builds through in the cohorts.
- Start from zero collection. The first version of almost any tool can store nothing personal: a flashcard app that keeps decks in the browser's local storage, a simulator with no accounts at all. Ship that first. Add collection only when a feature truly requires it.
- When you must have accounts, collect one thing. An email address, or a school sign-on (Google/Microsoft SSO) — not a birthday, not a phone number, not a "tell us about yourself." Every field you skip is a law you may never trigger.
- Age-gate honestly. If your app is built for 13+, ask, and don't design the question to be gamed. If under-13 users are the point, read section 04 again and bring an adult.
- Use fake data while you build. Generate sample rosters and grades — AI assistants are great at producing realistic fake data. Real names never belong in a dev database, a prompt, a screenshot, or a public repo.
- Write the tiny privacy policy. One honest page: what you collect, why, where it's stored, who else touches it (your host, your database), and how to get it deleted. If you collect almost nothing, it's three paragraphs — and it's the single document that makes parents, teachers, and IT directors trust you. Ours is a worked example of the genre.
- Be able to delete. Before launch, know exactly how you'd remove one user's data if asked. If the answer is "uh," fix that — under several of these laws, "uh" is not a permitted response.
- Lock the basics. HTTPS everywhere, secrets out of the repo, authentication on anything that shows personal data, and no PII in your logs. The hosting manual covers the how.
- Don't ship other people's information. No classmates' names in the demo, no photos without asking, no scraping the school directory "because it was right there."
For teachers: getting a tool approved at school
You built something useful and now you want it in front of real students. There's a front door, and tools that go through it live a long time. Tools that go around it get found during the next audit.
PLAYBOOK From side project to approved tool
Build v1 so it needs zero student data — sample data, or content the teacher supplies. Let the school see it working safely, then have the conversation about connecting real data. You'll be asking for trust you've already demonstrated, and half the time you'll discover the zero-data version was all you needed.
Where this fits
The three build manuals take you from idea to live URL: pick a platform, graduate to an editor and agent, ship it properly. This manual is the one you pull off the shelf the day your shipped thing meets real users — which, if the others worked, is soon.
For how we practice this ourselves, the studio's privacy policy and terms of service are written as worked examples of the same plain-English approach. And if you're a cohort family or teacher with a question this page doesn't answer, that's what hello@secondbellstudio.com is for.
Collect as little as possible, be honest about what you collect, be able to delete it, and walk through the school's front door — do those four things and the alphabet soup mostly takes care of itself.