A district leadership team is preparing to buy a new educational platform. The demonstration is impressive: personalized exercises, intelligent feedback, beautifully organized dashboards, and a reassuring slide that says the company takes privacy seriously. The superintendent asks about results. The curriculum director asks about teacher training. Someone from IT asks about single sign-on. Then a parent representative asks a different question: What exactly will happen to our children’s information when they use this?
The room goes quiet, not because the question is unreasonable, but because no one has mapped the answer.
Student data privacy in EdTech procurement means examining the complete life of students’ information—collection, access, processing, sharing, retention, and deletion—before an educational technology contract is signed. For US K–12 schools, that examination belongs alongside instructional evidence, accessibility, cybersecurity, and total cost. A reassuring privacy policy is a starting point, not a substitute for a documented review.
This practical guide is for principals, district leaders, curriculum teams, procurement officers, and the privacy and IT professionals who advise them. It includes an evidence-based checklist and a school-ready review workflow. It is not a legal determination: federal, state, and local requirements must be evaluated for the actual product and use case by appropriately qualified staff.
The question behind every EdTech privacy review
A platform does not simply “have data.” It receives particular information from particular people and systems, generates additional records, and makes those records available to others under particular rules.
Consider a proposed reading application for students in Grades 4–6. To personalize exercises, it requests each learner’s name, school ID, grade, class roster, reading responses, usage history, and microphone access for oral reading. It proposes to keep progress profiles after the semester ends. Its dashboard provides access to teachers and selected district staff. A subcontracted analytics service helps process usage events.
None of those details, by itself, establishes that the application is unlawful or appropriate. Together, however, they create a set of questions the district must answer: Does this educational purpose require a real name? Is microphone access essential or optional? Who can hear or retrieve a recording? Can the vendor use interaction data to develop other products? How are old accounts deleted? What happens when the district leaves?
The discipline of privacy review is to follow the actual information rather than accept a general description of the software.
Begin with educational necessity, not legal paperwork
Before asking a vendor for security certificates and contractual promises, ask the instructional team to define the problem being solved. A district trying to help students read fluently may need evidence of oral-reading accuracy. It may not need to retain every audio recording indefinitely or to export an entire student information system.
Describe the intended learning outcome, the age group, the setting, the existing alternative, and the smallest set of information needed to operate the proposed feature. This gives the privacy team something concrete to evaluate. Otherwise, the review may become a negotiation about data that no one has justified collecting.
At Learning Coach, the educational question is whether a tool helps a student understand, practice, reflect, and gradually work independently. A platform can offer genuine instructional value while still requiring a difficult privacy discussion. Equally, a low-risk data flow does not establish that students will learn more.
The US Department of Education’s guidance on online educational services provides a useful foundation for examining third-party educational applications. It is a historical guidance resource, not proof that any particular product meets present requirements.
Map the data journey before negotiating the contract
Build a one-page data-flow map for the exact implementation the school is considering. Have the vendor and school data owner review it together.
| Stage | School leader’s question | Evidence to request |
|---|---|---|
| Entry | What information enters the service, from whom, and why? | Field-level data inventory and integration diagram |
| Processing | What is calculated, inferred, recorded, or generated? | Description of processing and generated student records |
| Access | Which staff, vendor personnel, and subprocessors can view data? | Role-permission matrix and subprocessor list |
| Use | Is data used only for the district’s requested service? | Contractual permitted-use language and relevant policies |
| Storage | Where is information held and how is it protected? | Hosting locations, retention schedule, security summary |
| Exit | How are records returned, deleted, and verified at termination? | Export format, deletion process, and written confirmation procedure |
The map should include derivatives. An AI tutor may receive a student’s prompt and generate an interaction transcript, score, summary, or inferred performance profile. A school should not focus exclusively on the original roster while overlooking the new information produced inside the system.
Ask what appears in ordinary application databases, analytics logs, troubleshooting records, backups, and third-party integrations. Some operational logs may be necessary for security or reliability; the question is whether their content, access, and retention are proportionate and disclosed.
The practical EdTech privacy procurement checklist
Use the following checklist at the initial review, then repeat it when the intended use or product functionality changes. “Yes” is not enough on its own. Each answer needs an accountable person and a document, demonstration, or contractual clause that supports it.
1. Define the educational purpose
[ ] The district has described the specific instructional service and intended users.
[ ] The data requested by each feature is necessary or a documented, justified choice.
[ ] The team has checked whether an existing product or lower-data alternative could accomplish the same goal.
2. Identify the information collected
[ ] The vendor provides a current inventory of required and optional fields.
[ ] The team accounts for sensitive inputs such as recordings, free-text responses, photographs, disability-related information, or location data when applicable.
[ ] Generated profiles, inferences, metadata, and usage logs are identified—not just information imported at account creation.
[ ] Optional features that collect additional information can be disabled where appropriate.
3. Establish lawful access and permitted use
[ ] The district has determined the relevant legal basis or FERPA exception, if an education-record disclosure is involved.
[ ] The service provider’s permitted uses and redisclosure restrictions are documented.
[ ] The vendor identifies all relevant subcontractors and what information each can access.
[ ] Staff access follows defined roles rather than universal dashboard visibility.
[ ] Proposed AI model training, product development, advertising, and marketing uses are explicitly addressed rather than left to broad phrases such as “service improvement.”
4. Examine security and incident handling
[ ] Security personnel have reviewed authentication, access controls, encryption, logging, patching, and vendor security evidence appropriate to the risk.
[ ] Contract terms identify how security incidents are reported, investigated, and escalated.
[ ] The district can identify the person responsible for coordinating a response if information is exposed.
[ ] The vendor has explained how it oversees its own subprocessors.
5. Protect families’ and students’ interests
[ ] Notices are intelligible to families and consistent with applicable requirements.
[ ] Staff know how to respond to privacy questions and route access, correction, or deletion requests to the correct office.
[ ] The team has considered accessible alternatives for students who cannot or should not use a particular data-intensive feature.
[ ] A district contact—not just a vendor support link—is publicly identifiable for questions.
6. Prepare for retention and exit
[ ] Retention periods are documented for active records, logs, exports, and backups.
[ ] The district can export necessary learning records in usable formats.
[ ] The contract describes what happens to data after cancellation, including deletion and any justified exceptions.
[ ] The vendor can document completion of the agreed exit process.
This checklist is deliberately operational. It does not certify compliance or replace the district’s legal review. It makes missing answers visible before a pilot becomes an irreversible purchase.
FERPA: what leaders need to understand about vendor access
In US education, FERPA governs certain disclosures of personally identifiable information from education records. A school does not need to treat every technology interaction as the same kind of education-record disclosure, nor should it assume that any company calling itself an educational vendor automatically qualifies for an exception.
The US Department of Education explains that the “school official” exception can, under specific conditions, extend to a contractor performing an outsourced institutional service. Relevant conditions include institutional purpose, school control over the use and maintenance of education records, restrictions on use and redisclosure, and the criteria in the school’s annual FERPA notice. See the Department’s explanation of school officials under FERPA.
For procurement teams, the practical consequence is to ask exactly which records will be disclosed and under which applicable authority. Determine how the district will exercise meaningful control over the provider. Contracts are an important instrument for specifying obligations, but the existence of a signed data agreement alone does not demonstrate that every legal condition is satisfied.
The district’s attorney or privacy officer should decide whether written consent is necessary for a particular disclosure or whether an exception applies. Staff should not improvise a legal conclusion from a vendor’s marketing page.
COPPA: school authorization has limits
COPPA is a distinct federal framework concerned with certain online collection of personal information from children under 13. It is not a synonym for FERPA, and its application depends on the service and the information practices involved.
The Federal Trade Commission’s COPPA guidance for schools and operators explains that schools may act on parents’ behalf in a limited educational context, where information is collected for the school’s use and benefit rather than unrelated commercial purposes. The operator remains responsible for complying with the Rule. The FTC also highlights limits on unnecessary collection, retention, and permitted uses.
Therefore, the question is not simply, “Can our school authorize this app?” It is, “What collection are we authorizing, for what educational purpose, and what else does the provider intend to do with the information?”
The FTC amended its COPPA Rule in 2025. Schools and vendors should check the applicable current Rule and the details of their use case rather than relying on an older contract template.
State law, district policy, and procurement obligations
Federal law does not exhaust a US school’s privacy responsibilities. State student-data statutes, accessibility obligations, public contracting rules, cybersecurity requirements, and district policies may add important requirements. The applicable obligations vary by jurisdiction and by the kind of data or service involved.
A district purchasing a platform for one building should not automatically reuse another state’s legal checklist without review. An approved data privacy agreement from a neighboring school can be helpful, but its clauses and context still need examining. Similarly, a vendor’s certification or privacy-rubric assessment may provide evidence but cannot stand in for the school’s own decision.
The 1EdTech TrustEd Apps Data Privacy Rubric offers a structured way to assess issues such as notice of policy changes, collected data, security, third-party sharing, and advertising. Use such frameworks to organize questions, not to outsource accountability.
Seven contract clauses that deserve a real conversation
A contract can look comprehensive while leaving important decisions unresolved. Ask procurement, legal, privacy, and technical colleagues to review the clauses as a coordinated team.
Purpose and scope. Specify the services, the district’s authorized uses, and the categories of information the provider may process. Avoid language broad enough to support unrelated activity.
Control and role allocation. Define the provider’s responsibilities, the district’s oversight and review rights, and what happens if service functionality changes.
Subprocessors and disclosures. Identify downstream organizations and set a procedure for reviewing significant changes to the processing chain.
AI development and secondary use. State whether student inputs, outputs, or metadata can be used to train models, improve unrelated products, or support advertising. Do not infer the answer from a generic promise of responsible AI.
Security and incident response. Document relevant safeguards, escalation contacts, incident reporting processes, and reasonable cooperation requirements. Actual notice obligations may be determined by applicable law as well as contract terms.
Retention, export, and deletion. Define what must be returned or deleted, relevant timelines, treatment of backups, and the evidence the district will receive after termination.
Changes, audit, and remedies. Specify how material policy or product changes are communicated and what options the district has when commitments are not met.
Ask to see the signed version, not only an attractive privacy-policy page. Where terms conflict with other service agreements, resolve the conflict before student accounts are created.
The three mistakes that make a privacy checklist ineffective
Mistake one: Treating “we do not sell student data” as a complete answer
A promise not to sell student information addresses one concern. It says little by itself about collection scope, cross-product analytics, vendor support access, AI model development, account retention, or data shared with subprocessors. School leaders need a more detailed explanation and, where appropriate, enforceable limits.
Mistake two: Reviewing a vendor, not the deployment
The same application may behave differently depending on activated modules, district integrations, roster fields, administrative permissions, and teacher settings. An initial review of a limited pilot cannot automatically authorize every future deployment. If the vendor adds voice capture or predictive profiling, revisit the data-flow map.
Mistake three: Confusing privacy approval with educational impact
A platform can have a well-documented privacy posture and still be instructionally ineffective. Conversely, a powerful instructional tool may require changes before it can be introduced safely. Privacy, security, pedagogy, accessibility, and cost are separate decision gates. None should be traded away merely because a sales demonstration was persuasive.
For a broader multi-vendor evaluation, schools can examine learning evidence, integration burden, and total cost alongside the privacy review. Here, however, the goal is narrower: ensure that the handling of student information is understood and governed before purchase.
A five-step review workflow for school and district leaders
Step 1 — Convene the right people. Assign a named owner from curriculum, IT/security, privacy/legal, procurement, and the school where the tool will be used. Include appropriate teacher and family perspectives. Do not assume a single technology coordinator can answer every instructional and legal question.
Step 2 — Request a standardized evidence packet. Ask every shortlisted vendor for a field inventory, data-flow diagram, subprocessor list, role matrix, applicable security documentation, privacy policy, proposed agreement, retention schedule, and exit procedure. Where information is unavailable, record that as an open issue rather than a positive answer.
Step 3 — Walk through an actual student scenario. Use synthetic or dummy accounts, never real student records for an unapproved demonstration. Create a sample learner, complete an activity, inspect the teacher dashboard, examine generated reports, remove access, export a record, and ask the vendor to demonstrate or document deletion. Request written clarification for invisible background processing.
Step 4 — Record decisions and conditions. Maintain a short decision register with the risk, evidence, responsible reviewer, required change, and approval status. Use “approve with conditions,” “return for changes,” or “do not deploy” only after the designated reviewers have completed their work. Do not turn a numeric score into a substitute for an unresolved legal or security requirement.
Step 5 — Plan the renewal and exit review. Put review dates in the contract calendar. When features, subprocessors, data use, or school policies change, reassess the deployment. Before contract expiration, verify export and deletion options while there is still time to act.
A review becomes useful when a principal can answer a parent's question plainly, a teacher understands what tools are approved, and a district can show why it made its decision.
A sample decision record a school could reuse
| Item | Example entry |
|---|---|
| Proposed service | Adaptive reading practice for Grades 4–6 |
| Learning goal | More accurate reading feedback and independent practice |
| Minimum proposed input | Pseudonymous ID, class membership, reading responses |
| Additional feature requiring review | Optional microphone-based oral-reading assessment |
| Open privacy issue | Retention and secondary use of audio and derived scores |
| Evidence requested | Technical data inventory, contract clause, deletion procedure |
| Decision owner | District privacy lead with curriculum, IT, procurement, and legal review |
| Status | Pending clarification; student deployment not approved |
This is an illustrative template, not a report about a real district or supplier. Its purpose is to make the uncertainty observable.
Why learning coaching belongs in this conversation
Learning coaching does not replace privacy law or cybersecurity engineering. Its contribution is to hold the educational purpose in view while specialists evaluate the data practices.
A school leader using a coaching approach can ask teachers: What behavior should this tool help students practice? Which difficulties will become easier to see? Can students explain a strategy without the product? What feedback will teachers use? When will the learner take more responsibility rather than less?
These questions connect procurement to daily classroom practice. They also prevent a familiar failure: a school spends time approving and installing technology but has not defined what teachers should notice or what students should learn.
Learning Coach’s Pedagogical Director Coach specialization is oriented toward schoolwide pedagogical leadership, staff coaching, and learner autonomy. The principles of reflective practice, feedback, and responsible delegation can help leaders facilitate evidence-driven implementation. Availability and exact course arrangements should be checked on the official Learning Coach training page; this article does not assert a guaranteed qualification or outcome.
For a complementary reflection on why tools should serve learning rather than replace human judgment, explore Stop Teaching. Start Coaching.. Its perspective is particularly relevant when a technology decision risks treating more recorded activity as the same thing as more genuine understanding.
Frequently asked questions
Is a signed data privacy agreement enough to approve a new app?
No. A written agreement can be essential, but leaders must also understand the actual implementation, applicable legal requirements, technical safeguards, educational purpose, and the district's own policies. The agreement should reflect the practice that will occur.
Does FERPA ban schools from using third-party educational applications?
No. FERPA allows certain disclosures under defined conditions, including the possibility of outsourcing an institutional service under the school-official exception. Whether a specific arrangement qualifies must be evaluated rather than assumed.
Can an EdTech company use students’ information to train AI models?
Do not assume permission or prohibition solely from the label “AI.” Examine the provider’s actual practices, the types of information involved, contractual permissions, applicable law, and the district’s policies. Where the answer is unclear, withhold that use until it is resolved.
Should schools ask for parental consent for every EdTech product?
There is no universal yes-or-no answer. Requirements depend on the information, user age, legal framework, type of disclosure, and authorized educational purpose. Obtain a case-specific determination from the responsible district professionals.
Who should own the EdTech privacy review?
A designated district leader should coordinate it, but the decision requires input across educational, legal, privacy, security, procurement, accessibility, and operational responsibilities. Teachers and families also need understandable communication about what is being introduced.
What is the single most useful vendor question?
Ask the vendor to describe, in one concrete student scenario, every category of information collected, generated, shared, retained, and deleted—and to show the documentation that makes the answer verifiable.
The purchasing decision is a promise to students
Responsible EdTech purchasing is neither a rejection of technology nor a collection of forms designed to delay innovation. It is a promise that schools will know what they are asking students to do, what information that activity creates, and who is accountable for protecting it.
The strongest procurement meeting ends with more than a preferred product. It produces a defensible understanding of purpose, data flows, legal responsibilities, safeguards, and the conditions under which the school will stop using a system. Above all, it keeps the learner—not the platform—at the center of the decision.
If you lead educators and want to strengthen the relationship between pedagogical leadership, coaching practices, and student independence, explore the Learning Coach professional training pathway.
References and further resources
US Department of Education — Protecting Student Privacy While Using Online Educational Services (foundational guidance, February 2014).
US Department of Education — Who is a “school official” under FERPA?.
Federal Trade Commission — Complying with COPPA: Frequently Asked Questions (see school-specific guidance and revised Rule).
US Department of Education — Model Terms of Service for Online Educational Services (contract-review resource).
Legal determinations must be made for the district, jurisdiction, vendor, and deployment concerned.
