FERPA compliance checklist for edtech pilots in school districts

Before students log in, a FERPA-ready pilot needs a signed data agreement with each district, a data inventory, role-based access, encryption, audit logging and a deletion plan. Expect district privacy and IT review to take 4–10 weeks. The longer end applies when the district wants its own agreement signed or the app sends student data to third-party AI services.

FERPA (the Family Educational Rights and Privacy Act) applies to the district, not directly to you. A district can share student education records with a vendor or research team without parental consent only under specific exceptions. The district then holds you to that exception through a contract. Your job is to make it easy for the district to show which exception covers you and that you stay inside it.

Most pilots fit one of two exceptions, and which one you are under changes what your software has to do.

Many pilots run under both: teachers use the app for instruction, and the PI analyzes the logs as research. If so, say that in the agreement. The district’s counsel decides which exception applies, and your institution’s compliance office or counsel reviews it on your side. This page lists what they will ask for. It is not legal advice.

Data and agreements

1. Write a data inventory: every field you collect, where it is stored, who can see it and why the study needs it. Remove any field you cannot justify.
2. Sign a data privacy agreement with each district. Many districts use the Student Data Privacy Consortium’s National Data Privacy Agreement or their state’s version. Some require their own.
3. Check the state student privacy law. Many states add requirements beyond FERPA, such as bans on targeted advertising or required breach notices.
4. If any students are under 13, review COPPA obligations with counsel. In school settings the school can usually consent for educational use only.
5. Align the IRB protocol, the consent and assent forms, and the district agreement so they describe the same data. Reviewers compare them.

Technical controls

1. Pseudonymize research logs. Store a study ID, not a name, and keep the linking key separate with tighter access.
2. Use role-based access: students see their own work, teachers see their own roster, and researchers see de-identified exports.
3. Encrypt data in transit (TLS) and at rest, and prefer single sign-on through the district’s identity provider over new passwords.
4. Keep an audit log of who viewed or exported student data, and when.
5. List your subprocessors (cloud host, analytics, any AI model API), and confirm that none of them train on or keep student data.
6. Write a deletion procedure with a date, and test it before the pilot ends, not after.

District reviewers work through a questionnaire, and the fastest reviews are the ones where the answers arrive as a ready-made package. We call it the technical disclosure package. Writing it takes us about 15–25 hours for a typical pilot app.

The network requirements document gets overlooked most often. School content filters block unknown domains, WebSocket connections and audio or media endpoints by default. The first thing that breaks when research code meets a school network is usually a blocked domain, not a privacy question.

1. Week 1: data inventory, subprocessor list and data flow diagram. Cut fields the study does not need.
2. Weeks 1–3: engineering hardening. This covers pseudonymized logging, roles, SSO, encryption checks, audit log and deletion script.
3. Weeks 2–3: technical disclosure package sent to each district along with the agreement.
4. Weeks 3–10: district review. This runs in parallel with IRB amendments, teacher onboarding and content preparation.
5. Week before launch: test on a district device on the district network with a real teacher account.

A focused 30-day sprint can deliver the engineering and the disclosure package. It cannot speed up a district’s legal office, so send the agreement in week 1. We took one research prototype to a district-approved classroom pilot in under 30 days: 20 teachers, two districts, and 100+ framework-compliant problems generated. That timeline worked because the privacy documents went out in the first week.

• Treating IRB approval as FERPA clearance. They are separate reviews, and the district does its own.
• Logging everything for later analysis. Funders want clean data, but reviewers flag any field without a stated purpose.
• Sending student text to an AI model API with no contract terms on retention or training. This is now one of the first questions districts ask.
• Shared researcher logins and exports emailed as spreadsheets. Both break the access limits the agreement promised.
• No deletion plan, so student data sits in a graduate student’s cloud account after the grant ends.

A graduate student can keep building features while the study design is still changing. Bring in an engineering team when real student data is about to arrive. At that point reliability and privacy controls are part of research validity, and a program officer will judge the software as production work.

Does FERPA apply to my edtech startup or only to the school district?
FERPA applies to schools and districts that receive federal education funding, not directly to vendors. Districts pass its obligations to you through a data privacy agreement. In practice you must meet those terms or the district cannot share data with you.

Is IRB approval enough to run a pilot with student data?
No. The IRB protects research participants, while district review covers FERPA, state privacy law and network security. Most districts also have their own research approval process. Plan for all three, and make sure their documents describe the same data.

How long does district privacy review take for a pilot?
Typically 4–10 weeks. Districts that already have a standard agreement and a clear questionnaire are faster. Reviews take longer when the district wants its own contract signed, when legal teams go back and forth on edits, or when the app sends data to third-party AI services.

Can we use an AI model API like OpenAI or Anthropic in a classroom pilot?
Often yes, but the district will want the provider on your subprocessor list, and contract terms showing student data is not used for training or kept longer than needed. Pseudonymizing what you send and avoiding names in prompts makes review easier. The district’s counsel makes the final decision.

What should happen to student data when the pilot ends?
The agreement should name a deletion date and method, and you should be able to show deletion happened, usually with a written confirmation. Keep only de-identified research data that the agreement and IRB protocol permit. Test the deletion procedure before the pilot, not at the end.

We offer a free 30-minute review of your pilot plan or the technical section of your proposal. Bring the prototype’s repository or a demo, your pilot timeline and the district’s or funder’s requirements, and we will tell you what review will ask for and what to fix first. Start a conversation.