Sooner or later a school district sends you a student data privacy agreement and asks you to sign it before any teacher can use your product. Then a second district sends a different one. By the tenth, you have a stack of agreements with overlapping but not identical terms, and no clear record of what you have promised to whom.
A student data privacy agreement, often shortened to SDPA or DPA, is the contract that sets out how a vendor may collect, use, protect, and dispose of student data. It is where FERPA's conditions, state student privacy laws, and district policy become specific obligations with your signature on them.
This article covers why districts require these agreements, what they typically contain, how standardized agreements work, and which clauses you should be able to operate before you sign. It is not legal advice. State laws differ and change, so have counsel review each agreement against the laws of the states you serve.
Why districts require one
FERPA does not use the term "data privacy agreement". It does set conditions that a written agreement is the obvious way to meet. A district relying on the school official exception needs the vendor to be under its direct control with respect to education records and bound by the regulation's limits on redisclosure. Our article on the FERPA school official exception explains those conditions. A contract is how the district shows it imposed them.
State laws add a second reason. Many states have student privacy statutes, and several regulate EdTech operators directly or prescribe what contracts with them must contain. Examples include California's Student Online Personal Information Protection Act, New York's Education Law section 2-d, and Illinois's Student Online Personal Protection Act. Requirements vary widely, including on advertising, sale of data, security standards, breach notification, and public posting of agreements.
District policy is the third. Many districts will not approve a tool for classroom use without an agreement on file, whatever the law strictly requires.
What a typical agreement contains
Agreements differ in wording, but most cover the same ground. Expect each of these sections.
Parties, term, and scope. Who is bound, for how long, and which services the agreement covers.
Data elements. A schedule listing the categories of student data you will receive or collect, such as demographic, enrollment, assessment, or behavioral data. This is often an exhibit with checkboxes.
Ownership and control. Student data remains the property or under the control of the district. You act on its behalf.
Permitted use. Use only to provide the contracted services. Often an explicit statement that you are acting as a school official under FERPA.
Prohibited uses. No sale of student data, no targeted advertising, no building profiles for purposes unrelated to the service, and no disclosure except as the agreement permits.
De-identified data. Whether and how you may use de-identified data, what de-identification standard applies, and a prohibition on re-identification.
Subprocessors. Disclosure of subprocessors and a requirement to bind them to equivalent terms.
Parent and student requests. How requests to inspect or amend records are routed, usually to the district within a set period.
Security. Administrative, technical, and physical safeguards, sometimes tied to a named framework, and sometimes requiring a security contact.
Breach notification. What counts as a breach, how quickly you must notify the district, and what the notice must contain.
Return and deletion. What happens to data at the end of the contract or on request, and how you certify it.
Audit and inquiry rights. The district's right to ask about, or review, your compliance with the agreement.
Some states require specific attachments, such as a parents' bill of rights for data privacy and security in New York. Check for these before you treat an agreement as complete.
Standardized agreements
Negotiating a unique agreement with every district does not scale for either side. Standardized agreements exist to reduce that burden.
The Student Data Privacy Consortium publishes a National Data Privacy Agreement, with state-specific versions in many states that account for local law. Its structure follows the sections above, with exhibits for the data elements and for state-specific terms.
One feature matters a great deal to vendors. The agreement includes an optional general offer of terms. If you sign it, other districts can adopt the same terms with you without a new negotiation. That can save weeks per district. It also means every term you agree to becomes your standard, so read it as a commitment to every district that accepts the offer, not only the first one.
Standardized does not mean identical. Districts can propose modifications, state versions differ, and some districts use their own templates. Confirm the current version and state terms with the consortium's materials and with counsel before you sign.
The clauses that need operational work before you sign
Most agreement terms describe things you should already be doing. A few create obligations you may not yet be able to meet. Check these first.
Breach notification windows
Agreements set specific notification periods, and they vary. Your incident response process needs to identify affected districts quickly and meet the shortest window you have agreed to. Our guide to writing an incident response plan covers the structure; the agreement adds district contacts and deadlines to it.
Deletion and certification
Many agreements require deletion within a set period after termination, plus written certification. That requires a deletion process that covers primary storage, replicas, logs, and backups, and produces a record. If backups cannot be selectively purged, say how they expire, and make sure the agreement allows for that.
Subprocessor commitments
If the agreement requires prior notice of new subprocessors, or district approval, your vendor onboarding has to check that before any new tool touches student data.
De-identified data use
If you use aggregated or de-identified data for product improvement or research, confirm the agreement permits it and that your de-identification method meets the stated standard. Removing names is rarely enough under FERPA's definition of personally identifiable information.
Data location and access
Some agreements restrict where data may be stored or who may access it, such as limiting offshore access. Check this against your support and engineering model.
Managing dozens of agreements
Once you serve many districts, the challenge shifts from negotiation to tracking. A workable approach:
Keep one record per agreement. District, state, version, signature date, term, and any modifications from your standard.
Extract the operational terms. Breach window, deletion period, data elements, subprocessor approval, and any special attachments.
Map terms to controls. Each obligation should point to the control and owner that meets it, and to the evidence that shows it.
Track exceptions. A district that negotiated a shorter window or an extra restriction needs its exception visible to the team that would act on it.
Review at renewal. Agreements expire. Review terms, and the controls behind them, before renewal rather than after.
Security questionnaires from districts will ask about the same commitments. Our guide to answering security questionnaires covers keeping those answers consistent with what your agreements say. For FERPA's underlying requirements, see the FERPA framework page.
How TrustLynce helps
TrustLynce records each agreement's terms as customer commitments and tracks them against the controls that meet them, so breach windows, deletion periods, and subprocessor approvals have owners and evidence. When a district asks how you meet a clause, the answer points to a control that is monitored, not to a promise in a filing cabinet.