By Mehdi HassanWhen a school district evaluates an edtech product, the website is often the first compliance document it reads. Procurement teams look for how you handle student data, whether children's privacy is covered, and whether the product is accessible, and a vague privacy footer link rarely passes. This checklist covers the rules that shape an edtech website and gives you a trust page template built for district procurement. It's part of our edtech website design guide.
What edtech website compliance rules apply in the US?
The main edtech website compliance rules in the US are FERPA for student education records, COPPA for children under 13, state student data privacy laws, and accessibility requirements that usually reference WCAG. Which ones apply depends on who uses your product and who buys it.
Rule | What it covers | Website impact |
|---|---|---|
FERPA | Privacy of student education records held by schools | Explain how you handle records on the school's behalf; data terms for districts |
COPPA | Online collection of personal information from children under 13 | Sign-up, forms, consent and tracking on child-directed pages |
State student privacy laws | Limits on how edtech vendors use student data (for example, California's SOPIPA) | Commitments on no targeted advertising and data use; state-specific agreements |
Accessibility (ADA, Section 508, WCAG) | Equal access for people with disabilities | Accessible site and product; accessibility statement and conformance report |
EU and UK rules (GDPR, EAA) | Personal data and accessibility for European users | Privacy notices, lawful basis, accessibility for consumer services |
How does FERPA affect an edtech website?
FERPA affects an edtech website mostly through what you promise and document, not through a FERPA badge. FERPA protects education records held by schools. Vendors commonly receive student data under the school official exception, which generally requires that the school keeps direct control over the data and that the vendor uses it only for the purposes the school authorized.
On your site, that means explaining in plain language that you process student data on behalf of schools, use it only to provide the service, don't sell it or use it for advertising, and delete or return it when the contract ends. Back this up with a data processing agreement districts can review. Avoid phrases like 'FERPA certified': there is no official FERPA certification, and procurement teams know it.
How does COPPA affect an edtech website?
COPPA affects an edtech website whenever it collects personal information from children under 13, including through sign-up forms, cookies, analytics and advertising trackers. The FTC enforces it, and its guidance addresses when schools can authorize collection for educational purposes. Check the current rule and guidance on ftc.gov with counsel.
- Separate child-facing and adult-facing areas. Marketing pages aimed at teachers and parents can be treated differently from student experiences.
- Limit data at sign-up. Collect only what's needed. Class codes and school single sign-on reduce personal data from children.
- Control tracking. Remove advertising pixels and third-party trackers from any page children may use.
- Design consent flows with counsel, whether consent comes from parents or, where permitted, from schools.
- Publish a clear children's privacy notice linked from sign-up and the trust page.
What should a student data privacy page include?
A student data privacy page should explain, in plain language, what student data you collect, why, who can access it, where it's stored, how long you keep it and how schools can request deletion. It should link to the full privacy policy and data terms, and be written for a busy administrator, not a lawyer.
- Summary: a short statement of your commitments, such as no selling student data and no targeted advertising.
- Data inventory: a table of data types collected, the purpose of each and who provides it.
- Access: who at your company and which subprocessors can access student data, and why.
- Storage and security: where data is hosted, encryption and access controls.
- Retention and deletion: how long data is kept and how schools request deletion or export.
- School control: how schools and districts manage accounts, rostering and permissions.
- Agreements: your data processing agreement, any state-specific agreements and how to request them.
- Contact: a named privacy contact or team email.
Template: data inventory table for a student privacy page
Use four columns: data type, examples, purpose and source. Rows typically include account data (name, school email, class), learning activity (answers, progress, time on task), technical data (device type, browser, IP address for security) and teacher-provided content (assignments, comments).
For each row, state the purpose in one sentence, such as 'to show progress to the student and teacher'. If a data type isn't collected, consider saying so explicitly, for example 'we do not collect precise location'. Clear negatives answer questions before procurement teams ask them.
What accessibility rules apply to edtech websites?
Edtech websites are usually expected to meet WCAG 2.1 AA, and many buyers now reference WCAG 2.2. Public schools and universities have obligations under the ADA and Section 504, and the Department of Justice's ADA Title II rule for state and local governments adopted WCAG 2.1 AA as the technical standard for their web content. Check current compliance dates on ada.gov, because they've been subject to change.
In practice, districts and universities pass these obligations on to vendors through procurement. Expect requests for an accessibility conformance report (often based on the VPAT template), an accessibility statement and evidence of testing. The marketing site matters too: an inaccessible homepage signals that the product may be inaccessible as well. For the general rules, see our guides to website accessibility compliance and ADA website compliance.
Pros
- Accessible sites and products open doors in public-sector procurement
- Accessibility work improves usability for every learner
- A current conformance report shortens security and compliance reviews
- Good semantic structure also helps search and AI engines read your pages
Cons
- Full audits and remediation take real time and budget
- Conformance reports go stale as the product changes
- Third-party embeds (video, quizzes, chat) can break conformance
- Overlay widgets don't fix underlying issues and can create new ones
How do you build an edtech trust page for district procurement?
Build an edtech trust page as a single hub that answers procurement questions in the order districts ask them: privacy, security, accessibility, integrations and agreements. Link it from the main navigation, the school and district path, sign-up and the footer.
Lead with commitments
Open with three to five plain-language promises about student data, each linked to detail.
Add the student data privacy section
Use the structure above: data inventory, access, storage, retention and school control.
Publish accessibility documentation
Accessibility statement, current conformance report, testing approach and a contact for issues.
Describe security
Hosting, encryption, access controls, incident response and any independent audits you genuinely hold.
List subprocessors and integrations
Who processes data on your behalf, plus SIS, LMS, SSO and rostering integrations.
Make agreements easy to request
Downloadable data processing agreement, state-specific agreements and a request form.
Date and maintain it
Show a 'last updated' date and assign an owner to review the page on a fixed schedule.
Trust pages in other industries follow a similar pattern. Our guides to the AI trust center page and the HR software security page show how to present certifications, subprocessors and data use without burying them. If your product uses AI with student data, explain what the model does and whether student data is used for training.
What is the full edtech website compliance checklist?
Use this checklist before a launch, a redesign or a major district sales push. It covers the website, not your whole compliance program, and each item should be confirmed with the people who own it.
Area | Check | Owner |
|---|---|---|
Privacy | Student data privacy page in plain language, linked from nav | Legal and marketing |
Privacy | Children's privacy notice linked from sign-up | Legal |
Tracking | No ad pixels or third-party trackers on student-facing pages | Marketing and engineering |
Forms | Sign-up collects only needed data; age and consent flows reviewed | Product and legal |
Agreements | Data processing agreement and state agreements available on request | Legal and sales |
Accessibility | Site tested against WCAG 2.1 AA; statement published | Design and engineering |
Accessibility | Current conformance report for the product | Product |
Security | Security overview and subprocessor list current | Engineering |
Maintenance | Trust page dated and reviewed on schedule | Named owner |
Write each trust and FAQ section so it answers one question directly in its first sentence; that helps buyers and makes the content easier for search and AI engines to quote. Our guide to answer-first content structure explains the format. For broader examples of how learning platforms present privacy, browse our edtech website examples.
