Microsoft Copilot in Education: FERPA and Governance Checklist
A practical checklist for IT and compliance leaders to verify that Microsoft Copilot deployments meet FERPA data access and governance requirements before institution-wide rollout.
Governance pillars at a glance
Before expanding Copilot across the institution, confirm coverage across these four pillars. Each maps directly to the detailed checklist later on this page.
- Data access scoping Identify which Copilot data sources and connectors touch FERPA-protected records.
- Least-privilege permissions Audit SharePoint, OneDrive, Teams, and Exchange permissions before rollout.
- Audit logging Confirm Purview Audit coverage for Copilot prompts and responses.
- Ongoing oversight Establish recurring review as connectors and agents are added.
How Microsoft Copilot's data access model creates FERPA exposure
Microsoft 365 Copilot does not apply independent access logic to student data. It surfaces content that the signed-in user already has permission to access under existing Microsoft 365 permission models, including SharePoint, OneDrive, Teams, and Exchange. This means Copilot's FERPA exposure risk originates primarily from pre-existing over-permissioned repositories and mailboxes rather than from any AI-specific access mechanism.
Student information systems and learning management systems are not natively indexed by Copilot. Access to SIS or LMS data requires an explicit connector, built through Microsoft Graph connectors or a Copilot Studio agent, which introduces a separate governance surface with its own permission and vendor-terms review requirements.
FERPA (34 CFR Part 99) requires written consent before disclosing personally identifiable information from education records, subject to enumerated exceptions. The school official exception under 34 CFR §99.31(a)(1) permits disclosure to a contracted service provider only when the institution retains direct control over that party's use and maintenance of education records for authorized purposes. No primary Microsoft or U.S. Department of Education source confirms that Microsoft 365 Copilot is inherently FERPA compliant. Outcomes depend on tenant configuration, license tier, and how connectors to SIS or LMS platforms are governed. Department of Education PTAC guidance on online educational services predates generative AI and does not directly address AI summarization or retrieval behavior, leaving institutions to map Copilot activity against existing FERPA obligations rather than an AI-specific standard.
Where native controls leave gaps
Point-in-time configuration does not by itself provide continuous verification that Copilot's behavior stays within FERPA-permitted boundaries as staff roles change, new connectors are added, or sensitivity labeling drifts out of alignment with actual repository contents. Native Microsoft 365 and Purview controls are configuration-based: Restricted Content Discovery operates at the SharePoint site level, sensitivity labeling depends on comprehensive and current tagging, and audit logging availability varies by license tier. These mechanisms establish the boundaries within which Copilot operates once configured, but they do not enforce policy at the moment Copilot attempts to access or summarize a specific piece of content.
This is the gap that runtime governance addresses as a category: enforcing agent permissions and tool access at the point of use, rather than relying solely on upstream permission configuration and periodic audit review. Trussed AI provides runtime governance and security for enterprise AI agents, including runtime policy enforcement, agent identity and permissions management, and audit logging for AI agent activity. For institutions running Copilot alongside Copilot Studio agents or other AI tools connected to SIS or LMS platforms, this kind of runtime oversight complements Microsoft 365 admin and Purview controls rather than replacing the underlying permissions and labeling work described below.
Configuration is necessary, not sufficient
Restricted Content Discovery, sensitivity labels, and Purview Audit set boundaries. Runtime policy enforcement helps keep agent behavior inside those boundaries as connectors, roles, and content change over time.
FERPA compliance checklist for Microsoft Copilot
Use the following items to prepare the tenant, constrain access, enable auditability, and sustain review as the environment evolves. Work through each group in order when possible; discovery and legal basis should precede broad enablement.
1. Inventory and legal basis
- Inventory all SharePoint sites, OneDrive locations, Teams channels, and Exchange mailboxes containing grades, disciplinary records, accommodation details, or other education records covered by FERPA.
- Confirm whether Copilot is limited to native Microsoft 365 workloads or extended to SIS/LMS data through Graph connectors or Copilot Studio agents, and treat each connector as a separate scope requiring its own review.
- Document which user groups or licenses have Copilot enabled and cross-reference that population against staff who already have access to FERPA-protected repositories.
- Verify that contractual terms with Microsoft satisfy FERPA's school-official exception, specifically the requirement that the institution retains direct control over the vendor's use and maintenance of education records.
- Review any Copilot Studio agent or connector configuration for its own access scope and vendor data-use terms, independent of native Microsoft 365 Copilot governance.
2. Permissions and access controls
- Conduct a permissions audit across SharePoint, OneDrive, Teams, and Exchange to identify over-permissioned access to student records before expanding Copilot availability.
- Enable or restrict Microsoft 365 Copilot access at the user, group, or license level through the Microsoft 365 admin center, aligning access with roles that legitimately require it.
- Apply Restricted Content Discovery to exclude SharePoint sites containing FERPA-protected records from being surfaced by Copilot and Microsoft Search.
- Apply Microsoft Purview sensitivity labels and Data Loss Prevention policies comprehensively across student-data repositories, since partial labeling leaves gaps in Copilot summarization restrictions.
- Pilot Copilot with a limited administrative or compliance group first, and validate that FERPA-protected content is not unexpectedly surfaced before institution-wide rollout.
3. Audit logging and retention
- Enable Microsoft Purview Audit for Copilot activity logging, including prompts and responses, where the institution's license tier supports it.
- Confirm whether the deployed Microsoft 365/Education license tier, such as E5/A5 versus E3/A3, supports the audit logging and retention period needed for FERPA recordkeeping.
- Integrate Copilot audit log output into existing records-retention and incident-response workflows rather than treating it as a standalone log source.
- Establish a process for reviewing Copilot audit logs when a FERPA-related access question or complaint arises.
4. Ongoing oversight
- Designate a data-stewardship owner responsible for periodically re-reviewing Copilot's data-access scope as new connectors or Copilot Studio agents are introduced.
- Require a FERPA-scope review before any new SIS or LMS connector or Copilot Studio agent is connected to the tenant.
- Reassess sensitivity-label coverage and Restricted Content Discovery configuration on a recurring schedule rather than treating initial setup as permanent.
- Maintain documentation mapping each Copilot data source and connector to the FERPA disclosure exception, if any, that justifies its access to education records.
Verify Copilot governance before institution-wide rollout
Review how runtime governance can complement Microsoft 365 admin and Purview controls for Copilot and connected AI agents handling student data.
Talk to an Expert