What is the best way to ensure FERPA compliance when using cloud-based classroom software in 2027?

The district that discovered the exposure during a breach notification

A mid-sized district — roughly 12,000 students, 900 staff, and one systems administrator already wearing four hats — learned about a math practice platform the hard way. Three teachers had adopted it in 2025 by clicking through a click-wrap terms-of-service page. No one in central office signed a contract. The platform stored student names, grade levels, IEP accommodation flags typed into a free-text notes field, and two years of performance history. When the vendor suffered an intrusion, the district got a breach notification for data it did not know it had disclosed.

That is the shape of nearly every real FERPA problem with cloud-based classroom software. It is almost never a malicious actor targeting a school. It is a well-intentioned teacher making a defensible pedagogical choice, adopting a tool that never passed through a review capable of catching three specific failures: no written agreement establishing the vendor as a school official, no contractual limit on the vendor's use of student data, and no control over which vendor employees can read records in production.

The FERPA question underneath is narrow. FERPA restricts disclosure of personally identifiable information from education records without written parental consent. Sending student names and grades to a third-party server is a disclosure. The regulation provides an exception — the school official exception at 34 CFR § 99.31(a)(1)(i)(B) — permitting disclosure to a contractor, consultant, volunteer, or other outside party performing an institutional service the school would otherwise use employees to perform. That exception carries four conditions that must all hold simultaneously: the vendor performs a service the district would otherwise handle itself; the vendor is under the district's direct control regarding use and maintenance of the records; the vendor is subject to § 99.33(a) redisclosure limits; and the district uses reasonable methods to restrict access to officials with legitimate educational interest.

The click-wrap tool fails at least three of the four. So the answer is not "buy a better platform." It is to build a gate no classroom software crosses without satisfying all four conditions, and to make that gate cheap enough that teachers use it instead of routing around it.

Adjacent to this sits a second problem districts consistently underestimate: the same review discipline must cover tools nobody classifies as classroom software. Learning management systems get reviewed. The single sign-on layer, student information system API integrations, the parent communication app, the behavior-tracking system, the transportation routing tool that knows which students board which bus at which address, the AI tutoring assistant a department piloted, and the transcription service running over recorded lessons all carry education records too. A district that reviews only tools with "classroom" in the name has reviewed perhaps a third of its exposure.

How the school official exception actually works in a cloud contract

The mechanism has three layers, and districts that get FERPA wrong almost always have one missing rather than all three.

Layer one: the annual notification defines the exception's scope. FERPA requires districts to notify parents annually of their rights. Buried in that notification is the district's definition of "school official" and "legitimate educational interest." If your annual notice defines school official narrowly — "employees of the district" — you have not preserved the contractor pathway, and every vendor disclosure is technically unauthorized. The fix is a one-paragraph amendment: define school official to include a contractor, consultant, volunteer, or other party to whom the district has outsourced institutional services or functions, provided that party meets the § 99.31(a)(1)(i)(B) criteria. This costs nothing and is the single highest-leverage compliance action most districts have never taken.

Layer two: the written agreement establishes direct control. "Direct control" is not a feeling; it is contract text. The agreement must state that the vendor processes data solely on the district's instructions, may not use student data for its own purposes (product improvement, advertising, model training, resale), must delete or return data at contract end, may not redisclose without district authorization, and must notify the district of any subpoena or law-enforcement request before responding where legally permitted. Note the model-training clause specifically — since 2023 this became the fastest-moving gap in vendor terms, and by 2027 any agreement silent on whether student data trains a vendor's models is an agreement with a hole in it.

Layer three: technical enforcement of legitimate educational interest. The regulation demands "reasonable methods" to ensure officials only access records in which they have legitimate educational interest. In practice that means role-based access control provisioned from the student information system, not manually. A third-grade teacher sees their roster. A counselor sees their caseload. A district administrator sees the district. When a student transfers buildings, access moves within a sync cycle. Manual provisioning always drifts — the substitute who never got deprovisioned, the teacher who moved schools, the aide who left in October and still has a login in March.

The flow matters more than any individual control. A district with a mediocre contract but a working gate catches problems; a district with an excellent template contract and no gate discovers its exposure the way the district above did.

Real numbers, ranges, and benchmarks

Precise national figures on district software counts vary by source and methodology, so treat these as operating ranges to validate against your own inventory rather than as citations.

Application inventory. When districts run their first real discovery — pulling the OAuth-granted application list from their Google Workspace or Microsoft 365 tenant — the count is routinely several hundred distinct third-party applications granted access to district accounts. The number of those with a signed data privacy agreement is typically a small fraction. The gap between "apps with access" and "apps with a contract" is the entire compliance problem expressed as a single subtraction. Run it first; it reframes every subsequent conversation with leadership.

Discovery cost. The OAuth application report in both major tenants is free and takes under an hour to export. That is the cheapest compliance artifact in education technology, and almost nobody generates it before a crisis.

Contract negotiation time. A vendor already using a standard student data privacy agreement — the National Data Privacy Agreement maintained through the Student Data Privacy Consortium is the common one — can typically be onboarded in days, because you are signing an exhibit to an agreement whose body is already negotiated. A vendor requiring bespoke redlines runs weeks to months of back-and-forth with counsel. This asymmetry is the strongest practical argument for prioritizing SDPC-participating vendors: not that their privacy posture is inherently better, but that the transaction cost of verifying it collapses.

Access recertification. Districts that run access reviews find stale accounts every cycle. Departed staff, role changes, contractors, and test accounts accumulate continuously. Quarterly recertification for high-sensitivity systems (SIS, special education case management, health records) and annual for general instructional tools is a defensible cadence. Anything less frequent than annual is hard to characterize as "reasonable methods."

Retention. Set explicit retention in every agreement rather than accepting the vendor default, which is frequently "indefinitely" or "as long as the account is active." A reasonable default is deletion within 30 to 60 days of contract termination or student record inactivity, with a written deletion certificate returned to the district. Ask for the certificate. Vendors that cannot produce one usually cannot actually delete.

Breach notification. FERPA itself does not carry a federal breach notification mandate the way HIPAA does, but nearly every state student privacy statute does, and timelines in state law commonly run from immediate to 30 or 45 days. Your agreement should require vendor notification to the district within a window short enough that the district can still meet its own statutory deadline — 72 hours or less to the district is the standard ask, precisely because the district's clock starts when it learns.

Directory information. The one lever that legitimately reduces scope. Districts may designate certain fields as directory information — typically name, grade level, participation in activities, dates of attendance — disclosable without consent after annual notice and an opt-out window. Narrow designations reduce the surface you must defend but also constrain yearbooks, athletics programs, and honor rolls. Most districts over-designate. Reviewing that list is worth an afternoon.

Trade-offs and alternatives

Every FERPA control costs something, usually in teacher velocity, and pretending otherwise is why compliance programs get routed around.

Centralized approval versus classroom autonomy. A hard gate — no tool touches student data without a signed agreement — is the most defensible posture and the most resented. Teachers experience it as central office saying no to pedagogy. The mitigation that actually works is a two-track review: a fast track for tools requiring no account creation and no PII (a public reference site, a timer, a whiteboard used without logins) that clears in days, and a full track for anything that provisions student accounts. Publishing a pre-approved catalog of 40 to 80 vetted tools converts the gate from an obstacle into a menu, and menu usage is high because it is faster than fighting.

Roster sync versus data minimization. Automated rostering from the SIS is the single best access control you can deploy, and it tends to push more data to vendors than necessary, because the sync standard sends a full field set by default. Configure the sync to send the minimum: a pseudonymous student identifier, grade level, and course enrollment. Many platforms function fine without legal names — display names or IDs suffice for instruction, and the teacher holds the mapping. Districts rarely try this because nobody asks the vendor whether it is possible.

Free tools versus paid. Free classroom software is frequently free because the data has value. This is not universally true — genuinely free tiers of paid products exist, and nonprofit and university-run tools are real — but "free with no enterprise agreement available" should trigger scrutiny, not gratitude. The relevant question is not price; it is what the terms-of-service permit the vendor to do with the data, and whether they will sign something narrower.

On-premise versus cloud. Some districts respond to cloud anxiety by retreating to self-hosted systems. FERPA does not prefer either. A self-hosted server a district cannot patch, back up, or monitor is worse for student privacy than a competently operated cloud service under a strong agreement. Evaluate the operator's capability, not the deployment topology.

AI features versus contractual clarity. By 2027 essentially every instructional platform ships some generative capability — feedback assistants, differentiation generators, summarizers. Two questions decide whether it is usable: does student input leave the vendor's contractual boundary and reach a third-party model provider, and is the district's data excluded from training. If a vendor cannot answer both in writing, disable the AI features at the tenant level rather than rejecting the platform wholesale. Most enterprise plans support that toggle.

Common pitfalls and how to avoid them

Treating the DPA as the finish line. A signed agreement nobody configures against is paper. The agreement says access is limited to legitimate educational interest; the actual tenant has every teacher provisioned as an administrator because that was the fastest way to launch. Compliance lives in the configuration, and the configuration drifts. Pair every signed agreement with a documented tenant configuration baseline and check it annually.

Ignoring the annual notification. As above — if the district's annual FERPA notice does not define school officials to include contractors, the exception the district relies on is not available to it. This is a paperwork failure that invalidates otherwise-correct contracting.

Free-text fields as the disclosure vector. Structured student data is usually well-governed. The comment box is not. Teachers enter disability accommodations, custody arrangements, medical notes, and behavioral incidents into fields the district never classified as sensitive, in tools whose agreements assumed only name and grade. Train on this specifically, and where the platform allows, disable or restrict free-text on student-facing records in tools not covered for sensitive categories.

Confusing de-identification with anonymization. Vendor terms frequently reserve rights to "aggregated and de-identified data." FERPA permits release of properly de-identified data, but the standard is that a reasonable person in the school community could not identify the student. Small-cell data — the three students in an AP Latin section, the one student with a particular accommodation in a grade — re-identifies trivially. Require that de-identification meet a stated threshold and that the vendor not attempt re-identification.

Forgetting subprocessors. The vendor you contracted with is rarely the only party touching the data. Cloud infrastructure, analytics, email delivery, support ticketing, and increasingly model inference all sit downstream. Require a subprocessor list, notification before changes, and flow-down of the same restrictions. A district that vetted a vendor but not its subprocessors has vetted the front door of a building with several unlocked side entrances.

Never testing deletion. Contract says data is deleted in 30 days. Nobody has ever verified it. Pick two decommissioned vendors a year, request the deletion certificate, and if the platform supports it, attempt to authenticate a known former account. The vendors that fail this are the ones you most needed to test.

Assuming FERPA is the only statute. COPPA applies to children under 13 and shifts obligations around consent for online services. PPRA governs surveys touching protected categories. State student privacy laws — California, Colorado, Connecticut, New York, Illinois and many others — frequently exceed FERPA, and several ban targeted advertising and data sale outright. Building a program to FERPA alone leaves state gaps. Building to the strictest applicable state law usually satisfies FERPA automatically.

Under-scoping the inventory. Repeating the earlier point because it is the most common structural failure: the review must cover every system holding education records, not the ones labeled instructional. Transportation, food service (which knows free-and-reduced-lunch status, a protected category), athletics eligibility, library circulation, device management, and any recording or transcription running over instruction all qualify.

A ninety-day build sequence. For a district starting from nothing, sequence matters more than ambition. Days 1–15: discover — export the OAuth application list, pull the accounts-payable ledger for anything coded to software, and survey principals on what teachers actually use; reconcile the three lists. Days 16–30: triage into three buckets — touches PII with a signed agreement, touches PII without one, does not touch PII — and order the middle bucket by student count exposed times data sensitivity. Days 31–60: paper the gap, checking each unpapered vendor against the SDPC national agreement registry and setting a decision date. Days 61–75: configure — SSO everywhere available, roles provisioned from the SIS, secondary use and model training toggles off, retention set, administrator counts restricted to a number you can name from memory. Days 76–90: institutionalize — publish the approved catalog, stand up the two-track intake with a named owner and a service-level commitment you will actually meet, amend the annual notification, schedule recertification, and write the disclosure log procedure. FERPA requires a record of disclosures for records released without consent, and most districts maintain it poorly or not at all. The program that survives is the one where a teacher who wants a new tool knows exactly where to ask and gets an answer fast. Every hour you shave off intake response time buys back compliance you would otherwise lose to shadow adoption.

Related questions

Does a parent have to consent before a district uses cloud classroom software?

Not if the vendor qualifies under the school official exception — written agreement, district control over the data, redisclosure limits, and access restricted to legitimate educational interest. Absent those conditions, the disclosure needs written parental consent.

Is a click-wrap terms-of-service enough to establish a school official relationship?

Generally no. Click-wrap terms are drafted for the vendor's benefit and rarely grant the district direct control over use and maintenance of records or limit vendor secondary use. A negotiated data privacy agreement or countersigned SDPC exhibit is the defensible instrument.

What happens if student data trains a vendor's AI model?

That is vendor secondary use, outside the institutional service the district outsourced, and it undermines the direct-control condition. Require an explicit contractual prohibition on training with district data, and verify the tenant setting rather than trusting the default.

Who is responsible when a teacher adopts an unapproved tool?

The district. FERPA obligations attach to the educational agency, not the individual staff member. That is precisely why the intake gate has to be fast — enforcement against teachers after the fact does not restore the data or cure the disclosure.

How long should a vendor keep student records after a contract ends?

Set it contractually — 30 to 60 days after termination is a common and defensible window — and require a written deletion certificate. Never accept "as long as the account remains active" or an unspecified retention period.

FAQ

Does FERPA apply to every school using cloud software?

FERPA applies to educational agencies and institutions receiving funds under applicable U.S. Department of Education programs — effectively all public K-12 districts and most colleges. Private schools taking no such funding may fall outside FERPA but are usually still bound by state student privacy statutes and by contract, so the practical controls look similar.

What is the difference between FERPA and state student privacy laws?

FERPA sets a federal disclosure floor centered on consent and the school official exception. Many state laws layer on affirmative vendor obligations — bans on targeted advertising, on selling student data, and on profiling — plus breach notification timelines FERPA does not specify. Build to the strictest state law that applies to you and FERPA compliance generally follows.

Do we need a separate agreement for every classroom software vendor?

Every vendor that receives personally identifiable information from education records needs a written agreement establishing the school official relationship. Tools requiring no accounts and receiving no student data can clear a lighter review. The SDPC national agreement model lets one negotiated body cover many vendors through per-vendor exhibits, which is how districts keep this tractable at scale.

How do we ensure teachers actually follow the review process?

Make approval faster than circumvention. A published catalog of pre-vetted tools, a genuine same-week answer on no-PII requests, and a named human who responds beat any policy memo. Where the process is slow, shadow adoption rises regardless of what the handbook says — that is a design signal, not a discipline problem.

Is single sign-on required for FERPA compliance?

FERPA requires "reasonable methods" to restrict access, not a specific technology. SSO with role-based provisioning from the student information system is the most reliable way to meet that standard at scale, because it deprovisions automatically when employment or enrollment changes. Manual account management is defensible only in very small settings and drifts quickly.

What should we do about a vendor that refuses to sign our agreement?

Treat refusal as a decision. Identify a substitute, set a migration date, and tell affected staff early with named alternatives. A vendor unwilling to commit contractually to the limits FERPA's school official exception requires cannot be brought into compliance through configuration alone.

Sources

• https://studentprivacy.ed.gov/ — U.S. Department of Education Student Privacy Policy Office
• https://www.ecfr.gov/current/title-34/subtitle-A/part-99 — 34 CFR Part 99, the FERPA regulations
• https://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html — Family Policy Compliance Office FERPA overview
• https://privacy.a4l.org/ — Student Data Privacy Consortium (Access 4 Learning)
• https://www.ftc.gov/business-guidance/privacy-security/childrens-privacy — FTC guidance on COPPA
• https://www.cisa.gov/K12Cybersecurity — CISA K-12 cybersecurity resources
• https://nces.ed.gov/ — National Center for Education Statistics
• https://www.nist.gov/cyberframework — NIST Cybersecurity Framework
• https://studentprivacycompass.org/ — Student Privacy Compass, Future of Privacy Forum

Related on PULSE

• How do you build a vendor security review process that teams actually use?
• What belongs in a data processing agreement with a SaaS vendor?
• How do you run an access recertification cycle without stalling the business?
• What is the right way to inventory shadow IT across an organization?
• How should an organization handle vendor subprocessor changes?
• What does a defensible data retention and deletion policy look like?