Privacy Glossary

A federal law applying to commercial operators collecting data from children under 13, enforced by the FTC. The FTC recognizes two school-based consent mechanisms: schools acting as a parent's agent (consenting on the parent's behalf) or as an intermediary (channeling COPPA notices and consent between operators and parents). Both require that data be used solely for educational purposes.

The school consent authority is narrow regardless of which mechanism applies: data must benefit the school with no commercial use by the operator. The operator must still provide all COPPA-required notices and give the school the ability to review, delete, and stop further collection of a child's data. This is exactly why a solid DPA review process matters.

The delivery of advertisements based on a user's current visit to a website or a single search query, without the collection and retention of data about the consumer's online activities.

The NDPA prohibition on targeted advertising does not extend to contextual advertising. A student uses an online dictionary and sees an ad for a thesaurus: that is contextual. Targeted advertising, which tracks and acts on student behavior across sessions, is prohibited. The distinction matters in DPA reviews.

A contract between an LEA and a vendor that outlines the obligations for protecting student data.

This is the document that makes everything real. Without a signed DPA, your vendor relationship is operating on trust. With one, you have enforceable obligations. When a teacher wants to use a new online program, the first thing to check is whether a signed DPA exists.

A version of the National Data Privacy Agreement utilized when edits are made to specifically address one district's needs. Because these modifications are highly localized, no Exhibit E (piggyback clause) is offered.

This is the custom-tailored version. It solves your district's specific problem, but other districts can't sign on. For statewide efficiency, the standard or vendor-specific NDPA is usually the better path.

An unauthorized release, access to, disclosure, or acquisition of Student Data that compromises its security, confidentiality, or integrity in violation of applicable state or federal law.

When a vendor's system is hacked and student information is exposed, this constitutes a Data Breach. The DPA requires the vendor to notify the LEA and take specific steps to mitigate the damage. The question isn't if you'll hear about it. It's whether you had a signed agreement that defined what happens next.

Records and information where all Personally Identifiable Information has been removed or obscured, ensuring the remaining information cannot reasonably identify a specific student, including any information that, alone or in combination, is linkable to a specific student.

The word "reasonably" does a lot of heavy lifting here. A vendor that wants to use student data to improve its algorithm can use De-Identified Data (anonymous test scores, completion rates) to protect privacy. But with enough data points, de-identified data can sometimes be re-identified. That is why the NDPA has strict rules around this.

An exhibit attached to the DPA that describes all products and services covered by the agreement.

When an LEA signs a DPA, Exhibit A is where you confirm that every product the vendor offers that you plan to use is actually covered. If a vendor rolls out a new tool mid-year, check whether it is listed in Exhibit A. If not, you may need an amendment.

An exhibit attached to the DPA that identifies the specific Student Data elements processed by the Provider to perform the services.

Before approving a new app, check Exhibit B. It tells you exactly what data the vendor is collecting. If they are asking for data beyond what is listed here, that is a red flag.

An exhibit that provides the definitions for capitalized terms used in the DPA. In the event of a conflict, the definitions in the DPA prevail over terms used in other writings.

When you hit a term in the DPA that feels ambiguous, Exhibit C is where you look for the precise, legally binding definition. It is the arbiter when the vendor's marketing materials say one thing and the contract says another.

An optional exhibit that an LEA can use to provide specific instructions to the Provider for the disposition of Student Data that are not already covered in the DPA.

If you need a vendor to destroy all student data on a specific date (say, before a contract non-renewal takes effect), Exhibit D is where you formally document that request. Without it, the vendor defaults to whatever timeline is in the main agreement.

A document within the NDPA that allows a vendor to make a general public offer of their agreed-upon privacy terms, letting other LEAs ("Subscribing LEAs") piggyback onto the contract without negotiating a new one.

This is the single most powerful efficiency tool in the NDPA system. One district negotiates, and 50 more can sign on. That is why the SDPC registry exists: to make Exhibit E discoverable. A small charter school can execute an Exhibit E to adopt an existing NDPA without a full individual negotiation.

An optional NDPA exhibit generated by State Alliances to address state-specific data privacy legislative requirements.

Every state has its own privacy laws on top of FERPA. Utah has SB 267 (which directs USBE to study software use in public schools) and Utah Code §53E-9 (Student Privacy and Data Protection). California has SOPIPA. Exhibit G is where state-specific requirements get folded in. For Utah, audit and sub-processor disclosure requirements come from §53E-9, not SB 267.

The specific section of the NDPA where all modifications, redlines, or edits to the standard clauses must be documented. If changes are made but not listed here, the contract legally loses the right to use the official NDPA moniker.

This is the honesty clause. If a vendor says "we signed the NDPA" but there are undocumented changes, it is not actually an NDPA. Exhibit H keeps everyone accountable. Both the LEA and the vendor sign it to confirm all parties agree to the alterations.

The foundational U.S. federal law protecting student data privacy. It governs the disclosure of education records and parental access rights.

FERPA is from 1974. It predates the internet by decades. It still applies to every ed-tech vendor touching student data, and it is the legal backbone that everything else (COPPA, state laws, the NDPA) builds on. Parents have the right to inspect and review their child's Education Records, request amendments, and must give consent before records are shared with third parties outside of recognized exceptions.

Utah state law (Title 63A, Chapter 19, effective May 2024) that standardizes privacy requirements for all regulated government entities, including limits on data collection, prohibitions on selling or sharing data, and individual rights to access and correct personal data.

The GDPA applies broadly to Utah government entities, not just schools. For LEA-specific annual reporting requirements and vendor data governance, see Utah Code 53E-9 (Student Data Protection). The two laws work together: the GDPA sets the baseline for all government data handling, while 53E-9 adds education-specific requirements like the annual report to the Utah State Board of Education.

The educational entity entering into the privacy agreement. This encompasses state agencies, educational service agencies, charter schools, private schools, or local school districts.

When the NDPA says "LEA," it means whoever is signing on behalf of the students. That is usually the district, but it can be a charter school, a state agency, or a regional service center. For the purpose of the DPA, the LEA is the entity responsible for making sure all schools within its boundaries comply with federal and state student data privacy laws.

A standardized, community-created legal contract designed to streamline educational app contracting, standardize data protection expectations, and eliminate the need for districts to negotiate one-off contracts with vendors.

Before the NDPA, every district was negotiating its own agreement with every vendor. One district might have 200+ vendors. Multiply that by thousands of districts and you see the problem. The NDPA is the solution: one standard contract that works everywhere. When a teacher wants to use a new tool, the IT department can check the NDPA registry first to see if a signed agreement already exists.

A companion document to the NDPA utilized for standardizing data-sharing agreements between schools/districts and researchers under FERPA's "Studies Exception."

Research partnerships are valuable but tricky. The NRDPA gives districts a standardized way to share data with researchers without building a custom legal agreement every time.

The membership-elected leadership group that reviews the work of the Legal Project Team and approves new versions of the NDPA.

These are the people who decide what goes into the next version of the NDPA. If you want to influence the standard, this is the room to be in.

The initial educational entity that signs the DPA in its entirety with a vendor, potentially paving the way for other districts to sign on later.

The Originating LEA does the heavy lifting. They negotiate, they review, they sign first. As the Originating LEA, a large school district spends time and resources negotiating a master DPA that benefits dozens of other districts that can then easily adopt the agreement through Exhibit E.

Data defined under 34 C.F.R. § 99.3 and applicable state laws that can directly or indirectly identify an individual student.

The word "indirectly" is key. A student's name is obvious PII. But a combination of grade level, school, and birth date can also identify someone. Vendors sometimes collect indirect PII without realizing it. If a vendor's platform requires a student's name, birthdate, and student ID to create an account, that combination is PII and the DPA must specify how it will be protected.

Under FERPA, a contractor or vendor performing an institutional service or function for which the school would otherwise use employees, operating under the school's direct control regarding PII.

When a vendor is designated as a "school official," they can access education records without parental consent. That is a big legal privilege, and it comes with real obligations. The DPA is what defines those obligations. A vendor that handles the LEA's student information system is a School Official, which allows the LEA to share FERPA-protected data for educational purposes without individual parental consent.

The underlying business contract (e.g., terms of service, quote, or purchase order) that dictates the commercial relationship. The NDPA supersedes this agreement regarding the treatment of student data.

The Service Agreement is the business deal. The NDPA is the privacy deal. When they conflict on how student data is handled, the NDPA wins. That is by design.

A third-party subcontractor utilized by the primary Provider for data collection, analytics, security, or storage, and who has access to or storage of Student Data. They must be subject to privacy terms no less stringent than the NDPA.

Your vendor signed a DPA. Great. But does their cloud hosting provider? Their analytics subcontractor? Their customer support company? Subprocessor disclosure is one of the most commonly missed items in DPA reviews. The DPA requires the main vendor to ensure that its Subprocessors also comply with the privacy protections.

An agreement between a Provider and a third-party Subprocessor. It can be a written agreement or an acceptance of terms and conditions.

The DPA requires the vendor to have a Subprocessor Agreement with every third party that touches student data. This ensures the third party is bound by the same strict privacy rules as the original vendor. If a vendor cannot produce this when asked, that is a concern.

A legal term stating that the terms of an agreement remain in force if a vendor is sold or acquired by another company. The DPA is binding upon the respective successors in interest to the Provider in the event of a Change of Control.

If a vendor is purchased by a competitor, the Successors Bound clause ensures the new company must continue adhering to the data privacy protections in the original DPA. Without this clause, an acquisition could void your privacy protections overnight.

Digital materials explicitly created by a student (e.g., essays, photos, audio files, portfolios). This does not include student responses to standardized assessments.

A student's essay belongs to the student. A student's test answers belong to the assessment. The NDPA draws that line clearly, and it affects what a vendor can keep after the contract ends. A student's digital art portfolio is their intellectual property, and the vendor cannot use it for commercial purposes.

A centralized platform and two-sided marketplace where Alliances manage privacy frameworks, districts track and search for signed agreements, and vendors manage their DPA portfolios.

The Registry is the source of truth for who has signed what. ABYA sits on top of it, surfacing each district's agreements in one hub a parent or board member can actually read. When a district IT director wants to see if an NDPA already exists for a new tool, this is where they look first.

A digital badge earned automatically by a vendor when they successfully sign a standard Alliance DPA, acting as a visible signal of their commitment to student privacy.

Think of it as a trust mark. When a vendor has this badge, it means they went through the standard process. No badge? That is a question worth asking.

A special interest group of the A4L Community comprising districts, states, and vendors. It was created to address real-world student data privacy issues and establish common market expectations.

SDPC is the engine behind the NDPA, the Resource Registry, and the entire framework most districts use for vendor privacy management. If you are in K-12 privacy, you are working within the SDPC ecosystem whether you realize it or not.

A district or school that was not a party to the original Service Agreement but legally signs onto the Provider's General Offer of Privacy Terms (via Exhibit E).

This is the piggyback mechanism in action. One district negotiated. You benefit. But you still need to sign Exhibit E to make it official. A charter school in a different county can become a Subscribing LEA by executing Exhibit E, which binds them to the pre-existing NDPA.

Presenting advertisements to a student based on their Student Data or behavior inferred over time from usage of the Provider's website, online service, or mobile application. The NDPA strictly prohibits Targeted Advertising, though it allows for adaptive learning customizations or product recommendations permitted by the LEA.

This is a bright line. No vendor can target ads at students based on their behavior. Period. If a DPA does not explicitly prohibit this, that is a red flag worth catching. A student uses an educational app and starts seeing ads based on their in-app activity? That is Targeted Advertising and it violates the NDPA.

A modified version of the NDPA used when there are agreed-upon edits that are approved by Alliance leadership for all member districts. In this setup, the vendor has the option to sign Exhibit E to allow other districts to piggyback.

This is the middle ground between a standard NDPA and a district-modified one. The vendor gets some customization, but it is approved at the Alliance level, so the piggyback option stays open.