SOC 2 for EdTech: What We Tell Education Technology Companies About Compliance

After guiding dozens of EdTech companies through SOC 2, we have seen firsthand how student data requirements reshape every aspect of the compliance journey. This guide captures what we consistently advise our education technology clients — from navigating the FERPA-COPPA intersection to building the controls that school district procurement teams actually scrutinize.

Education technology companies handle some of the most regulated data in the SaaS landscape — student personally identifiable information (PII), learning records, assessment results, behavioral data, and in many cases, data belonging to minors under thirteen. School districts, universities, and state education agencies increasingly require SOC 2 reports from EdTech vendors as part of their procurement process, driven by growing concern over student data privacy, high-profile data breaches in education, and the expansion of state student privacy laws. We consistently advise our EdTech clients that their SOC 2 program must address not only standard security controls but also the regulatory intersection with FERPA, COPPA, and the patchwork of state student privacy legislation that governs how student data is collected, used, and shared.

This guide covers SOC 2 compliance specifically for education technology companies serving K-12 schools, higher education institutions, and corporate training markets. It addresses the regulatory landscape, Trust Service Criteria selection for EdTech, student data handling requirements, how school district and university procurement teams evaluate EdTech vendor SOC 2 reports, and the specific controls that distinguish an EdTech SOC 2 program from a general SaaS program.

The Regulatory Landscape for EdTech

FERPA (Family Educational Rights and Privacy Act)

FERPA governs the privacy of student education records at institutions receiving federal funding. When an EdTech company processes student data on behalf of a school, the company operates as a "school official" under FERPA and must handle student education records in accordance with the law.

FERPA Requirement	Impact on EdTech SOC 2
Student data used only for authorized educational purposes	SOC 2 controls must demonstrate data use limitations and access restrictions
No unauthorized disclosure of student records	Access management and confidentiality controls must prevent unauthorized data access and sharing
Parents have right to inspect education records	Platform must support data access requests
Schools retain ownership and control of student data	Data handling controls must reflect school ownership; deletion and export capabilities required
Data security requirements	Security controls must protect student education records throughout their lifecycle

COPPA (Children's Online Privacy Protection Act)

COPPA applies to EdTech companies that collect personal information from children under thirteen. For K-12 EdTech platforms, COPPA compliance is often required because the student population includes children in this age range.

COPPA Requirement	Impact on EdTech SOC 2
Verifiable parental consent before collecting personal information from children	Privacy controls must include consent management mechanisms
Limitations on data collection to what is necessary	Data minimization controls must be documented
Parental access to collected information	Platform must support parental data access
Data deletion upon request	Data retention and deletion controls must be operational
Reasonable security measures	Security controls must be appropriate for the sensitivity of children's data

State Student Privacy Laws

Over forty US states have enacted student privacy legislation that adds requirements beyond FERPA and COPPA. Common state law requirements include:

• Prohibition on using student data for targeted advertising
• Requirements for data breach notification to parents and schools
• Data deletion requirements when contracts end
• Restrictions on selling student data
• Transparency requirements about data collection practices
• Vendor compliance certification obligations

The Student Privacy Pledge, administered by the Future of Privacy Forum, provides a voluntary framework that many EdTech companies sign to demonstrate commitment to student privacy. While not legally binding in the same way as FERPA or COPPA, school districts increasingly reference the pledge during vendor evaluation.

Trust Service Criteria for EdTech

Recommended Criteria

Criterion	Recommendation	EdTech-Specific Rationale
Security (Common Criteria)	Required	Mandatory baseline; covers access controls, change management, and incident response for student data
Availability	Strongly recommended	Classroom-dependent tools must be available during school hours; downtime disrupts teaching and learning
Confidentiality	Required	Student data confidentiality is a core obligation under FERPA, COPPA, and state laws
Privacy	Strongly recommended	EdTech companies process student personal information; Privacy criteria align with FERPA and COPPA requirements
Processing Integrity	Situational	Required for assessment platforms, grade management systems, and learning analytics where data accuracy affects student outcomes

Why Availability Matters for EdTech

EdTech platform availability has direct educational impact:

• Classroom disruption: When a learning management system (LMS), assessment platform, or classroom tool goes down during school hours, teachers cannot deliver planned instruction
• Assessment integrity: Testing platforms must be available during scheduled assessment windows — downtime can invalidate test results or require rescheduling
• Learning continuity: Students relying on EdTech platforms for homework, assignments, and study materials need consistent access
• District-wide impact: A single EdTech platform may serve thousands of students across a district — downtime affects the entire educational community

We recommend documenting the following Availability controls:

• Uptime commitments appropriate for educational use (availability during school hours across US time zones)
• Capacity planning for peak periods (back-to-school, standardized testing windows, end-of-term)
• Redundancy mechanisms that maintain service during infrastructure failures
• Communication procedures for notifying districts and schools of planned or unplanned downtime

Why Privacy Is Important for EdTech

The Privacy criterion is more relevant for EdTech companies than for most SaaS verticals because:

• Student personal information is subject to specific privacy regulations (FERPA, COPPA, state laws)
• School districts and parents are increasingly sensitive to how student data is used
• Privacy violations involving children's data carry significant reputational and regulatory consequences
• Including the Privacy criterion demonstrates proactive commitment to student privacy beyond minimum legal requirements

EdTech-Specific Controls

Student Data Handling

Control Area	What to Implement
Data purpose limitation	Technical and administrative controls ensuring student data is used only for authorized educational purposes — no use for advertising, marketing, or purposes beyond the educational service
Data minimization	Collect only the student data necessary for the educational service; document what data is collected and why
Data retention and deletion	Defined retention periods for student data; automated or procedural deletion when retention period expires or contract ends; ability to delete data upon school request
Data portability	Ability to export student data in a standard format upon school request; supports school's ownership of student data
Age-appropriate data handling	Differentiated data handling procedures for students under thirteen (COPPA requirements) versus older students
Parental and school access	Mechanisms for parents and schools to access, review, and request deletion of student data

Access Management for Student Data

Control	EdTech-Specific Requirement
Role-based access by educational role	Access differentiated by role — teacher (access to own students), administrator (access to school/district data), student (access to own records), parent (access to child's records)
Teacher-student data boundaries	Teachers can access only their assigned students' data; cross-classroom access restricted
District data isolation	Multi-district platforms must isolate data between districts — one district cannot access another's student data
Student data access logging	Comprehensive logging of all access to student records for FERPA compliance and audit purposes
Minimum necessary access	Access limited to the minimum data necessary for each role's educational function

Assessment and Grade Data Integrity

For EdTech companies that process assessments, grades, or learning analytics:

Control	Purpose
Assessment data immutability	Once submitted, assessment responses and scores are protected from unauthorized modification
Grade calculation accuracy	Automated grade calculations are validated for accuracy; manual overrides are logged
Score transmission integrity	Assessment scores transmitted between systems (LMS, SIS, state reporting) maintain accuracy throughout the data flow
Testing environment security	Online assessment environments include controls preventing unauthorized access to test content and student responses

Incident Response for Student Data

Student data breaches carry unique requirements:

Requirement	Detail
School notification	Notify affected schools within contractual timeframe (typically twenty-four to seventy-two hours)
Parent notification	Support schools in notifying parents of affected students per state law requirements
Regulatory notification	Comply with state breach notification laws specific to student data
Incident documentation	Document the scope of student data affected, root cause, and remediation for school review
Post-incident cooperation	Cooperate with school districts' own incident response and investigation procedures

How Education Procurement Teams Evaluate SOC 2 Reports

K-12 School District Procurement

School district technology directors and IT coordinators evaluate EdTech SOC 2 reports with particular attention to:

Evaluation Focus	What They Look For
Student data protection	Controls specifically addressing student PII, education records, and age-appropriate data handling
FERPA alignment	Evidence that the SOC 2 program addresses FERPA requirements for data use limitation, access restrictions, and school data ownership
Data deletion capability	Confirmation that student data can be deleted when the contract ends or upon school request
Availability during school hours	Uptime commitments and incident communication procedures relevant to school operating hours
Third-party data sharing restrictions	Controls preventing student data from being shared with unauthorized third parties
Privacy criterion inclusion	Many districts specifically look for the Privacy criterion in EdTech vendor SOC 2 reports

Higher Education Procurement

Universities and colleges evaluate EdTech SOC 2 reports with broader security expectations:

Evaluation Focus	What They Look For
Integration security	Controls for integrating with campus identity systems, student information systems (SIS), and LMS platforms
Research data handling	Controls for handling potentially sensitive research data (if the EdTech platform supports research functions)
FERPA compliance	Student data protection aligned with FERPA requirements for higher education records
Multi-institution data isolation	For platforms serving multiple institutions, clear tenant isolation and data segregation controls
Accessibility compliance	While not part of SOC 2, universities often evaluate accessibility alongside security during procurement

State Education Agency Requirements

State education agencies that manage state-level educational technology contracts often require:

• SOC 2 Type II report covering Security, Availability, and Confidentiality at minimum
• Evidence of FERPA compliance alignment
• State-specific student privacy law compliance
• Data residency documentation (where student data is stored and processed)
• Penetration testing results
• Incident response and breach notification procedures

Building an EdTech SOC 2 Program

Implementation Priority Order

Based on what we see working with EdTech clients, we recommend the following priority order:

Priority	Control Area	Why First
1	Student data access management	FERPA compliance and the highest-scrutiny control area for EdTech
2	Data purpose limitation and minimization	Core regulatory requirement; districts evaluate this closely
3	Encryption for student data at rest and in transit	Baseline protection for sensitive student information
4	Multi-tenant data isolation	Districts must be confident their data is separated from other customers
5	Monitoring and logging of student data access	FERPA audit trail requirements; essential for incident investigation
6	Data retention and deletion controls	Contract-end data handling is a top district concern
7	Availability and capacity planning	Classroom-dependent tools must be reliable during school hours
8	Incident response with school notification	Districts need confidence in rapid breach notification

Complementary Certifications and Attestations

In our experience, EdTech companies that pursue additional certifications alongside SOC 2 strengthen their position during procurement:

Certification	Purpose	Relationship to SOC 2
Student Privacy Pledge	Voluntary commitment to student privacy best practices	Demonstrates privacy commitment; referenced during procurement
iKeepSafe COPPA Safe Harbor	COPPA compliance certification	Addresses COPPA specifically; complements SOC 2 Privacy criterion
1EdTech (IMS Global) certification	Interoperability standards compliance	Addresses integration standards; separate from SOC 2
State-specific certifications	Various state student privacy certifications	Addresses state law compliance; complements SOC 2

Key Takeaways

• We consistently see that EdTech SOC 2 programs must address the regulatory intersection with FERPA, COPPA, and state student privacy laws — standard SOC 2 controls alone are not sufficient
• What we recommend: include Security, Availability, Confidentiality, and Privacy at minimum — school districts increasingly expect the Privacy criterion from EdTech vendors
• In our experience, student data handling controls (purpose limitation, minimization, retention, deletion, portability) are where EdTech programs diverge most from general SaaS SOC 2
• We advise all EdTech clients to build access management that differentiates by educational role (teacher, administrator, student, parent) with appropriate data boundaries
• Availability is critical for classroom-dependent tools — we have seen district relationships damaged by downtime during school hours
• What we tell every EdTech client: data deletion capability when contracts end is a top concern for school district procurement teams
• K-12 districts focus on FERPA alignment, student data protection, and data deletion; universities add integration security and research data handling
• We recommend treating multi-tenant data isolation between districts as non-negotiable — one district must never access another's student data
• Over forty US states have enacted student privacy laws creating a patchwork of requirements beyond FERPA and COPPA — we help clients map these to their SOC 2 controls
• Student data breaches require school notification within contractual timeframes and may require parent notification per state law

Frequently Asked Questions

Does SOC 2 satisfy FERPA requirements?

What we tell clients is that SOC 2 does not directly satisfy FERPA — they are different frameworks with different requirements. However, a SOC 2 program with appropriate EdTech-specific controls (data purpose limitation, access restrictions, deletion capability) demonstrates many of the security safeguards FERPA requires for school officials handling student data. Based on what we see in procurement cycles, school districts view SOC 2 as complementary to FERPA compliance, not a substitute for it. Your SOC 2 report provides independent verification of security controls that support your FERPA obligations.

Do EdTech companies need the Privacy criterion?

Based on what we see advising K-12 EdTech companies, we strongly recommend including the Privacy criterion. It covers personal information lifecycle management (notice, consent, collection, use, access, disclosure, disposal) that aligns with FERPA and COPPA requirements. School districts increasingly look for the Privacy criterion when evaluating EdTech vendor SOC 2 reports. For higher education EdTech, the Privacy criterion is less commonly required but still valuable for demonstrating comprehensive data governance.

How does COPPA affect our SOC 2 program?

What we tell clients is that if your platform collects personal information from children under thirteen (most K-12 EdTech platforms do), COPPA adds specific requirements: verifiable parental consent mechanisms, data minimization, parental access to collected information, and data deletion upon request. We recommend that your SOC 2 Privacy and Confidentiality controls incorporate these COPPA-specific requirements. In our experience, some EdTech companies pursue separate COPPA Safe Harbor certification alongside SOC 2 to specifically address COPPA compliance.

What do school districts care about most in our SOC 2 report?

Based on what we see across dozens of district procurement reviews: (1) student data access controls with role-based restrictions, (2) data deletion capability when contracts end, (3) data purpose limitation (student data used only for educational purposes), (4) breach notification procedures, and (5) availability during school hours. What we consistently hear from procurement teams is that they care less about the auditor's brand and more about whether the controls specifically address student data protection. A SOC 2 report that covers general SaaS security without EdTech-specific controls may be viewed as insufficient.

Should an EdTech company pursue SOC 2 or a student privacy certification first?

What we recommend is pursuing SOC 2 first. SOC 2 provides the broadest security attestation recognized across all buyer types — school districts, universities, corporate training buyers, and enterprise education departments. Student privacy certifications (Student Privacy Pledge, iKeepSafe COPPA Safe Harbor) are complementary and should be pursued alongside or after SOC 2. In our experience, the SOC 2 program establishes the security infrastructure that supports all other compliance efforts.