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

The district that found out during a breach notification

A mid-sized district — roughly 12,000 students, 900 staff, one full-time systems administrator wearing four hats — discovers that a math practice platform adopted by three teachers has been storing student names, grade-level, IEP accommodation flags entered in a free-text notes field, and two years of performance history. Nobody in central office signed a contract. The teachers clicked through a click-wrap terms-of-service page in 2025. The vendor's privacy policy permits "aggregated and de-identified analytics shared with partners," and its support team, based on a ticket, confirmed that engineers can read individual student records in production for debugging.

That is the shape of nearly every real FERPA problem with cloud-based classroom software. It is almost never a hacker. It is a legitimate teacher, making a defensible pedagogical choice, adopting a tool that never passed through a review that would have caught three specific things: no written agreement establishing the vendor as a school official, no contractual limit on the vendor's use of the data, and no control over which vendor employees can see records.

The FERPA question underneath is narrow and answerable. 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 gives schools an exception — the "school official" exception at 34 CFR § 99.31(a)(1)(i)(B) — that permits disclosure to a contractor, consultant, volunteer, or other outside party who performs an institutional service the school would otherwise use employees to perform. But that exception carries four conditions that must all be true simultaneously. The vendor must perform a service the district would otherwise handle itself. It must be under the direct control of the district with respect to use and maintenance of the records. It must be subject to § 99.33(a) requirements limiting redisclosure. And the district must use reasonable methods to restrict access to records to those officials with legitimate educational interest.

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

Adjacent to this sits a second problem districts consistently underestimate: the same review discipline needs to cover tools nobody classifies as "classroom software." Learning management systems get reviewed. The single sign-on layer, the student information system's 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, the transcription service running on recorded lessons — these carry education records too. A district that reviews only the tools with "classroom" in the name has reviewed maybe 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 of them missing rather than all three.

Layer one: the annual notification defines the exception's scope. FERPA requires districts to annually notify parents 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 vibe; 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.

What the numbers actually look like

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 that have been 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 that already uses 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: it is not that their privacy posture is inherently better, it is that the transaction cost of verifying it collapses.

Access recertification. Districts that run access reviews find stale accounts every single 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: what you give up for each control

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 that require 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 does the terms-of-service permit the vendor to do with the data, and will they 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 that 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, the AI features should be disabled at the tenant level rather than the platform rejected wholesale. Most enterprise plans support that toggle.

Where districts get this wrong

Treating the DPA as the finish line. A signed agreement that 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 is relying 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 that are 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.

Building the program in ninety days

For a district starting from nothing, sequence matters more than ambition.

Days 1–15: discover. Export the OAuth application list from your identity tenant. Pull the accounts-payable ledger for anything coded to software or instructional technology. Survey principals with one question: what tools do your teachers actually use. Reconcile the three lists. You now have an inventory, and it will be larger than leadership expects.

Days 16–30: triage. Sort into three buckets: touches PII with a signed agreement, touches PII without one, does not touch PII. The middle bucket is your work queue, ordered by student count exposed times data sensitivity. A tool holding special education records for 200 students outranks a tool holding names for 6,000.

Days 31–60: paper the gap. Check each unpapered vendor against the SDPC national agreement registry; many are already signed with some district and will countersign an exhibit quickly. For the rest, send your template. Set a decision date: vendors that will not sign by day 60 get scheduled for replacement, and communicate that to affected teachers early with alternatives named.

Days 61–75: configure. Turn on SSO everywhere it is available. Provision roles from the SIS. Disable vendor secondary use and model training toggles. Set retention. Restrict administrator counts 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 the recertification calendar. 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 student's 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 that take 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 that require no accounts and receive 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?