Quick Answer
A student data privacy agreement (DPA) is a contract binding a vendor to a district's student-data rules. It usually comes up when a school hands data over: a roster upload, accounts from school records, or a district sign-in. When families sign up themselves and the school sends none of that, those handoffs haven't happened. Your district decides the rest.
TL;DR
FERPA is enforced against the school, not the vendor. So a school that shares student records has to bind the vendor by contract, and that takes time. Each source also has its own scope. FERPA covers education records the school keeps or shares. New York's Education Law 2-d covers contractors that get student data from a school or district. California's SOPIPA covers services used mainly for K–12 school purposes and designed and marketed for them, and it excludes general-audience apps. The U.S. Department of Education's vendor guidance covers services provided to a school, not ones students use on their own outside school. Every source is linked below, so your reviewer can check the text instead of trusting a vendor's summary.
What this is: KudoKids is a vendor — we sell schools a funded year of our family app, so read this the way you'd read any vendor writing about privacy review: a plain-English summary of the public sources, each one linked, and not legal advice. What your district needs on file is your district's determination, never ours.
What Is a Student Data Privacy Agreement, and When Do Schools Sign One?
A DPA is a contract between a school district and a vendor that receives student data, binding the vendor to the district's privacy obligations. A district can start from a shared template: the National Data Privacy Agreement (NDPA) maintained by the Student Data Privacy Consortium — currently version 2.2 — which exists so that a district and a vendor don't have to negotiate a bespoke contract for every app.
Its terms are worth knowing even if you never sign one, because they spell out what a district can ask any vendor to agree to: the district owns the student data; the vendor may use it only to deliver the contracted service; no selling it (the one carve-out is a merger or sale of the vendor's company); no targeted advertising off it; subcontractors inherit the same terms; breaches are reported to the district within 72 hours; and data is deleted within 60 days of the district's request or the contract's end.
What counts as "student data" matters here. NDPA v2.2 defines it as data "gathered, created, or inferred by Provider or provided by LEA or its users, students, or students' parents/guardians, for a school purpose." (LEA is the contract's word for the district.) So under the NDPA, student data isn't only what a district uploads. It can include what students and parents enter, when it's for a school purpose.
What Actually Triggers a Student-Data Privacy Review?
Each framework starts at a different point: FERPA and New York's 2-d start when a school shares student data, COPPA when an app collects data from a child under 13, California's SOPIPA with how a service is built and sold, and a DPA with a signature:
| Framework | What starts the obligation, in plain English |
|---|---|
| FERPA (federal) | The school discloses personally identifiable information from education records — records directly related to a student that the school (or a party acting for it) maintains. Vendors usually receive it under the "school official" exception, which requires the school to keep direct control over how the vendor uses it. |
| COPPA (federal) | Applies to child-directed online services no matter who buys them — the operator must get verifiable parental consent before collecting from a child under 13. The school-specific variant only enters when a school contracts with an operator to collect student information for the school's use and benefit; then the school may consent in the parents' place, within strict limits. |
| New York Education Law § 2-d | A vendor becomes a "third party contractor" when it receives student data from an educational agency under a contract or written agreement to serve that agency. The district must then attach its Parents Bill of Rights and specific disclosures to the contract. |
| California SOPIPA | Binds operators of services used primarily for K–12 school purposes and designed and marketed for K–12 school purposes — and expressly does not apply to general-audience sites, services, and apps. |
| The DPA itself | A contract: it exists once a district and a vendor sign it, and it covers the student data it defines. In the NDPA, that includes what students and parents provide for a school purpose. |
One school district put the practical version in a single sentence. Edmonds School District's published test for what must be vetted: "Any website, app, or software utility that requires the generation of an account, uses a district credential to authenticate, or gathers information about the student or their progress must first be vetted by the Edmonds School District…" Account creation, district credentials, student progress data — that's the district's own published line, and applying it to any given tool is Edmonds' call. A policy worded like that can reach tools that federal law doesn't, which is why your district's process has the last word on scope.
Why Does the Review Take a Semester?
A privacy review takes months because the school has to set the vendor's rules before any student records move. When a district shares records under FERPA's school-official exception, the Department of Education's 2014 vendor guidance says the district must keep "direct control" over how the vendor uses them. In practice, it says, districts "will usually be able to establish direct control through a contract signed by both the school or district and the provider." That takes legal reading, security review, sometimes insurance requirements, sometimes a board calendar.
San Francisco Unified's published process states a minimum of three months for review, with submission deadlines: October 1 of the prior year for spring-semester use, and April 1 for the start of the next school year. SFUSD also requires an agreement for free tools.
What If No Student Data Leaves the Building?
Each source ties its rules either to data a school shares or to a service provided to, or built and sold for, schools. Where a given app falls is your reviewer's call.
The Department of Education's vendor guidance scopes itself to "computer software, mobile applications (apps), and web-based tools provided by a third-party to a school or district that students and/or their parents access via the Internet and use as part of a school activity" — and then says: "This document does not address online services or social media that students may use in their personal capacity outside of school." Asked whether FERPA protects student information in online services, ED's answer is "It depends," with a contrast: a district that gives a provider student names and contact information to create accounts has disclosed FERPA-protected information; a teacher having students watch video tutorials from a provider that doesn't need individual log-ins is different, because there "no PII [personally identifiable information] from the students' education records would be disclosed to (or maintained by) the provider." The same guidance adds: "Even when FERPA is not implicated, the Department recommends using written agreements as a best practice."
The state statutes carry the same structure in their definitions. New York's § 2-d obligations attach to a vendor that receives student data from an educational agency under an agreement. California's SOPIPA attaches to services used primarily for, and designed and marketed for, K–12 school purposes and expressly excludes general-audience apps.
Here is what that looks like when the family is the customer: the parent creates the account and consents for their own child, and the school sends no roster, no student names, no records and no credentials. That describes how the arrangement is built. It is not a legal opinion about your district. Your reviewer weighs it against your district's own agreements and policies. A district can add its own rules on top of federal law, and some published processes reach further than federal law does (SFUSD's is one). If your reviewer wants the arrangement described in writing, the vendor should hand it over and answer questions plainly.
What Does COPPA Require When Families Sign Up Directly?
COPPA applies to a child-directed app whether or not a school is involved: the operator must obtain verifiable parental consent before collecting personal information from a child under 13, and the FTC's COPPA Rule was amended effective June 23, 2025, with compliance due by April 22, 2026.
What the school's absence changes is who consents. The FTC's schools guidance allows a school that contracts with an operator — for the school's use and benefit, and no other commercial purpose — to consent in the parents' place. In a direct-to-family arrangement there is no substitution to rely on: the parent is the account holder and gives the consent themselves, which is the arrangement COPPA's default rule describes. What any specific operator collects and how it handles consent is exactly what its published children's-privacy notice is for — ours is at our COPPA notice, and our privacy policy states what we collect from a family and what we don't.
What Should a School Still Ask a Family-Enrollment Vendor?
A school should still put six questions to a family-enrollment vendor. Several are adapted from the FTC's questions for schools and from the NDPA's own terms:
- Does any student data flow from us to you — now or through any integration? Roster files, student information system or rostering integrations, district single sign-on, class lists in any form. For a family-enrollment app, the answer should be "none."
- Who holds the account and the consent? It should be the parent, in writing, in the vendor's own documents.
- What do you collect from a family, and which outside companies handle it for you (your subprocessors)? The vendor's privacy policy and subprocessor list should answer this without a meeting.
- Do you sell data or run targeted advertising? The NDPA's flat prohibitions are a good ruler even where there's no NDPA to sign.
- What does our school receive back, and what do parents tell you that feeds it? Ask for the exact list. The safe answer is counts and averages that carry no name or identifier, with figures held back when too few families answered, and never named students or per-child records.
- What's in the app itself? Ads shown to children, upsells aimed at families your school recommended it to — things your name will be attached to either way.
How KudoKids Is Built
KudoKids (kudokids.org) is built as a family-enrollment app: parents sign up themselves through the school's link and consent for their own child, the school sends no roster, and no student names, ID numbers or records move from the school to us. When parents join, they answer a few short questions about how routines go at home. A school that pays gets the premium version for every family in the building. In its hub, the school sees counts and averages that carry no name or identifier: how many families started, and when. It never sees who. The privacy section of the schools page lays out everything that passes between a school and KudoKids, in a list short enough to read in a minute.
And if your district has privacy paperwork for us anyway, send it over — we'll read it and answer you plainly. Ask the same of any vendor. If the question after privacy is funding, that one has its own plain-English walkthrough: how coordinators evaluate family-engagement purchases.
Frequently Asked Questions
What is the difference between a DPA and COPPA?
A DPA is a contract between a school district and a vendor that sets the rules for student data in a service the district uses. It passes the school's duties under FERPA and state law on to the vendor. COPPA is a federal law that binds the operator of a child-directed service directly, requiring verifiable parental consent before collecting personal information from a child under 13. A vendor can be outside any DPA relationship and still fully subject to COPPA.
Do free apps need a data privacy agreement?
Price isn't the trigger — data flow and district policy are. Some districts' published processes require an agreement for any tool staff or students use, free or paid (San Francisco Unified says so explicitly); others scope their review to tools that receive student data. Your district's own process governs.
Does FERPA apply to apps parents choose on their own?
FERPA binds schools and parties acting for them, and it covers education records — records directly related to a student that the school maintains or that are maintained on its behalf. The Department of Education's vendor guidance states that it addresses services provided to a school and used as part of a school activity, not services used in a personal capacity outside of school. How any specific arrangement is classified is a determination for the district's own review.
What is the National Data Privacy Agreement (NDPA)?
The NDPA is the standard student-data privacy agreement maintained by the Student Data Privacy Consortium, an initiative of the Access 4 Learning Community, used across its state alliances so districts and vendors can sign one shared contract instead of thousands of bespoke ones. The current version is 2.2.
Can we see whether a vendor has already signed a DPA with other districts?
You can check. The Student Data Privacy Consortium runs a Resource Registry at sdpc.a4l.org that hosts signed agreements between districts and vendors, and the consortium says a login is required to access it. A vendor with no signed agreements isn't a red flag in itself. It may just mean no district has sent it one yet.
What should a school keep on file for a program where no student data leaves the building?
The ordinary purchase paperwork still exists — an agreement, tax forms, whatever your business office's process requires; that's the procurement lane, separate from the student-data lane this article is about. On the student-data side: the vendor's written description of the arrangement, its written answers to the questions above, its published privacy documents, and whatever the program reports back — for a family-enrollment program, the counts and averages it reports, which carry no name or identifier. What belongs in the file is the district's call.
No ads* · No child data sold · Ages 3–12
*ads can be shown via the YouTube and web browser features if a parent turns them on.
Last updated: September 24, 2026
This article is for informational purposes only and does not constitute legal advice. Every determination about a district's privacy review, paperwork, and policies belongs to the district and its reviewers.
