SOC 2 by industry
SOC 2 for edtech: a report shaped by student records and school buyers.
An edtech product holds data about people who cannot sign a contract: pupils, many of them minors. Schools, districts and universities buy on behalf of those people, and their reviewers ask sharper questions about who can see a learner's record than most commercial buyers do. This guide sets out what an edtech SOC 2 should cover, where the scope usually goes wrong, and how the report sits beside student-privacy law.
Back to SOC 2 services01 · Who asks
Who asks edtech companies for a SOC 2 report
The buyer decides the scope and the weight of the report, so start with who is asking.
| Asked by | What they want to see |
|---|---|
| School district technology or privacy office | A signed data privacy agreement, plus proof that staff access to student records is limited, logged and removed on time. |
| University information security team | A Type 2 report covering the single sign-on integration, the learning-tool connection and the hosting environment. |
| Ministry, state agency or education authority | Where student data is stored, which sub-processors touch it, and how a breach would be reported to them. |
| Corporate learning buyer | Ordinary enterprise questions: access reviews, encryption, uptime during training rollouts. |
| Reseller or content partner | Assurance that their content and their learners' progress data are kept apart from other partners'. |
02 · What is in scope
What sits inside the system boundary
The report covers one system. In this sector the boundary usually takes in:
- Learner records
- Names, grades, assessment answers, attendance and progress: the education record a school expects you to guard on its behalf.
- Rostering sync
- The connection that pulls class lists from the school's student information system, including its credentials and its error handling.
- Teacher and admin consoles
- Where staff view and export data. Exports are the most common path for student data to leave the system.
- Assessment and proctoring features
- Recordings, screenshots or keystroke data, if you collect them, sit in scope and raise the sensitivity of the whole system.
- Support tooling
- The help desk and the impersonation or view-as-user feature support staff use to see what a teacher sees.
03 · Categories
Which Trust Services Categories matter here
Security is always in. The rest depend on what you promise customers.
| Category | Weight in this sector | Why |
|---|---|---|
| Security | Always | Required in every report; for schools it is mostly read as access to learner records. |
| Privacy | Often | Chosen when you collect data from or about learners directly and make commitments on notice, consent and deletion. |
| Confidentiality | Often | Covers assessment content, item banks and school data you promise to destroy at contract end. |
| Availability | Sometimes | Matters when the product runs live lessons or exams and an outage stops a class. |
| Processing Integrity | Rarely | Considered when you compute grades or scores that a school relies on as official results. |
04 · Vendors in the report
The vendors that appear in your report
Each one is a subservice organization or a carve-out, and the report has to say which.
- Cloud host
- Usually carved out; the report names the region and relies on the host's own report for physical and platform controls.
- Identity and rostering connectors
- Third-party sync services that move roster data are often carved out, with monitoring controls on your side for their reports and their failures.
- Video and proctoring providers
- If recordings pass through them, buyers expect to see them named as subservice organizations, not left out.
- Email and messaging services
- Parent and learner notifications go through them; name the data they receive and keep it to the minimum.
05 · Sector controls
Controls that this sector makes necessary
Examples only. Your own wording is what the auditor tests.
- S.1Tenant-per-school access boundaryTeachers see only learners rostered to their classes; cross-school access requires a documented admin role.
- S.2Student data export loggingEvery bulk export from a staff console is logged with the user, the scope and the time, and reviewed periodically.
- S.3Impersonation approvalSupport staff can view as a teacher only with a ticket reference, and every session is recorded.
- S.4Contract-end deletionWhen a school's agreement ends, its learner data is deleted or returned within the agreed window and a destruction record is kept.
- S.5Age-aware sign-upDirect sign-up flows check age and route younger learners to a school- or parent-authorised path.
- S.6Roster sync failure alertsFailed or partial roster syncs raise an alert, so learners aren't left in, or dropped from, the wrong class.
06 · Traps
Where companies in this sector slip
Predictable, and cheaper to fix before fieldwork.
- Leaving the support view-as feature out of scope. It is the widest access path to learner data in many products. If it isn't described, the description misleads.
- Calling the report a FERPA attestation. SOC 2 tests your controls against the Trust Services Criteria, not against any student-privacy law.
- Promising deletion you can't evidence. A district agreement may promise deletion at contract end. The auditor will sample ended contracts and ask for proof.
- Ignoring backups in the deletion story. If backups keep learner data for longer than the agreement allows, the commitment needs to say so.
- Treating a pilot school as out of scope. Pilot data is still real student data, on the same system, under the same promises.
07 · District reviews
How a district privacy review reads your report
District reviewers usually hold the report and the privacy agreement side by side.
A district reviewer rarely reads the whole report. They look for the promises in their agreement and check whether the report tests a control behind each one. Where a promise has no control, they ask for a separate answer, and the review slows.
| Promise in the agreement (illustrative) | Where the report should answer it |
|---|---|
| Data used only to provide the service | System description: data use and commitments; Privacy criteria if in scope |
| No sale or advertising use of student data | Commitments section of the description, plus the control that restricts data sharing |
| Deletion at the end of the contract | Confidentiality or Privacy disposal control, with sampled destruction records |
| Notice of a breach within the agreed time | Incident response controls under CC7, and the notification procedure |
| Named sub-processors | The subservice organizations listed in the description |
Write commitments in the description in the same words your standard agreement uses. The reviewer then finds them quickly.
08 · Evidence
Evidence to have ready
What an auditor will ask for, in the order they usually ask.
- The system description, with learner data and the rostering flow drawn in
- Role definitions for teacher, school admin, district admin and support
- Export logs and the record of their periodic review
- Impersonation session logs tied to support tickets
- Destruction records for agreements that ended in the period
- The sub-processor list and the monitoring done on each
- Roster sync alert history and how failures were resolved
Student-privacy law sits beside the report
In the US, FERPA governs how schools share education records, usually letting a vendor act as a school official under the school's direct control, and COPPA governs collecting personal information from children under 13 online. Many states add their own student-privacy statutes. A SOC 2 can show the controls that support those duties; it is not a finding of compliance with any of them.
Sources: AICPA Trust Services Criteria (TSP section 100, 2017, revised points of focus 2022); AICPA description criteria (DC section 200); AICPA SOC 2 guide; US Family Educational Rights and Privacy Act (34 CFR Part 99); Children's Online Privacy Protection Rule (16 CFR Part 312).
More about SOC 2 for edtech
Our buyers are schools, not companies. Will they even read a SOC 2?
Larger districts and universities usually do.
Smaller schools often rely on a privacy agreement and a questionnaire. Larger districts, state bodies and universities commonly ask for the report and read it against the agreement. Having one shortens those reviews; it does not replace the agreement.
Do we need the Privacy category if we only process data on a school's instruction?
Not always; Confidentiality may fit better.
When the school collects the data and you process it on its behalf, many edtech companies cover the handling under Security and Confidentiality. Privacy becomes more relevant when you collect directly from learners or parents and make notice and consent commitments to them.
Are assessment recordings a bigger scoping question than grades?
Usually, yes.
Recordings and screen captures can show a learner's face, home and voice. They tend to sit with a third-party provider, have their own retention rules and draw the most reviewer questions. Decide early whether that feature is inside the boundary.
Can a pilot run before the report is ready?
Yes, with honest wording.
Many districts accept a pilot on a signed agreement and a questionnaire. Describe your status accurately, for example a readiness assessment complete and an observation period under way, rather than implying a report exists.
Scope your edtech SOC 2 around what buyers ask.
A readiness assessment turns this into your boundary, your categories and your gaps.