ai compliance privacy

Is Microsoft Copilot FERPA Compliant?

EduGenius Team··16 min read

Watch the EduGenius tutorials playlist

Feature walkthroughs, setup help, and practical learning workflows connected to this article.

Open Tutorials

Is Microsoft Copilot FERPA Compliant?

Microsoft Copilot cannot be "FERPA certified," because FERPA (20 U.S.C. § 1232g) issues no certificate to any software company. What Microsoft offers instead is one of the more concrete contractual positions on the market: its Online Services Data Protection Addendum designates Microsoft a FERPA "school official," so a district's Microsoft 365 Education agreement can support that district's own compliance. The district stays the legally responsible party.

Quick Answer: No AI vendor is FERPA certified, because FERPA binds the school district, not the software company, and offers no vendor seal. Microsoft's Online Services Data Protection Addendum (DPA) does name Microsoft a "school official" under FERPA's exception at 34 CFR § 99.31(a)(1), commits to the use limits at 34 CFR § 99.33(a), excludes under-18 data from model training, and does not mine content for advertising. That signed, district-reviewed contract is what supports compliance, not a badge, and a personal consumer Copilot login carries none of it.

If you have searched "is Microsoft Copilot FERPA compliant" hoping for a clean yes or no, the useful answer is a qualified one. Microsoft has done more contractual groundwork here than many AI vendors, which makes Copilot a comparatively strong case. It also does not settle the question on its own. This guide covers what Microsoft's contract actually promises, the one configuration gap that can undo a perfect contract, and how a school confirms its own footing before enabling Copilot for classroom use.

FERPA Binds Your District, Not Microsoft, So "Compliant" Has a Narrow Meaning

FERPA is a 1974 federal law that regulates schools and districts receiving U.S. Department of Education funding, not the software vendors they buy from. That single fact is why "Is Copilot FERPA compliant?" is really a question about your contract with Microsoft, not about a property the product holds on its own.

A vendor can support your compliance, but it cannot be compliant for you. When a page says a tool is "FERPA compliant," it is making one of three claims, and they carry very different weight:

  • A self-attestation, where Microsoft describes its own practices as consistent with FERPA. Informative, but not independently verified.
  • A signed contract, where the DPA in your Microsoft 365 Education agreement puts confidentiality and use limits in writing. Enforceable, and specific to your district.
  • An implied government seal, which does not exist for FERPA at all, since the law never created one.

Only the middle claim does real legal work. RAND's 2025 survey of U.S. teachers and principals found that 70% of principals weighed data privacy in their AI purchasing decisions, so the demand for a simple compliance stamp is understandable (RAND, 2025). FERPA simply does not supply one, which is why the complete school data-privacy guide to FERPA and COPPA treats the signed contract, not the marketing language, as the actual compliance mechanism.

The School-Official Exception in Plain Terms

FERPA's regulations at 34 CFR § 99.31(a)(1) let a school share education records with an outside vendor without collecting individual parental consent for every disclosure, but only when four conditions hold at once:

  1. The vendor performs a service the school would otherwise handle itself.
  2. The school keeps direct control over how the vendor uses the data.
  3. The vendor uses the data only for the authorized purpose.
  4. The vendor is barred from redisclosing the data without permission.

That test is the entire legal basis for a vendor touching student records. It exists on paper only when a signed contract puts it there.

What Microsoft's Online Services DPA Actually Commits To

A district's real FERPA protection with Copilot lives in the Microsoft 365 Education agreement, specifically the Online Services Terms and their Data Protection Addendum, where Microsoft agrees to be treated as a "school official" with a legitimate educational interest in customer data. Microsoft's own compliance documentation states it abides by the limitations at 34 CFR § 99.33(a) when it handles education records, the same way an in-house school official would (Microsoft, 2026).

Microsoft is unusually specific about the surrounding commitments, which is what makes Copilot a comparatively strong FERPA case rather than a vague one:

  • Customer data is processed only as the institution directs, not repurposed for Microsoft's own goals.
  • Content is not mined for advertising, a commitment that applies across Microsoft 365 and Copilot.
  • Data from users under 18 is excluded from foundation-model training, per Microsoft's published documentation.

The table below separates what the DPA genuinely locks in from what it deliberately leaves to the district, since conflating the two is where confident rollouts go wrong.

DPA commitmentWhat it actually coversWhat it leaves to the district
"School official" designation under FERPALets Microsoft touch education records without per-disclosure consentThe district must still sign and review the specific agreement
Processing only on documented instructionBars Microsoft from repurposing content for its own endsThe district defines what instruction and configuration it sets
No advertising use of contentRemoves a common commercial-use worryDoes not address who inside the school can see what
Training exclusion for under-18 accountsKeeps minors' content out of model trainingRequires accounts to be correctly flagged by age

None of that is a certificate. It is a contract, enforceable exactly to the degree your district's legal or data-privacy officer actually read the terms rather than trusting "Microsoft" as a brand to settle it.

The Permission-Inheritance Wrinkle That Is Uniquely Copilot's FERPA Problem

Full Microsoft 365 Copilot only surfaces content a signed-in user could already reach through existing SharePoint and file permissions, which sounds reassuring until a school's own permission hygiene becomes the actual FERPA boundary. This is the part of the answer that a contract alone cannot fix, and it is specific to how Copilot works.

Here is the trap in one sentence: a flawless DPA plus one overly broad sharing setting can still produce a FERPA disclosure. Copilot does not grant new access, but it makes old, forgotten access far easier to stumble into by surfacing a document in a search that a manual folder-browse never would.

Independent analyses of Copilot in education have flagged exactly this: if faculty or staff hold broader file access than intended, Copilot can surface student records those users should not see, turning a stale permission into a live disclosure risk. Microsoft's model is explicitly a shared responsibility, where the contract covers Microsoft's conduct and the district owns its own configuration.

A Grade 7 Scenario, Walked Through

Say you teach Grade 7 and your district has just enabled full Microsoft 365 Copilot for staff. Before leaning on it, three checks matter more than the contract itself:

  1. Audit the sharing settings on the class folders you actually use. A drive folder shared broadly years ago for a substitute or a parent volunteer is exactly what Copilot can now surface in a search.
  2. Confirm that student-facing accounts are correctly age-flagged, so the under-18 training exclusion and youth data handling apply as intended.
  3. Separate "the DPA covers this" from "my building is configured for this." The first is a legal fact; the second is an IT task that has to actually happen.

That third point is the whole lesson. The companion guide on whether Copilot is COPPA compliant covers the age-eligibility mechanics in depth; the FERPA question adds this configuration layer on top, because a school's permission settings become part of its privacy boundary the moment Copilot is switched on.

Consumer Copilot vs Microsoft 365 Copilot: Only One Has FERPA Footing

The FERPA protections described above apply to Microsoft 365 Copilot inside a managed school tenant, not to the consumer Copilot a student or teacher might sign into with a personal Microsoft account. This distinction is easy to miss because both products carry the "Copilot" name, yet only one sits under a DPA.

A personal login at copilot.microsoft.com runs on consumer terms with no institutional data protection, no "school official" designation, and no district oversight. If a teacher pastes an identifiable student's work into a personal Copilot session, none of the education agreement's commitments apply to that interaction.

DimensionMicrosoft 365 Copilot (managed tenant)Consumer Copilot (personal account)
FERPA "school official" statusYes, through the district's signed DPANo; governed by consumer terms
Data-processing instruction controlHeld by the institutionHeld by the individual user
Under-18 training exclusionApplies to correctly flagged accountsNot an education-managed protection
Who should use it with student dataStaff, under district configurationNo one, for identifiable student records

The practical takeaway is blunt: the account matters as much as the product. A district that has done everything right at the tenant level still has a FERPA gap if teachers default to personal Copilot logins for convenience.

The Subprocessor Question: Which Model Sits Behind Copilot

FERPA's school-official exception requires the district to keep "direct control" over how student data is used and to bar redisclosure, which raises a fair question about the foundation models Copilot routes through. Microsoft 365 Copilot runs its large language models inside the Microsoft 365 service boundary rather than sending tenant content out to a separate consumer service, and that design point is what keeps the DPA's commitments intact across the processing chain.

The reason this matters: a no-training or use-limitation promise is only as strong as how far down the stack it actually reaches. A commitment that stops at the application layer, while a model provider underneath operates under looser terms, has a gap precisely where a district most needs it closed.

Three questions put the point to the test:

  • Confirm the commitment covers the model layer, not just the app. A district should see in writing that the training exclusion and use limits apply to every model the product calls.
  • Ask whether any content leaves the Microsoft 365 trust boundary during a Copilot request, since that boundary is what keeps the education agreement's protections continuous.
  • Treat a subprocessor change as a notice event. A DPA worth signing requires the district be told if the processing chain behind the product changes materially.

Most districts skip this layer, because "we contracted with Microsoft" feels complete. The four-part school-official test cares about the whole chain that touches an education record, not only the brand on the invoice.

When Copilot Content Actually Becomes an "Education Record"

A FERPA "education record" is information directly related to an identifiable student and maintained by the school or a party acting for it, which means a Copilot prompt or output can become one depending entirely on what goes into it. Copilot's typical footprint is narrower than a grading platform's, because much of its classroom use is teacher productivity rather than stored student data.

The distinction is worth holding onto:

  • A Copilot Chat exchange that names a student and discusses their performance can be an education record, since it is identifiable and maintained inside the tenant.
  • A lesson-plan draft built from a topic and grade level generally is not, because no identifiable student is involved.
  • A summary of a document a teacher pasted in inherits whatever the source contained, which is why prompt hygiene matters regardless of the contract.

This is a meaningful contrast with a tool like Gradescope, where the stored graded work is the education record by design; the analysis in the Gradescope FERPA guide shows how differently that plays out for a records-holding platform. With Copilot, a teacher has real influence over how much education-record data ever enters the system, simply by choosing what to type. Describing "a small group reading two grade levels behind" keeps a prompt useful without naming a child.

How Copilot's FERPA Footing Compares to Other Classroom Tools

Copilot's contract-based FERPA model, a signed DPA carrying a "school official" designation, is the same basic structure most enterprise education vendors use, but the specifics vary enough that one tool's posture never transfers to the next. A district evaluating a stack of AI tools has to review each one on its own contract, not extrapolate from the biggest brand in the pile.

A few contrasts make the point concrete:

  • A grading platform stores graded student work as its core function, so its education-record surface is large and constant, a different profile than Copilot's mostly teacher-facing use.
  • A lighter classroom tool aimed at younger grades, such as the leveling tool covered in Diffit and student data privacy, documents its data handling for a different age band and purpose than an enterprise productivity suite.
  • Two tutoring products in the same category can document consent and data handling in genuinely different ways, as the side-by-side comparison in SchoolAI vs Khanmigo illustrates.
Tool typePrimary FERPA data surfaceTypical compliance route
Enterprise productivity AI (Copilot)Prompts and outputs a teacher chooses to enterSigned DPA, "school official" designation
Grading or assessment platformStored graded work, an education record by designInstitutional contract inherited from the vendor
Classroom content or leveling toolMaterial generated for a class, often no student PIIVendor DPA plus district configuration

The lesson for a privacy officer: never assume the tool approved last month sets the standard for the one in front of you now, even when both are broadly "AI-powered" and both serve the same building.

A FERPA-Readiness Checklist Before Enabling Copilot

Turning the analysis above into a defensible rollout is a sequencing task. Work these in order and get written answers, not verbal reassurances.

  1. Confirm a current DPA is in place for your Microsoft 365 Education tenant, and route it through legal or a data-privacy officer, not procurement alone.
  2. Audit file and folder permissions on anything a class touches, since Copilot's access mirrors existing sharing settings.
  3. Verify age-group flags on student accounts, so the under-18 protections and training exclusion apply where they should.
  4. Set a policy against personal consumer Copilot logins for any student data, and give staff the managed alternative instead.
  5. Ask whether the training-exclusion commitment extends to every model Copilot routes through, in writing, not just Microsoft's own layer.
  6. Check your state statute, because California's SOPIPA (2014) and Illinois's SOPPA (2021) can require more than FERPA's federal floor.

Pro Tips From a Rollout Point of View

  • Treat the permission audit as recurring, not one-time. A folder scoped correctly in September can drift by spring.
  • Not every AI task needs student-facing access. For quizzes, worksheets, and flashcards tied to a class profile, a teacher-directed generator like EduGenius can produce differentiated material from a grade level and subject without a student ever holding an account or a record entering a chat log, which sidesteps the education-record question for that task entirely.
  • Document which buildings and grade bands have which Copilot surfaces enabled, so next year's review starts from fact rather than memory.

What to Avoid

  • Do not treat "Microsoft is a trusted brand" as a substitute for the signed DPA. Reputation is not a legal instrument; the contract is.
  • Do not enable Copilot broadly before auditing sharing permissions. A stale "anyone in the organization" setting becomes a live disclosure risk once Copilot can surface it.
  • Do not let staff use personal Copilot accounts with identifiable student work. The education-agreement protections simply do not reach a consumer login.
  • Do not assume the DPA answers your state law too. A FERPA-satisfying contract can still fall short of a stricter state student-data statute.

Key Takeaways

  • No vendor, Microsoft included, can be "FERPA certified," because FERPA binds the district and creates no vendor seal. The compliance mechanism is a signed contract, not a badge.
  • Microsoft's Online Services DPA names Microsoft a "school official" under 34 CFR § 99.31(a)(1) and commits to the use limits at 34 CFR § 99.33(a), which makes Copilot a comparatively concrete FERPA case (Microsoft, 2026).
  • The DPA's real strength is undone by weak permission hygiene, since full Copilot surfaces content a user can already access, making a district's own SharePoint settings part of its FERPA boundary.
  • Only Microsoft 365 Copilot in a managed tenant carries FERPA footing; a personal consumer Copilot login has none of the education-agreement protections.
  • Copilot content becomes an "education record" based on what a teacher enters, giving prompt hygiene real weight and keeping the education-record surface narrower than a grading platform's.
  • A defensible rollout confirms the DPA, audits permissions, verifies age flags, and checks state law before Copilot reaches a classroom.

Frequently Asked Questions

Does Microsoft Copilot have a FERPA certification?

No, and no AI vendor does, because FERPA legally binds schools and districts rather than software companies, leaving nothing for a vendor to be certified against. Microsoft's FERPA-relevant commitment is contractual: its Online Services Data Protection Addendum designates Microsoft a "school official" and follows the use limits at 34 CFR § 99.33(a).

Is a personal Copilot login covered by the same FERPA protections as a school account?

No. The FERPA "school official" designation, processing controls, and under-18 protections apply to Microsoft 365 Copilot inside a managed education tenant. A consumer Copilot account signed into with a personal Microsoft account runs on consumer terms, so identifiable student data should never be entered into it.

Can a signed DPA still leave a FERPA gap with Copilot?

Yes. Because full Microsoft 365 Copilot surfaces content a user can already access through existing file permissions, an overly broad sharing setting can expose student records even under a flawless contract. FERPA compliance with Copilot is a shared responsibility, so a district must audit its own permission hygiene alongside the agreement.

What should a district confirm before enabling Copilot for teachers?

Confirm a current Data Protection Addendum is in place, audit sharing permissions on folders a class touches, verify age-group flags on student accounts, prohibit personal Copilot logins for student data, and check state statutes like California's SOPIPA or Illinois's SOPPA that can require more than FERPA's federal floor alone.

Are the outputs Copilot generates about a student part of the education record?

They can be. If a Copilot Chat exchange names an identifiable student and is maintained within the school's tenant, it can meet FERPA's definition of an education record, the same way a teacher's saved notes would. Content with no identifiable student, such as a generic lesson plan, generally does not qualify.

#administrators#data-privacy#ai-tools