Student Data Privacy: A K–12 Compliance Guide for Schools

Student data privacy means controlling who can access and share education records, building written and auditable agreements with every vendor, and applying reasonable safeguards to personally identifiable information (PII) at every point in its lifecycle. For K–12 schools, that translates to three immediate actions you can take today.

Start here:

• Launch a data inventory. List every system, app, and vendor that touches student records. You cannot protect what you have not mapped.
• Require a signed data-sharing agreement (DSA) for every vendor. No written agreement means no authorized access, regardless of how useful the tool is.
• Publish a plain-language family notice. Parents and eligible students have a legal right to know what data you collect, why, and who sees it.

For parents specifically: Ask your school which apps and platforms your child uses in class, whether each vendor has a signed DSA, and how long student records are retained after graduation or withdrawal. Those three questions surface most compliance gaps quickly.

Pro Tip: Don't wait for a breach to discover your inventory gaps. A one-page spreadsheet listing every system, its data type, its vendor, and its DSA status is the single most defensible document you can maintain.

What U.S. laws govern student data privacy?

Four federal laws form the core legal framework for educational data protection in the United States. Understanding which law applies to which context prevents both over-compliance in the wrong area and dangerous gaps in the right one.

FERPA is codified at 20 U.S.C. § 1232g and implemented through regulations at 34 CFR Part 99. Its focus is access and disclosure, not technical controls. A school that shares a student's grades with an unauthorized third party violates FERPA; a school that lacks encryption does not violate FERPA per se, though encryption is considered a best practice under the "reasonable methods" standard.

COPPA restricts how online services collect data from children under 13. Schools can provide consent on behalf of parents, but only for tools used for an educational purpose, not for commercial enrichment of the vendor. If a platform uses classroom data to build advertising profiles, the school-consent pathway does not apply.

PPRA governs surveys and data collection on sensitive topics. It is frequently overlooked in procurement, yet it directly affects how schools deploy social-emotional learning platforms and mental health screening tools.

Beyond federal law, state legislatures have passed many student-data protection laws since 2014, many of which add commercial-use prohibitions and vendor obligations that go well beyond FERPA. California's Student Online Personal Information Protection Act (SOPIPA) and Illinois's Student Online Personal Protection Act are two prominent examples. Before finalizing any vendor contract, check your state education agency's (SEA) guidance.

How do you build a school compliance program step by step?

A defensible student-data privacy program is not a single policy document. It is an operational system with assigned roles, documented controls, and a recurring audit cycle. The sequence below reflects the order in which most districts can realistically implement controls.

1. Conduct a data inventory. Catalog every system, application, and data feed that processes student PII. Record the data type, the vendor or internal owner, the legal basis for collection, and whether a DSA exists.
2. Classify data by sensitivity. Separate directory information (name, grade level, enrollment status) from sensitive records (disability status, disciplinary records, health data, biometrics). Apply stricter controls to the latter.
3. Establish a governance charter. Assign a privacy lead or Data Protection Officer (DPO), define decision authority for new data uses, and document escalation paths.
4. Issue the annual FERPA notice. FERPA requires schools to notify parents and eligible students annually of their rights to inspect, review, and seek amendment of education records. The notice must also describe the school's directory information policy and the opt-out process.
5. Maintain a record of disclosures. FERPA's recordkeeping requirements at 34 CFR § 99.32 mandate that schools log each request for and disclosure of education records, including the party's name and legitimate interest.
6. Adopt a data retention and disposal policy. Define how long each record type is kept, where it is stored, and how it is securely disposed of when the retention period ends. Retention schedules for education records vary by state, so align your policy with your SEA's guidance.
7. Execute DSAs with every vendor. No vendor should touch student PII without a signed, written agreement that limits data use to the contracted educational purpose.
8. Deliver annual staff training. Every employee who handles student records needs role-specific training on FERPA rights, disclosure rules, and incident reporting.
9. Conduct an annual privacy audit. Review the data inventory, DSA currency, training completion rates, and incident logs. Document findings and remediation actions.

Roles and responsibilities:

FERPA compliance documentation is what auditors and the Department of Education's Student Privacy Policy Office (SPPO) look for: a current data inventory, signed DSAs, a record of disclosures, training logs, and incident documentation. Gaps in any of these artifacts are the most common finding in FERPA reviews.

Pro Tip: FERPA's "reasonable methods" standard is intentionally flexible, but that flexibility cuts both ways. Document why each control you chose is reasonable for your district's size and risk profile. A written rationale is far more defensible than a control that exists but was never explained.

How should you vet and contract with edtech vendors?

When a vendor processes student PII on a school's behalf, the school remains legally responsible for that data under FERPA. The vendor must operate as a "school official" with a legitimate educational interest, and that relationship must be established in writing through a DSA.

A data-sharing agreement is not a formality. It is the legal instrument that defines what the vendor can do with student data, what they cannot do, and what happens when something goes wrong. Without it, the school has no enforceable control over how student records are used after they leave the district's systems.

Contract clauses to require in every DSA:

• Purpose limitation. The vendor may use student data only for the specific educational service contracted, not for product development, advertising, or any commercial purpose.
• No commercial use or sale. Explicit prohibition on selling, renting, or monetizing student PII in any form.
• Data deletion and return. Upon contract termination, the vendor must return or securely destroy all student data within a defined period, with written certification.
• Audit rights. The district retains the right to request evidence of compliance, including security assessments and subprocessor lists.
• Breach notification. The vendor must notify the district within a defined window (many districts require 48–72 hours) of any confirmed or suspected unauthorized access.
• Subprocessor disclosure. The vendor must list all subprocessors that will touch student data and notify the district before adding new ones.

During procurement, request SOC 2 Type II or ISO 27001 evidence, a complete subprocessor list, the vendor's privacy policy, and a draft DPA. A vendor that refuses to provide any of these documents is a procurement red flag, not a negotiating position.

Operationally, build an onboarding checklist: confirm DSA is signed before granting data access, verify the vendor's security documentation is current, and schedule a reassessment at least annually or when the vendor announces a material change to its platform or subprocessors.

Pro Tip: If a vendor's standard contract says they can use student data to "improve their services," that clause is incompatible with FERPA unless the improvement is directly tied to the contracted educational purpose. Push back in writing and document the vendor's response.

What technical controls and incident response steps protect student data?

FERPA does not mandate specific technical controls like encryption or multi-factor authentication (MFA). It requires "reasonable methods" to protect access and disclosure. In practice, that standard is met by layering controls that reflect the sensitivity of the data and the district's threat environment.

Recommended technical controls:

• Role-based access control (RBAC): grant access to student records only to staff with a documented legitimate educational interest.
• Multi-factor authentication on all systems that store or process student PII.
• Encryption in transit (TLS 1.2 or higher) and at rest for sensitive records.
• Centralized logging and monitoring: retain access logs for a minimum period aligned with your retention policy.
• Regular, tested backups stored separately from production systems.
• Endpoint protection and mobile device management (MDM) for district-issued devices.
• Annual vulnerability assessments and patch management cadence.

FERPA does not set a federal clock for breach notification to families or the Department of Education. That does not mean silence is appropriate. Prompt, transparent notification to affected families and coordination with the SPPO demonstrates good faith and is consistent with the transparency principles PTAC recommends for a proactive privacy program.

Incident response flow:

1. Detect. Identify the unauthorized access or disclosure through monitoring alerts, staff reports, or vendor notification.
2. Contain. Revoke compromised credentials, isolate affected systems, and preserve logs as evidence.
3. Assess. Determine what records were affected, how many students are involved, and whether the disclosure was to an unauthorized party under FERPA.
4. Notify. Inform the privacy lead, legal counsel, and communications staff. Notify affected families and, where appropriate, the SPPO.
5. Remediate. Patch the vulnerability, update access controls, and revise the relevant DSA or internal procedure.
6. Document. Record the full timeline, the records affected, notifications sent, and remediation steps taken.

IT and legal counsel should coordinate from step 2 onward. Communications staff should draft family notifications before they are needed, not during an active incident.

How do you communicate privacy practices to families?

Transparency is not just a legal obligation under FERPA; it is the foundation of the trust relationship between schools and families. A plain-language family notice does more compliance work than any internal policy document.

A good family notice answers five questions in plain language: What data do we collect? Why do we collect it? Who can see it? How long do we keep it? And how can you access, correct, or opt out?

A compliant annual FERPA notice must include:

• A description of the types of education records the school maintains.
• The right to inspect and review those records, and the procedure for doing so.
• The right to seek amendment of records the parent believes are inaccurate.
• The right to consent to disclosures of PII, with a description of the exceptions (school officials, audit and evaluation, health and safety emergencies).
• The right to file a complaint with the SPPO at the U.S. Department of Education.
• The school's directory information policy and the process to opt out of directory information disclosures.

Schools must notify parents and eligible students annually of their FERPA rights, but the format is flexible. A printed handbook insert, a school website posting, and an email with a link to the full notice all satisfy the requirement, provided the notice is reasonably likely to reach parents.

Consent rules in brief:

• FERPA generally requires written consent before disclosing PII from education records, with named exceptions.
• COPPA requires verifiable parental consent for online services collecting data from children under 13, unless the school provides consent for an educational purpose.
• PPRA requires prior written consent before students participate in surveys covering protected sensitive topics.

Log every parental consent and opt-out with a date, the parent's name, and the specific record or activity covered. That log is your audit trail if a disclosure is ever challenged.

The DOE's PTAC hosts model FERPA annual notices and directory information templates that districts can adapt without starting from scratch.

What AI-specific risks should schools address in vendor agreements?

AI tools introduce risks that standard vendor agreements were not designed to address. The most significant: a vendor's model may be trained on student submissions, potentially encoding identifiable information into model weights that cannot be easily purged.

PTAC guidance and privacy experts recommend treating AI vendors as partners in data handling and requiring written DSAs that explicitly address model training uses. The school's responsibility under FERPA does not diminish because the vendor uses machine learning rather than a conventional database.

AI vendor checklist for procurement:

1. Prohibit training on student data without explicit consent. The DSA must state that the vendor will not use student submissions, responses, or behavioral data to train, fine-tune, or improve any model without separate written authorization.
2. Require model explainability documentation. Ask how the system reaches its outputs and whether those outputs can be audited for bias or error.
3. Confirm individual record purge capability. The vendor must be able to identify and delete a specific student's data from training sets and inference logs upon request.
4. Require subprocessor disclosure for model infrastructure. Cloud compute providers, annotation services, and fine-tuning partners are all subprocessors under FERPA.
5. Assess re-identification risk. If the vendor uses de-identified data for model improvement, require documentation of the de-identification method and a contractual prohibition on re-identification attempts.

For internal AI pilots, apply data minimization from the start: use the smallest dataset necessary, segregate training data from production inference data, and document the legal basis for each identifiable data use under FERPA's audit and evaluation or school official exceptions.

PTAC recommends preferring de-identified or aggregated outputs wherever possible. If identifiable data are necessary for a specific AI function, evaluate that use under the applicable FERPA exception and document the rationale before deployment.

Pro Tip: Ask every AI vendor one direct question: "Can you provide written confirmation that student submissions are never used to train your models without our explicit consent?" A vendor that hedges or redirects that question has answered it.

What does a FERPA violation actually look like?

FERPA violations are more common and more mundane than most educators expect. They rarely involve a dramatic data breach. More often, they involve a routine disclosure that someone did not think required authorization.

Concrete examples:

• A teacher emails a student's grade report to the wrong parent after a divorce, where only one parent holds FERPA rights.
• A vendor uses classroom interaction data to build behavioral profiles for marketing to students, a use not covered by the school's DSA.
• A school counselor shares a student's disability accommodation records with a coach who has no legitimate educational interest in that information.
• An AI grading platform trains its model on student handwritten submissions without a DSA clause authorizing that use.

FERPA is not a technical-control mandate. A school can have perfect encryption and still commit a FERPA violation by disclosing a student's records to an unauthorized party. The violation is in the disclosure, not the security posture.

If you suspect a violation, take these steps:

1. Preserve all relevant logs, emails, and system access records immediately. Do not delete or alter anything.
2. Notify your privacy lead or DPO and document the date and nature of the suspected disclosure.
3. Identify the records affected, the parties involved, and whether the disclosure was to an unauthorized recipient under FERPA.
4. If the violation is confirmed, notify affected families and document that notification.
5. Consider filing a complaint with the Department of Education's Student Privacy Policy Office if internal remediation is insufficient or if the violation is systemic.

Schools that self-report and demonstrate good-faith remediation typically receive corrective action plans rather than fund termination. The SPPO's primary goal is compliance, not punishment.

Where can you find authoritative templates and direct help?

The resources below are primary or near-primary sources. Each one contains materials you can download and adapt without legal review from scratch.

• StudentPrivacy.ed.gov / PTAC: The U.S. Department of Education's Privacy Technical Assistance Center hosts model DSA components, FERPA annual notice templates, data security guidance for K–12 and higher education, training modules, and a direct technical assistance contact for districts that need individualized support.
• DOE Data Security Guidance: Specific K–12 and higher education data security resources, including vendor procurement guidance and model contract language.
• CoSN (Consortium for School Networking): CoSN publishes the Trusted Learning Environment (TLE) Seal program and a library of privacy resources specifically for K–12 technology leaders, including a vendor assessment framework and a privacy toolkit.
• Future of Privacy Forum (FPF): FPF's Policymakers' Guide to Student Privacy maps state and federal law, explains the commercial-use prohibition landscape, and provides policy templates for state education agencies.
• State Education Agencies (SEAs): The Illinois State Board of Education (ISBE) and California's Department of Education both publish state-specific student data privacy guidance that supplements federal requirements. Check your own SEA's website for applicable state law summaries and model contracts.

For direct technical assistance, PTAC accepts requests from schools and districts at studentprivacy.ed.gov. The assistance is free and can include document review, training support, and guidance on specific compliance questions.

How should schools handle student biometric and health data?

Biometric and health data sit at the highest sensitivity tier in any student data classification scheme. Biometric identifiers, including fingerprints, retinal scans, voiceprints, and facial geometry, are often regulated by state biometric privacy laws that impose consent requirements and retention limits beyond FERPA. Illinois's Biometric Information Privacy Act (BIPA) is the most litigated example, but Texas, Washington, and several other states have comparable statutes.

Before deploying any system that collects biometric data from students, confirm whether your state has a biometric privacy law, obtain explicit written consent from parents (and eligible students), document the specific purpose and retention period, and prohibit the vendor from using biometric data for any purpose other than the contracted function.

Health records maintained by a school nurse under FERPA are education records, not medical records under HIPAA, unless the school is a HIPAA-covered entity. That distinction matters: FERPA governs their disclosure, not HIPAA's more prescriptive technical safeguard requirements. However, applying HIPAA-equivalent controls (access logging, minimum necessary access, encrypted storage) is a defensible "reasonable methods" posture under FERPA.

Disability and accommodation records require particular care. Sharing a student's IEP or 504 plan with staff who have no direct instructional role with that student is a FERPA violation, regardless of intent. Role-based access controls in your student information system (SIS) should restrict these records to the specific staff members listed in the student's accommodation plan.

How does remote and hybrid learning affect student data privacy?

Remote and hybrid learning environments multiply the number of systems that touch student data and shift much of that data processing to vendor-controlled infrastructure. A student attending class via a video conferencing platform, submitting assignments through a cloud-based LMS, and receiving AI-generated feedback through a third-party tool may have their data processed by four or five vendors in a single class period.

Each of those vendors requires a DSA. Each platform's data collection settings should be reviewed and restricted to the minimum necessary for the educational purpose. Video conferencing platforms, for example, often default to recording sessions and retaining transcripts; those defaults should be disabled unless the district has a specific educational purpose and a documented retention policy for recordings.

Home environments introduce endpoint risks that districts cannot fully control. Provide families with guidance on securing home networks (WPA2 or WPA3 encryption, updated router firmware) and on the risks of using personal devices for schoolwork without MDM enrollment. For district-issued devices used at home, MDM policies should enforce screen locks, remote wipe capability, and VPN use when accessing district systems.

COPPA compliance becomes more complex in remote settings. When a teacher assigns a consumer app for home use rather than a school-managed platform, the school-consent pathway under COPPA may not apply, and the vendor may be collecting data directly from a child under 13 without verifiable parental consent. Vet every tool for home use separately from tools used on district-managed devices.

How do you conduct a privacy audit and risk assessment?

A privacy audit is not an annual checkbox. It is a structured review of whether your documented controls are actually operating as designed. The distinction between a policy that exists and a control that works is where most districts have their largest gap.

Audit components:

• Data inventory review. Verify that every system in the inventory is still in use, that its DSA is current, and that no new systems have been deployed without completing the onboarding checklist.
• DSA currency check. Confirm that every active vendor has a signed DSA that covers the current scope of data processing. Contracts signed three years ago may not address AI features added since.
• Access control review. Pull a sample of user accounts from your SIS and LMS and verify that access levels match current role assignments. Former employees and transferred staff are common sources of excessive access.
• Training completion audit. Confirm that all staff who handle student records completed annual privacy training and that completion was logged.
• Incident log review. Review all reported incidents from the prior year, confirm that each was documented, and assess whether remediation was completed.

For risk assessment, use a structured framework such as NIST SP 800-30 or the CoSN Privacy Risk Assessment template. Identify assets (data types and systems), threats (unauthorized disclosure, vendor misuse, insider error), and existing controls, then score residual risk and prioritize remediation by impact and likelihood.

PTAC's data governance framework recommends documenting decision protocols for each data use, particularly when identifiable data are involved. That documentation becomes the primary evidence of a proactive, transparent privacy program during any external review.

How do you train school staff on data privacy responsibilities?

Training is the control that makes every other control work. A well-designed access control system fails the moment a staff member shares their credentials. A carefully negotiated DSA fails the moment a teacher forwards a student's records to an unauthorized party without realizing it.

Effective privacy training for school staff has three characteristics: it is role-specific, it uses realistic scenarios, and it is repeated annually with updates when laws or district policies change.

Role-specific training modules:

• Teachers and instructional staff: FERPA basics, what constitutes an education record, how to handle parent requests, and what to do before adopting a new classroom app.
• School administrators: Annual FERPA notice obligations, directory information opt-out management, and how to respond to a records request.
• IT staff: Technical controls rationale, access provisioning procedures, incident detection and response, and vendor onboarding checklist.
• Front office and counseling staff: Disclosure rules for third parties (coaches, employers, colleges), health and disability record handling, and PPRA survey procedures.

Scenario-based training consistently outperforms policy-reading exercises. Present staff with realistic situations: "A parent calls asking for their child's grades. The student is 19. What do you do?" or "A vendor emails asking for a student roster to 'test their integration.' What is your response?" Those scenarios surface gaps that policy documents never reveal.

Document every training session: date, attendees, content covered, and the trainer or platform used. That log is a core artifact in any FERPA compliance review, and it demonstrates that your "reasonable methods" posture includes human controls, not just technical ones.

Key Takeaways

Effective student data privacy in K–12 schools requires a documented, operational program built on a current data inventory, written vendor agreements, role-based access controls, annual staff training, and transparent family communication.

30/60/90-day implementation plan:

• Days 1–30: Complete the data inventory, identify vendors without signed DSAs, and issue the annual FERPA notice if overdue.
• Days 31–60: Execute DSAs with all active vendors, deliver role-specific staff training, and publish or update the plain-language family notice.
• Days 61–90: Conduct the first privacy audit, complete a risk assessment, and assign a privacy lead with a documented governance charter.

The balance between privacy and edtech innovation

The tension between adopting useful AI tools and protecting student data is real, but it is not irresolvable. The schools that navigate it well share one habit: they treat privacy governance as a procurement function, not a legal afterthought.

When a district evaluates an AI grading platform, the privacy review should happen before the pilot, not after the contract is signed. That means requiring a draft DSA at the RFP stage, asking explicit questions about model training practices, and confirming that the vendor can purge individual student records on request. Those are not unreasonable demands. They are the minimum standard for any vendor that processes student PII.

The practical reassurance here is that privacy-first AI adoption is achievable. Assignify is designed with compliant data handling as a core requirement, not a feature added after the fact. When you pilot AI for grading handwritten STEM assignments, the governance questions are the same as for any other edtech vendor: What data does the system process? Under what DSA terms? And can you get it back or deleted when the contract ends? Answering those questions before deployment is what separates a defensible program from a liability.

Educators deserve tools that reduce the cognitive burden of grading without creating new privacy risks. That balance is achievable when procurement, IT, and instructional staff work from the same governance framework. Our guide to FERPA-compliant AI grading workflows covers the vendor questions in more depth, and the cognitive cost of manual grading explains why districts are evaluating these tools in the first place.

Useful sources and further reading

• Protecting Student Privacy, U.S. Department of Education (StudentPrivacy.ed.gov): the central hub for FERPA and PPRA guidance, model agreements, training resources, and direct technical assistance from PTAC.
• FERPA Frequently Asked Questions, DOE/PTAC: authoritative answers to the most common FERPA questions, including annual notice requirements, directory information opt-outs, and eligible student rights.
• FERPA Statute, 20 U.S.C. § 1232g: the primary statutory text of FERPA, useful for verifying the scope of parental rights and the conditions on fund availability.
• Data Security: K–12 and Higher Education, DOE/PTAC: vendor procurement guidance, model DSA components, and data security resources for school technology leaders.

For direct technical assistance, submit a request through StudentPrivacy.ed.gov. PTAC support is free and available to any school or district navigating FERPA compliance, vendor agreements, or data governance questions.

This article provides general informational guidance on student data privacy law and is not legal advice. Confirm current requirements with your state education agency, legal counsel, or the U.S. Department of Education's Student Privacy Policy Office.