An EdTech Vendor and Student-Data Review for Private Schools and Childcare Organizations

Schools and childcare organizations should approve technology through a repeatable process that connects educational purpose, privacy requirements, vendor terms, access, information lifecycle, and operating responsibility.

Published September 2026

Short answer

Before approving an educational application, the organization should identify its purpose, users, student and family information, data flows, vendor role, terms, security, access, retention, deletion, support, and exit process. Teachers and staff should not have to make privacy and vendor-risk decisions independently. Administration should establish a practical request, review, approval, inventory, and reapproval process.

FERPA applicability and other education, childcare, contractual, privacy, and licensing requirements depend on the organization and circumstances. The U.S. Department of Education advises educators to confirm that online tools are approved and to consult appropriate administration and technology representatives. Qualified advisers should determine obligations; technology work can implement the approved controls and evidence.

Frame the decision around the operating condition

Start with the work the organization must perform, the information it depends on, and the consequence when a handoff fails. Document the current condition before prescribing a replacement, integration, automation, control, or subscription.

Leadership needs evidence of reliable use, controlled access, accountable ownership, recoverable information, supportable change, and a path for exceptions. Use these decision factors:

The educational or administrative purpose, intended outcome, approved users, alternatives, and accountable sponsor.
Student, child, parent, guardian, employee, payment, health, behavioral, biometric, image, communication, and device data involved.
Collection, use, disclosure, sharing, integrations, subcontractors, advertising, profiling, training, retention, export, and deletion.
Account creation, authentication, roles, parent or school authorization, teacher access, support, monitoring, and offboarding.
FERPA, COPPA, contracts, school policy, childcare requirements, accreditation, insurance, and qualified legal interpretations.
Vendor change, breach, outage, acquisition, product retirement, contract termination, data return, transition, and family communication.

Make responsibilities explicit

Industry platforms depend on business owners, employees, vendors, Microsoft 365, devices, networks, identity, integrations, and recovery services. Product contracts do not necessarily assign every operating responsibility.

Before making changes, name who approves the outcome, performs the work, and sustains it. Shared participation is normal; accountability still needs a named owner.

A responsibility map should connect each role to evidence the organization can inspect.
Role	Primary responsibility	Evidence to retain
School or childcare leadership	Approve purpose, risk, policy, resources, vendor, communications, and accountable ownership	Approval record, inventory, contract, policy, and review cadence
Privacy and legal advisers	Determine applicable obligations, authority, notices, contracts, and response requirements	Approved requirements, clauses, notices, and legal decisions
Educational and program owners	Define need, users, workflow, content, alternatives, training, and expected outcome	Use-case record, curriculum or program fit, guidance, and outcome review
Technology owner and vendor	Operate identity, access, configuration, integration, security, support, export, and deletion duties	Configuration, data map, service evidence, access review, and exit record

Recognize warning signs before they become urgent

Treat these signals as questions to investigate, not proof that a product or provider failed. Preserve examples, dates, affected workflows, and business consequences so the decision rests on evidence.

Teachers, volunteers, or staff create accounts before administration reviews the tool and its information practices.
The organization cannot list applications, responsible sponsors, users, data, integrations, contracts, or renewal dates.
Vendor terms allow uses or disclosures inconsistent with the approved educational purpose or organizational expectations.
Accounts and data remain after students, families, employees, volunteers, or vendors leave.
Family communication describes features but not the approved purpose, information practices, choices, contacts, and changes.
There is no practical response for a vendor breach, outage, acquisition, product change, termination, export, or deletion failure.

What to verify before buying or changing technology

Verify requirements, current capability, ownership, and transition consequences before selecting a tool. Ask vendors to distinguish included features, licensed modules, supported integrations, services, and customer responsibilities.

Test representative workflows and exceptions. Record the evidence, open assumptions, acceptance owner, and post-launch measures. Leadership should answer these questions:

What approved educational or administrative purpose does the tool serve, and is a lower-risk existing option available?
What information is collected, generated, inferred, shared, integrated, retained, exported, and deleted?
What authority, consent, notice, contract, policy, and qualified review does the organization require?
Who approves accounts and roles, reviews access, supports users, monitors changes, and removes access?
How does the vendor protect information, manage subcontractors, report incidents, and support organization oversight?
Can the organization export needed records, verify deletion, communicate change, and continue work when the service ends?

Use a bounded improvement sequence

Evidence may support retaining the current system, improving configuration, clarifying ownership, connecting a handoff, adding a recovery control, or replacing only a justified gap. Sequence the smallest useful change.

Define success before implementation and schedule a review. Show what changed, what remains unresolved, who operates the result, and when the decision returns to leadership.

Move from evidence to action without turning an assessment into a predetermined sale.
Stage	Practical action	Decision produced
Request	Document purpose, users, information, sponsor, timing, alternatives, and expected outcome	Accept for review or decline
Review	Evaluate approved requirements, terms, data flow, access, security, support, retention, and exit	Approve, condition, pilot, or reject
Operate	Configure roles, train users, maintain inventory, support use, review access, and handle incidents	Continue within the approved boundary
Reapprove	Review outcomes, vendor changes, contracts, data, access, incidents, and organizational needs	Retain, revise, replace, or retire

Related next steps

Industry Software, Microsoft 365, and the System of Record Information Architecture Assessment Choosing a Technology Provider

Before Connecting Protégé to Microsoft 365 or Your DMS Who Owns What in a Medical or Dental Practice? EHR, Microsoft 365, Devices, Backups, and Vendors

Sources and further reading

This resource provides general business-technology guidance. Engagement scope, evidence, and recommendations depend on the organization’s actual condition.

A practical next step

Create a repeatable EdTech and student-data review process.

Explore the information architecture assessment