FERPA vs COPPA vs State Student Privacy Laws: A K12 Decision Tree
School districts are under growing pressure to approve digital tools quickly while still protecting student privacy. The hard part is not simply whether an app seems safe. The hard part is knowing which rules apply, what questions to ask, and what documentation is needed before student data is collected or shared.
This decision tree is designed for K12 superintendents, technology leaders, curriculum teams, and school privacy teams who need a practical way to triage tools and make defensible approval decisions.
Key idea: FERPA, COPPA, and state privacy requirements can overlap, but they have different triggers and obligations. Determine which apply to the product and intended use, and then document data minimization, permitted purposes, security, transparency, retention, and any required agreements. This is a screening guide, not a substitute for legal advice.
Plain language refresher
FERPA in one sentence
FERPA protects the privacy of education records at educational agencies and institutions receiving funds under programs administered by the U.S. Department of Education. Education records generally are directly related to a student and maintained by the school or a party acting for it. See the Department of Education’s definition of education records.
COPPA in one sentence
COPPA imposes requirements on covered online-service operators collecting personal information online from children under 13. Schools may provide consent in qualifying educational circumstances, but that consent is limited to the authorized educational purpose. See the FTC’s COPPA FAQs, section N.
State student privacy laws in one sentence
State laws often add vendor restrictions, contract requirements, transparency obligations, breach duties, and governance rules that can be more specific than federal law.
The K12 decision tree: numbered step flow
Use these steps in order. The goal is not to produce a perfect legal analysis. The goal is to reach a clear approval path and document the reasoning so your district can explain the decision later to staff, families, auditors, or regulators.
Step 1: Is the tool used for a school purpose
- School purpose: The tool is used for instruction, assessment, student services, communications, or operations.
- Personal purpose: The tool is used independently by families outside a school assigned context.
If school staff select, require, recommend for assigned work, or integrate a service into instruction or operations, send it through the district’s approval process. A purely independent family use is different; determine the school’s actual role rather than assuming that any family-used app is district-approved.
Step 2: Does the tool collect or access student information
Ask a simple question: does this tool collect, store, or transmit any data that identifies a student, can be linked to a student, or describes a student school experience.
If yes, continue. If no identifiable student information is collected or disclosed, a lighter privacy review may be appropriate—but verify identifiers, analytics, integrations, and the specific deployment before making that determination.
Tip: Student information is broader than names and grades. It can include device identifiers, IP addresses, chat logs, photos, voice recordings, usage analytics, and free form notes.
Step 3: Is the district sharing education record data, or is the student entering data directly
This is a practical turning point for FERPA analysis. Many tools do both.
- District to vendor: roster data, identifiers, grades, schedules, or other data from district systems.
- Student to vendor: student created content, messages, uploads, recordings, or AI prompts.
FERPA does not automatically apply to every student-entered prompt, chat, or upload. Determine whether the information is personally identifiable information from education records or becomes a record directly related to a student that is maintained by the school or a party acting for it. When the school discloses education-record information to a vendor, identify an applicable FERPA consent exception or obtain the required consent; if relying on the school-official exception, verify direct control over use and maintenance, legitimate educational interest, and limits on redisclosure. See the Department of Education’s guidance for classroom apps.
Step 4: Are any users under 13
If children under 13 will use the service, determine whether COPPA covers the operator and whether it collects personal information online from those children. Examine personal information broadly, including persistent identifiers and data collected by integrated technologies. If the district plans to provide school consent, confirm that the vendor uses the information only for the school-authorized educational purpose, provides the required notice and review/deletion controls, and does not rely on school consent for unrelated commercial use.
School consent under COPPA does not replace a signed Data Privacy Agreement when state law requires one. A vendor’s COPPA compliance claim also does not establish that the app is appropriate for the district’s intended use. Review the FTC’s school-consent guidance and your state’s separate contracting obligations.
Step 5: Does the tool involve high risk activities
If any of these are true, elevate to deeper review and require stronger vendor commitments:
- Targeted advertising or tracking across sites
- Sale of data or sharing for non educational purposes
- Student profiling beyond what is needed for school use
- AI features that store prompts or use data to improve models beyond the school purpose
- Sensitive data types such as health, disability, discipline, counseling notes, custody flags, or precise location
- Deep integrations with SIS, SSO, rostering, or email
Practical rule: for sensitive data or deep integrations, require strong vendor assurances, clear retention and deletion limits, documented permissions, and a signed agreement wherever legally required or appropriate under district policy. Verify actual enabled integrations rather than assuming every optional connection is active.
Step 6: Identify which state rules apply where you operate
State student privacy laws can impose additional restrictions on data use, required contract terms, notice, security, deletion, and public transparency. Do not rely on COPPA school consent alone to authorize a tool where state law requires a signed DPA or other specific safeguards. Review the laws applicable to the district and the proposed data processing.
If you want examples, start with your state guides and compare how expectations differ:
- Texas State Guide
- Florida State Guide
- Illinois State Guide
- New York State Guide
- California State Guide
Vendors may offer agreements covering multiple states, but the district should verify that the signed agreement actually covers its jurisdiction, product, data uses, and required contractual terms. A vendor’s national presence is not itself evidence of state-law compliance.
Step 7: Choose and document the approval path
Use risk tiers to determine the depth of review, then record a final decision such as approve, approve with restrictions, hold pending evidence or contract, or do not approve. Risk tier alone does not authorize the application. Suggested review tiers:
- Low risk review: minimal student data, no sensitive categories, no deep integrations.
- Standard approval review: roster data and identifiers, student content, moderate integrations.
- High risk review: sensitive data, AI logs, unclear sharing, districtwide deployment, core operational dependency.
For every decision, identify the approving staff member, intended grade levels and use, applicable privacy laws, agreement status, permitted data, restrictions, unresolved questions, and next review date. Re-evaluate material changes to the product, vendor terms, AI functionality, or data-sharing practices.
What to ask vendors before approval
These questions help you cover FERPA, COPPA, and state governance expectations in one workflow.
Data collection and purpose
- What data elements do you collect from students and parents
- Which elements are required vs optional
- What is the educational purpose for each category
- Do you use data for analytics or AI training beyond the school purpose
Sharing and subprocessors
- Do you share data with any third parties or subprocessors
- Provide a current subprocessor list and the purpose of each
- How do you notify districts of subprocessor changes
Security controls
- Do you support multifactor authentication for district admins
- How is data encrypted in transit and at rest
- What logging and monitoring exists for suspicious access
- What is your incident response process and customer notification timeline
Retention and deletion
- How long do you retain data
- What happens when a student leaves a district
- What happens at contract end
- Do you provide deletion certification
Common red flags that should pause approval
- Privacy policy allows broad sharing for marketing, advertising, or "business purposes"
- No clear retention schedule or deletion process
- No subprocessor list or no notice of changes
- Vague language about using student data to improve services or train models
- Tool requires sensitive data types that are not necessary for the educational purpose
FAQ
Do we need a signed agreement for every tool?
Not necessarily. Contract requirements depend on applicable state law, the product, information involved, the vendor’s role, and the district’s policies. If state law requires a DPA, COPPA school consent cannot substitute for that agreement. Even when a DPA is not legally mandated, a written agreement can help establish permitted use, security, retention, deletion, and vendor accountability.
What is the simplest way to reduce risk quickly
Start with data minimization and retention. Collect less. Keep less. And require vendors to show how deletion works. These changes reduce the blast radius of any incident.
Use the checklist above as an intake tool, then record the supporting evidence and any conditions of approval in your district’s established review process.
Put Your Student Privacy Decision Process Into Practice
EdPrivacy helps districts evaluate vendor privacy practices, manage agreements, document approval decisions, and monitor vendor privacy policy changes. Districts can review AI and accessibility concerns within the same technology approval workflow, while still applying their own legal and policy requirements.
Want to see how a real application review works? Start your free EdPrivacy trial and review an application your district uses. No credit card required.
