Does a SOC 2 report satisfy a school district's vendor review?
A SOC 2 report is independent evidence that a service organization's controls were designed and operated as described, but it does not by itself establish FERPA compliance. FERPA places duties on the school and on how the vendor uses and maintains education records, and a district's vendor review asks questions that a SOC 2 report only partly answers, such as where student data is processed, who can see it, and what happens to it at the end of the contract. The organization owns its controls and the data practices behind them. An implementation partner such as DeployOpen can prepare systems, policies and evidence, but only an independent CPA firm issues the SOC 2 report, and a district should read the report as one input to its review rather than as a finished answer.
What a district needs from the report changes with each contract. Some districts sign standard terms and some negotiate a data privacy agreement, and the data categories in scope, such as student names, grades, behavioral notes or health information, determine which controls matter most. Privacy criteria are only in a report when the vendor has included them in scope, so a district handling personal information should check whether the examination covers the privacy category and whether the system description reflects the student data flows it actually uses. Districts also differ in their own vendor review checklists, often asking for a security plan, breach procedures and a data destruction plan with a timeline and method. Before sending a report, the vendor should confirm the examined period, the scope of the system, and which of those district questions the report does not address, so the gaps are answered in writing rather than discovered during procurement.
What schools can ask edtech vendors for
The Department of Education's vendor guidance describes what schools may ask for before and during a relationship with an edtech provider. Each card below pairs one of those expectations with the part of a SOC 2 report or supporting document that addresses it, and notes where a SOC 2 report stops short.
Transparency about data use
Schools may require clear information about how student data are used, including which features process it, which subprocessors touch it and whether it trains any model. A SOC 2 report describes the system and its commitments but rarely lists every data use in plain language. Check the system description for the data flows and purposes, then compare them with the privacy notice and the data processing terms the school signs. Confirm that the privacy criteria in scope cover notice and use.
Data security and confidentiality plans
A school will expect a written plan for protecting student records, covering access, encryption, staff confidentiality obligations and how those controls are reviewed. The Common Criteria (CC6 logical access and CC5 control activities) and the confidentiality category, if in scope, are the usual places a SOC 2 report evidences this. Ask whether the report's scope includes the product the school actually uses, not only the parent company's platform.
Evidence of direct control
Under FERPA's school official exception, the school must keep direct control of its records at all times. The guidance warns that vendors changing terms of service without notice make that control hard to show. A SOC 2 report does not prove contract control. Provide change-notice commitments, a record of how the school can access, correct and export its data, and a contract that requires consent for material changes.
Security plan with checks and controls
The guidance says providers should maintain a security plan with a system of checks and controls. This is the closest match to a SOC 2 Type 2 report, which gives an auditor's opinion on whether controls operated over a period. Read the report's exceptions and the complementary user entity controls section, because the school may have obligations the report expects it to meet. Ask for the report's period and bridge letter if it is stale.
Agreed breach procedures
Schools will want written breach procedures that set notification timing, contacts and cooperation duties. SOC 2 incident response criteria in CC7 show that a process exists and was tested, but the notification commitments themselves belong in the contract or data processing agreement. Confirm that the vendor's incident response plan matches the timelines promised to the school, and that the school's contract names the same people and channels.
Data destruction and periodic privacy audits
The guidance expects a data destruction plan with a timeline and method, and it suggests periodic privacy audits. The privacy criterion P4.3 and confidentiality criterion C1.2 both require secure disposal in line with stated objectives, which a SOC 2 can test. Ask for the retention schedule, the disposal method and certificates of destruction for backups. Recognize that a SOC 2 report is a periodic attestation, not a continuous privacy audit by the school.
Which SOC 2 criteria fit student data
Every SOC 2 examination, whatever the categories in scope, is built on the common criteria CC1 to CC9. They cover the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation. For an edtech vendor, these criteria describe how the company protects the platform and the student records stored in it from unauthorized access, and they form the foundation the privacy and confidentiality criteria build on.
- Access controls (CC6): how staff and vendor personnel are granted, reviewed and removed from systems that hold student records.
- Vendor and partner risk (CC9.2): how the company oversees hosting providers, analytics tools and other subservice organizations that touch student data.
- Incident response (CC7): how security events involving student records are detected, escalated and recovered.
- Change management (CC8): how software and configuration changes to the learning platform are approved, tested and deployed.
Before relying on a report, check whether the security baseline was tested over a period and whether the vendor's system description names the student data stores and the systems that process them.
The privacy category, P1 to P8, is added to a SOC 2 only when the vendor commits to it. It covers notice, choice and consent, collection, use, retention and disposal, access, disclosure and notification, quality, and monitoring and enforcement. When privacy is in scope, nine common criteria also carry additional points of focus: CC1.3, CC1.5, CC2.2, CC2.3, CC6.1, CC7.3, CC7.4, CC8.1 and CC9.2. These points of focus help a vendor show how privacy commitments to schools are built into governance, access, incident handling and change control.
- Use and retention (P3 to P4): how student personal information is limited to the purposes the school authorized and kept no longer than agreed.
- Disclosure (P6): how the vendor controls onward sharing with subprocessors and any third party.
- Secure disposal (P4.3): the requirement to dispose of personal information securely in line with the privacy objectives, which schools typically test through the destruction plan.
- Notification (P6.x and CC7.3 to CC7.4): how breaches involving student data are identified and reported under the agreed procedures.
Check that the privacy criteria in the report match the commitments in the vendor's contract and privacy notice, not only the marketing description.
The confidentiality category adds two criteria, C1.1 and C1.2. C1.2 requires the organization to dispose of confidential information in line with its confidentiality objectives. Confidentiality is useful for edtech vendors whose contracts treat student records, assessment data or school information as confidential even where a privacy commitment is not made. It is often the right category for vendors whose main concern is protecting school data from disclosure, while privacy is added when the vendor handles personal information directly.
- Identifying confidential data: a documented classification that marks school records, grades and assessment results as confidential.
- Protection in transit and at rest: how that data is encrypted and how access to it is limited by role.
- Disposal (C1.2): the commitment to remove confidential information when the school ends the contract or the data is no longer needed.
- Contract alignment: whether the confidentiality commitments in the report match the data handling terms the school signed.
Ask the vendor which categories it chose, why, and whether the chosen categories cover every data type the school will upload.
Which report a district can use: Type 1, Type 2 or SOC 3
This table compares the three SOC 2 report types a vendor may hold, with the audience each one usually serves in a school or district review. Read it as a sequence of questions: does the district need a point-in-time design view, evidence of sustained operation, or a document it can post publicly. The main takeaway is that a Type 2 report usually answers a district's privacy review, while a SOC 3 supports public trust pages.
| Report | What it covers | Who usually receives it and when it fits |
|---|---|---|
| SOC 2 Type 1 | System description and suitability of control design as of a single date | Early-stage vendors and districts that want to see the design of controls before a pilot; not evidence that controls operated over time |
| SOC 2 Type 2 | Adds an opinion on operating effectiveness over a period | Districts that want evidence of sustained operation, such as access reviews and incident handling, during a contract renewal or data privacy review |
| SOC 3 | Same trust services categories in less detail | Public trust pages, procurement portals and prospective districts at first contact; general use and freely distributable |
| Distribution | Use of a SOC 2 report is generally restricted to specified parties | Districts usually receive a SOC 2 under an NDA; confirm the vendor's distribution terms before sharing with staff or parents |
| Detail in the report | System description, controls, tests and results | Relevant to privacy and security staff who test controls; a SOC 3 omits this detail |
| What to ask the vendor | Which report exists, its date or period, and its scope | Confirm which categories are in scope, whether privacy is included, and whether student data systems are covered |
| Complementary controls | Customer responsibilities the report assumes | Districts should confirm which controls, such as account provisioning, remain with the school |
| Fit with FERPA review | Evidence on direct control and destruction, not a legal finding | A SOC 2 supports, but does not replace, the district's own FERPA review of the contract |
How to build a data destruction plan a school will accept
This sequence turns student data disposal into a documented plan with a stated method, timeline and proof of completion, the elements a school expects to see before it signs and that an auditor can later test against C1.2 and P4.3.
Inventory every location of student records
Map each system where education records or student personal information live, including production databases, file stores, analytics warehouses, logs, email attachments, support tickets, exports and backups. Record which subprocessors host or process each location and who in the company owns it. The output is a data inventory keyed to each school contract, reviewed by engineering and privacy owners. You know it is done when someone outside the build team can trace a single student record to every copy the company holds.
Map subprocessors and their deletion terms
For each subprocessor identified in the inventory, document what it holds, where, and how deletion is requested and confirmed. Check your contracts and subprocessor agreements for deletion obligations and notice periods. Where a subprocessor is a cloud platform, confirm whether backup retention and snapshot deletion are controlled by you or by the provider. The output is a subprocessor register with a deletion method for each entry. You know it is done when every subprocessor has a named contact and a written deletion method.
Define the triggers for disposal
Write the events that start disposal: termination or expiry of the school contract, a written request from the school, the end of a retention period set in your schedule, or a deletion request handled under the contract. Specify which trigger applies to which data type and who authorizes each one. Note that your own retention schedule sets the default, while the school may specify different requirements in the contract, and the contract governs where they conflict. The output is a trigger table approved by legal and the data owner. You know it is done when each data category has at least one trigger and an approver.
Set the timeline and destruction method
For each trigger, set a timeline for disposal and a method suited to the storage medium, such as cryptographic erasure, secure overwriting, or physical destruction for media you cannot reliably wipe. The Department of Education's vendor guidance expects a data destruction plan with a timeline and a method, so both must be written out. Address backups explicitly, including how deleted records age out of backup sets and how restores are prevented from reintroducing deleted data. Confirm the exact timeframes with the school and your own contract terms, since none are fixed by regulation here. You know it is done when each trigger maps to a written timeline and method.
Execute disposal and record each action
Run disposal according to the approved method and log every action: the data set, the system, the trigger that started it, the operator, the date, and the method used. Include subprocessor deletions and backup expiry dates in the same log. Where a record is kept rather than deleted because of a legal hold or a school instruction, log that exception and its reason. The output is a disposal log tied to the trigger table. You know it is done when the log reconciles with the inventory, leaving no unexplained data sets.
Obtain written confirmation from subprocessors
Request written confirmation from each subprocessor that the data has been deleted or returned, stating the scope and date. Where a provider cannot confirm backup purges on your timeline, record that gap, the compensating control, and the date by which the provider expects its backups to expire. Keep the confirmation with the disposal log. You know it is done when every subprocessor entry in the register has a confirmation or a documented exception.
Issue a certificate of disposal to the school
Send the school a written certificate of disposal that lists the data categories, systems, method, dates and any exceptions, signed by an accountable officer. Retain a copy and link it to the contract file. Agree with the school in advance whether it wants the certificate, a summary or an audit trail, since school requirements vary. You know it is done when the school has received and acknowledged the certificate or has documented its acceptance of exceptions.
Retain and test the evidence
Store the inventory, subprocessor register, trigger table, disposal log, confirmations and certificates together so an auditor can sample them against C1.2 and P4.3 during a SOC 2 examination. Review the plan periodically, and test a sample of disposals against the log to confirm the process runs as written. Ask your SOC 2 auditor which evidence period and sample sizes they expect before fieldwork. You know it is done when a sampled contract can be traced from trigger to certificate without gaps.
Why unilateral terms changes can undermine direct control
The Department of Education warns that changing a contract's terms of service without notice makes it difficult for a school to show that it keeps direct control of student data, so districts scrutinize any clause that lets a vendor modify provisions on its own. For an edtech company, the practical question is whether a school can point to a contract, and a dated record of its versions, that shows the school still decides how records are used, maintained and shared. A SOC 2 report does not answer that question on its own, but the operating evidence behind it can support the school's position.
Start with four controls that a vendor can put in writing and prove. First, set a change notice period for material changes to the terms of service, privacy terms and data processing addenda, and confirm with counsel what notice the school's agreement requires. Second, keep version control on every policy and contract document, with effective dates, approvers and a record of what changed. Third, notify customers before a new subprocessor receives student data, and give schools a way to object or exit. Fourth, record each change to these terms as a tracked change request, so the same evidence can be shown during a SOC 2 examination. The change management criteria (CC8) cover how changes to software, data and procedures are authorized and approved, and the vendor management and risk mitigation criteria (CC9) cover how third parties and business partners are assessed and monitored. Auditors may test whether these change records exist and were followed, so the vendor's own process should produce them.
Legal review of any contract clause, including whether a unilateral modification right is acceptable under FERPA and the school's own agreements, belongs to counsel. The vendor's job is to produce the operational records and to give schools the contract terms that let counsel reach that judgment. Ask your lawyers to review notice periods, objection rights and termination terms before you finalize the change process, and confirm the contract language with them rather than relying on this summary.
What must exist before a district's security review
Before a district security office opens a review, it expects the vendor to produce its own records, not a finished report. The six items below are the records a SOC 2 examiner will also sample, and a district will ask for them directly, so each should exist, be current and have a named owner before the first questionnaire arrives.
Current student data inventory
A living register of every student data element you collect, where it is stored, which system processes it, how long it is kept and which contract or school instruction authorizes it. Districts use it to confirm you collect only what the service needs. To check it, pick three data fields from a sample student record and trace each one through your databases, logs, backups and analytics exports. Product engineering owns the inventory, and the privacy lead signs off on changes.
Written security plan with controls
A security plan that names the safeguards protecting student records, the checks that verify each one, and the person accountable for running those checks. The Department of Education's vendor guidance says providers should maintain a security plan with a system of checks and controls. To check it, confirm every safeguard in the plan maps to a control in your control matrix and to an owner who can show a recent test result.
Breach response procedures for schools
A written incident response procedure that describes how you detect a student data incident, who decides on containment, how and when the school is notified, and what information you will provide. The guidance expects breach procedures to be agreed with the school in advance. To check it, confirm the procedure names the security lead and the executive contact, lists the contract's notification obligations, and has been exercised in a tabletop exercise with a dated record.
Data destruction plan with method and timeline
A plan that states how student records are deleted at the end of a contract or on a school's request, the method used for each storage location, the time allowed for removal from backups, and how you confirm completion in writing. The guidance expects a destruction plan with a timeline and method. To check it, ask engineering to show a deletion job for a test tenant, the backup expiry setting that governs residual copies, and the certificate you would send the school.
Access reviews and staff joiner and leaver records
Dated access reviews for every person with production access to student data, plus joiner and leaver records showing when access was granted, approved and removed. Districts ask who at the vendor can see their students' records and how quickly departing staff lose that access. To check it, compare the current list of production accounts against the HR roster and confirm each leaver's access was removed within the timeline in your access policy. Engineering management owns the review, and HR owns the leaver record.
Documented subprocessor list
A current list of every third party that receives or stores student data on your behalf, with the service each provides, the data categories involved, the hosting location and the date the contract with that party was last reviewed. Schools need this to judge whether their direct control extends through your supply chain. To check it, compare the list against your cloud account, logging, support and analytics invoices, and confirm each entry has a signed data processing term. Procurement and the security lead own the list together.
Who owns the controls, who prepares the evidence, who issues the report
Your organization owns the controls, the contracts and the district relationship. No outside party can accept responsibility for how student data is used, who may access it or when it is destroyed. Management must also write the system description and the assertion that the examiner evaluates, so the people who run the platform need to understand what the report will claim.
- Controls and their operation: Your staff designs, runs and records each control, including access reviews, change approvals and incident handling.
- Contracts and terms: Your legal team negotiates data processing terms with each district and keeps any changes to terms of service visible to schools.
- Retention and destruction schedule: Your team sets the retention periods and the destruction method and timeline that each district agrees to.
- Customer and district relationship: Your staff answers questionnaires, handles breach notices and explains the report to school officials.
- Management assertion: Your leadership signs the written representations the examiner requires.
Before engaging anyone, confirm that each control has a named owner inside your organization and that the owner can show the evidence without help from a consultant.
An implementation partner such as DeployOpen works inside your environment to plan, configure, document and harden the systems that the controls depend on, then assembles the evidence the examiner will request. Its work is bounded by a written scope with agreed deliverables. The partner does not perform the examination, does not test controls on the auditor's behalf and does not issue a report or opinion of any kind.
- Planning and configuration: The partner helps set up logging, access controls, encryption settings and backup procedures in your cloud accounts or data centers.
- Documentation: It writes runbooks, configuration records and control descriptions that match what the systems actually do.
- Evidence preparation: It organizes exports, screenshots and tickets so your team can respond to the examiner's requests.
- Examination support: Within the agreed scope, it answers technical questions during fieldwork and helps prepare the system description.
- Limits: The partner cannot make a control effective by installing a tool, and a partner's involvement does not guarantee an unqualified opinion.
Ask any partner to state in writing which tasks it performs, which it will not perform, and who in your organization remains accountable for each control.
An independent CPA firm performs the SOC 2 examination under the AICPA attestation standards. It tests the design of controls, and for a Type 2 report, their operating effectiveness across a period. It then issues the report with its opinion. Independence is the reason schools and their counsel can rely on the report, so the firm cannot design, build or operate the controls it tests.
- Examination procedures: The firm selects samples, inspects evidence and interviews staff to test each applicable criterion.
- Written representations: The firm obtains management's representation letter before it issues an opinion.
- Opinion and exceptions: The firm reports any exceptions it finds, and the opinion may be qualified.
- Report types: The firm issues a Type 1 or Type 2 report and, if requested, an SOC 3 general use report.
- Engagement terms: The firm's engagement letter defines scope, timing and fees, which you should compare across firms before signing.
Confirm that the firm has no role in preparing your controls or evidence, and ask for its engagement letter and report samples before you commit.
Questions edtech vendors ask about SOC 2 and schools
Does SOC 2 satisfy FERPA for a school district?
No. SOC 2 does not satisfy FERPA, and no report makes a vendor FERPA compliant on its own. FERPA's school official exception depends on the school's own conditions: the vendor performs a service the school would otherwise do with employees, the school keeps direct control over the records, and the vendor does not redisclose them without authorization. A SOC 2 report is evidence a school can weigh when it judges security and privacy practices, alongside your contract, data flows and deletion practices. The Department of Education's vendor guidance (PTAC-FAQ-5, August 2015) describes what schools may ask for, including transparency about data use and evidence of direct control. Confirm the exact conditions with the school's counsel or privacy officer.
How long does a SOC 2 take, and what does it need from staff?
The duration comes from the CPA firm's engagement letter and the examination period, so ask the auditor for a written timeline rather than relying on a general figure. Several drivers set the pace: whether you pursue a Type 1 report (a point-in-time view of control design) or a Type 2 report (operating effectiveness over a period), how many criteria are in scope, how mature your policies and access records already are, and how quickly your team answers evidence requests. Staff time falls on engineering, IT operations, HR and the person who owns the control matrix. Expect recurring demands for access reviews, change records and vendor reviews throughout the period, not only at audit time.
Can our own team run the SOC 2 work in-house?
Often yes, if someone owns the program and has time to maintain it. The tradeoff is effort and independence. An internal team knows the product and can build evidence into daily operations, but it may lack experience with auditor expectations, sampling and the system description. An outside consultant can prepare systems, controls and evidence, and DeployOpen works this way: we prepare systems and evidence for an assessment, but we do not issue audit reports or attestations. Only the independent CPA firm issues the report. Many teams split the work, keeping control ownership internal and buying readiness help for gap analysis and evidence design.
Do we need the privacy criteria for school customers?
It depends on the contract and the data you hold. The privacy category covers how personal information is noticed, collected, used, retained, disclosed and disposed of. A school contract that involves student personal information, or a district request for privacy commitments, usually makes the privacy criteria a strong fit, and when privacy is in scope, nine common criteria carry additional points of focus (CC1.3, CC1.5, CC2.2, CC2.3, CC6.1, CC7.3, CC7.4, CC8.1 and CC9.2). Security alone may suffice for some products. Confirm scope with your auditor and with customers before the examination starts, because adding a category later changes the work.
What do districts typically ask for before signing?
Requests vary, but the Department of Education's vendor guidance says schools may ask for several things. Prepare these in advance:
- Transparency about how student data is used, shared and retained
- A security plan with checks and controls, plus agreed breach procedures
- Evidence that the school keeps direct control of the data at all times
- A data destruction plan with a timeline and method
- Your SOC 2 report or a bridge letter, plus subprocessor lists and the security questionnaire
Ask the district which of these it requires in writing, since requirements differ by state and contract.
How should we respond when a school asks for a data destruction certificate?
Start by checking what your contract and retention schedule say, then give the school a documented process rather than an informal promise. A destruction plan should name the data categories, the systems and backups where copies live, the method, the timeline and who approves completion. Confirm that backup rotation is covered, because deleted records may persist in backups for a period. Provide a written attestation or certificate that you produce from your own records, and keep logs that show the deletion ran. Criteria C1.2 and P4.3 expect confidential and personal information to be disposed of in line with your objectives, so an auditor will test this process. Do not promise certificates your records cannot support.
Is a SOC 2 report enough evidence for a school's vendor review?
A report is useful evidence, not a complete review. It shows that an independent CPA examined your controls against the Trust Services Criteria and what the examination covered, but it does not describe every school-specific term. Schools also look at the contract, data flows, retention, subprocessors and how you handle access requests. Read the report's scope and exceptions carefully, and tell the district which systems, data and time period it covers. Confirm with the school what it considers sufficient before you promise any outcome.
How DeployOpen prepares edtech platforms for SOC 2 reviews
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the controls and evidence behind an edtech SOC 2 can be built and kept in order. DeployOpen prepares systems, controls and evidence for the assessment, while an independent CPA firm performs the examination and issues the report.
How we scope
- Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
- The written scope names which Trust Services Criteria categories are included, such as privacy and confidentiality for student data.
- Scope also records which school-facing data flows, subservice providers and hosting environments the report will cover.
How we build
- Self-hosted platforms are configured in the client's cloud accounts or data centers, with access control and logging set up to produce evidence.
- Data retention, deletion and disposal procedures are implemented in the systems so that destruction plans can be carried out and recorded.
- Security testing of applications, APIs and infrastructure is run to check the controls that the SOC 2 description relies on.
How we hand over
- Control descriptions, evidence collection steps and owner assignments are documented so the client can run them after handover.
- Runbooks cover breach procedures, data destruction timelines and the records a school may ask for during a vendor review.
- The client receives a clear map of which evidence supports which criterion, ready for the CPA firm's evidence requests.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which can keep controls current between examinations.
- Support can cover changes to hosting, new school integrations and updates to the platform that affect the control description.
- Confirm with DeployOpen during scoping which support terms apply to your environment and which tasks stay with your own team.
