Privacy Glossary

A non-profit collaboration of schools, districts, states, and software vendors dedicated to interoperability, privacy, and security in educational technology.

A4L is the parent organization behind the SDPC and the National Data Privacy Agreement. If you hear someone reference "the consortium," this is usually what they mean.

An annual self-assessment for LEAs to review their privacy practices and identify areas for improvement.

Think of it as a checkup for your privacy program. The district data manager uses this to review all agreements and vendor policies, making sure the LEA is following best practices before the annual state privacy report is due.

A tool built to act as an automated, AI-assisted speed layer on top of the SDPC Resource Registry. It reviews Data Privacy Agreements and flags problematic clauses so tech directors can say yes to teachers faster.

That is what you are looking at right now. The goal: turn a process that takes days into one that takes minutes.

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.

Any merger, acquisition, consolidation, or sale of all (or substantially all) of the assets of a Provider, or of the portion of Provider that performs the services in the Service Agreement.

This clause matters more than most people think. When an ed-tech company gets acquired by a larger corporation, the Change of Control clause ensures the new owner is legally bound to the same data privacy protections as the original vendor. Without it, your data agreement may not survive the transition.

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.

The U.S. national data dictionary that establishes a shared vocabulary for how education data connects across different systems.

When two systems use different names for the same field, CEDS is the Rosetta Stone. Without it, interoperability is guesswork.

An LEA's comprehensive, published plan for managing education data, including protection, sharing, and breach response.

This is the guiding document for all staff. It outlines who can access student data, the secure methods for sharing it with vendors, and the steps to take in the event of a data incident. If your district does not have one, that is the first thing to fix.

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.

Specific data elements (like name and address) defined under FERPA that a school may disclose, subject to a parent's right to opt-out.

Districts define their own list of directory information. If a vendor is collecting something your district hasn't designated as directory information, that changes the legal picture.

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 exhibit where the Provider must mark one or more nationally or internationally recognized cybersecurity frameworks with which it complies.

Check Exhibit F to see if a vendor meets a recognized security standard like NIST Cybersecurity Framework or ISO 27000 series. If a vendor leaves this blank or marks "none," that tells you something about their security posture.

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.

Records specifically defined and protected under FERPA (20 U.S.C. 1232g(a)(4) and 34 CFR § 99.3).

Not everything a school collects qualifies as an "education record" under FERPA. But if a vendor is processing data that does qualify (grades, behavioral notes, transcripts), FERPA's rules apply whether the vendor realizes it or not.

A Gates-funded project by Data Standard United designed to build a governed semantic backbone and reference library for practical data interoperability.

Think of EDUcore as the plumbing that makes it possible for different education systems to actually talk to each other using a shared vocabulary.

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.

A recognized cybersecurity framework guiding security and management practices in the education space.

If FERPA tells you what data to protect, GESS tells you how to protect it. It is the security playbook for the education sector.

A public-private initiative to standardize job and employment records, linking K-12 education data to broader workforce and longitudinal data systems.

JEDx connects the dots between what a student learned and where they ended up working. That longitudinal view requires extremely careful data governance.

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 public record required by Utah law that defines all PII collected and shared by the LEA, including with whom it is shared and for what purpose.

When a parent wants to know what information their child's school shares with a vendor, the Metadata Dictionary is where they should be able to find a complete, transparent list. If your district does not have one published, you may be out of compliance with Utah law.

Contextual information providing meaning to other collected data (e.g., date and time of creation). If stripped of all direct and indirect identifiers, it is not considered PII or Student Data.

The catch is "if stripped of all identifiers." A timestamp alone might be harmless. A timestamp combined with a device ID and a school network can re-identify a student. An online learning platform that collects access times and session durations is collecting metadata, and depending on context, it may need to be treated as Student Data.

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.

A federal law restricting surveys, evaluations, and the collection of specific sensitive student information.

PPRA says you cannot survey students about certain sensitive topics (political beliefs, mental health, sexual behavior) without parental consent. It applies to third-party surveys run through ed-tech tools too. If a school wants to administer a student survey on family backgrounds, the principal must ensure PPRA compliance first.

A Department of Education resource center offering guidance on data privacy, confidentiality, and incident response.

PTAC is your free federal resource. If you have a privacy question and don't know where to start, PTAC has guidance documents, webinars, and a help desk.

A legal provision that grants an LEA the ability to verify a vendor's data practices and compliance with an agreement, as provided for in Utah Code § 53E-9-309.

If your LEA receives a report of a potential security vulnerability in a vendor's system, the Right to Audit lets you inspect their data security protocols and ensure they are meeting contractual obligations. This is a real power. Use it.

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.

Any information gathered, created, or inferred by a Provider, or supplied by an LEA, that is descriptive of a student. This includes Education Records, PII, persistent unique identifiers, and identifiable metadata.

Notice the word "inferred." If a vendor uses an algorithm to predict a student's reading level based on their clicks, that prediction is Student Data. The definition is broader than most people realize. A math teacher's online quiz scores? Student Data. The vendor cannot use it for purposes outside of instruction.

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 as a speed layer, so you can review and act on agreements faster than the Registry alone allows. 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.

A comprehensive open standard and K-12 data model designed to securely connect learning systems with built-in interoperability and privacy.

SIF is the technical standard that makes it possible for your SIS, LMS, and assessment platform to actually exchange data securely. It is the pipes behind the walls.

A model integrating with CEDS that acts as a "periodic table" of standard elements to automate validation and transformations across data standards in special education.

Special education data is some of the most sensitive data a district handles. SEDM exists to make sure that data can move between systems without losing meaning or breaking compliance.

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.