FERPA Data Protection Guide
How to protect student education records with iboss DLP. Covers data classification, access controls, incident response, and audit documentation.
What FERPA Protects
The Family Educational Rights and Privacy Act (20 U.S.C. § 1232g), commonly known as FERPA, protects the privacy of student education records. It applies to all educational agencies and institutions that receive funding under any program administered by the U.S. Department of Education, which includes virtually every public school district in the country.
FERPA protects personally identifiable information (PII) contained in education records. Education records are defined broadly as records that are directly related to a student and maintained by an educational agency or institution, or by a party acting on its behalf. PII includes but is not limited to: the student's name, the name of the student's parent or family members, the student's address, personal identifiers such as Social Security numbers or student ID numbers, indirect identifiers such as date of birth combined with place of birth or mother's maiden name, biometric records, and any other information that alone or in combination is linked or linkable to a specific student and would allow a reasonable person to identify the student.
Violations of FERPA can result in the withdrawal of federal funding, complaints to the Student Privacy Policy Office (SPPO) within the Department of Education, and significant reputational harm to the district. As student data increasingly flows through cloud-based systems and digital platforms, the technical controls governing data loss prevention have become as important as administrative policies.
Data Classification Framework
Effective FERPA compliance begins with a data classification framework that categorizes student information by sensitivity level and governs how each category may be stored, transmitted, and disclosed. Districts should establish at least three classification tiers.
Directory Information is the least restricted category. Under 34 CFR § 99.3, directory information includes data such as the student's name, address, telephone number, email address, date and place of birth, grade level, enrollment status, participation in officially recognized activities and sports, and degrees or awards received. Districts may disclose directory information without consent, but only after providing annual public notice to parents and eligible students and allowing them to opt out. The district must define which data elements it considers directory information in its annual FERPA notification.
Protected Education Records encompass all PII in education records that is not designated as directory information. This includes grades, transcripts, disciplinary records, special education records, attendance records with associated notes, counselor records shared with other school officials, health records maintained by the school, and any behavioral or assessment data. These records require written consent before disclosure to third parties, with limited exceptions under 34 CFR § 99.31.
Highly Sensitive Records require the strongest protections. This tier includes special education (IEP/504) records, mental health and counseling records, records related to disciplinary actions involving drugs, violence, or law enforcement, and records of students in foster care or experiencing homelessness. These records often have additional protections under IDEA, state law, or other federal statutes beyond FERPA.
- Tier 1 — Directory Information: name, address, email, grade level, enrollment status, awards (may disclose after opt-out notice)
- Tier 2 — Protected Education Records: grades, transcripts, attendance, behavioral data, assessment scores (consent required for disclosure)
- Tier 3 — Highly Sensitive Records: IEP/504 records, counseling notes, disciplinary records involving law enforcement, foster/homeless status (additional legal protections apply)
Access Control Requirements
FERPA limits access to education records to school officials with a legitimate educational interest. Under 34 CFR § 99.31(a)(1), a school official includes teachers, administrators, counselors, school board members, contractors, and other parties to whom the district has outsourced institutional services. Legitimate educational interest means the official needs to review the record to fulfill their professional responsibility.
Districts must define both 'school official' and 'legitimate educational interest' in their annual FERPA notification. The definition should be specific enough to be meaningful — broad definitions that effectively grant all employees access to all records undermine the purpose of the standard and create audit risk.
Technically, this translates to role-based access controls (RBAC) on all systems containing education records. Teachers should only access records for students in their classes. Counselors should access records for students on their caseload. Administrators should have broader but still scoped access. Student information systems, learning management systems, and any third-party platforms holding student data should enforce these boundaries.
The annual FERPA notification must be provided to parents of students currently in attendance and to eligible students (those 18 or older). The notification must inform parents and eligible students of their rights to inspect and review records, request amendments, consent to disclosures, and file a complaint with the SPPO. It must also specify directory information designations and the opt-out process.
- Define 'school official' and 'legitimate educational interest' with specificity in the annual notification
- Implement role-based access controls on the Student Information System (SIS)
- Restrict teacher access to records of students enrolled in their courses
- Audit access logs on the SIS and LMS quarterly to detect unauthorized record access
- Distribute the annual FERPA notification via multiple channels (mail, email, handbook)
- Provide a clear opt-out mechanism for directory information and track responses
- Maintain documentation of all consent-based disclosures of education records
Data Loss Prevention with iboss
The iboss cloud platform includes inline Data Loss Prevention (DLP) capabilities that inspect data in transit to prevent unauthorized disclosure of student PII. DLP policies can be configured to detect and block the transmission of education records through web uploads, email, cloud storage, messaging platforms, and other egress points.
The iboss DLP engine supports multiple detection methods relevant to FERPA compliance. Exact Data Matching (EDM) allows districts to hash and upload structured datasets — such as student ID numbers, SSNs, or name-plus-DOB combinations — so the DLP engine can detect when those specific data values appear in outbound traffic. This is particularly effective for detecting bulk data exfiltration. Pattern-based detection uses regular expressions to identify common PII formats such as Social Security numbers (XXX-XX-XXXX), student ID patterns unique to the district, and date-of-birth formats in combination with name fields.
Content inspection policies should be applied to all outbound web traffic, including uploads to cloud services, webmail platforms, social media, and file-sharing sites. Districts should create tiered DLP policies: a blocking policy that prevents transmission of highly sensitive records (Tier 3 data) to unauthorized destinations, a coaching policy that warns users when transmitting protected records (Tier 2) and requires justification, and a logging policy that records all instances of directory information (Tier 1) leaving the network for audit purposes.
The iboss CASB (Cloud Access Security Broker) capabilities extend DLP into sanctioned cloud applications, enabling inspection of data stored in and shared through platforms like Google Workspace and Microsoft 365. Inline CASB policies can prevent students or staff from sharing documents containing PII with external recipients.
- Configure Exact Data Matching with hashed student ID and SSN datasets
- Create regex patterns for district-specific student ID formats
- Apply DLP inspection to all outbound HTTP/HTTPS traffic
- Block transmission of Tier 3 data (IEP records, SSNs) to all external destinations
- Configure coaching prompts for Tier 2 data (grades, transcripts) with justification workflow
- Log all instances of Tier 1 data (directory information) in outbound traffic
- Enable CASB inline DLP for Google Workspace and Microsoft 365
- Set up DLP incident alerts to the district privacy officer and technology director
Third-Party Vendor Management
FERPA's school official exception (34 CFR § 99.31(a)(1)(i)(B)) permits districts to disclose PII from education records to third-party contractors and service providers without parental consent, provided specific conditions are met. The contractor must perform an institutional service or function for which the district would otherwise use employees, must be under the direct control of the district with respect to the use and maintenance of education records, and must use the information only for the purposes for which the disclosure was made. The contractor must also be subject to the same FERPA restrictions on re-disclosure that apply to school officials.
In practice, every EdTech vendor, cloud service provider, and managed service provider that receives student PII must be covered by a written agreement establishing these conditions. Data Privacy Agreements (DPAs) should specify what data the vendor receives, the permitted uses, security requirements, breach notification obligations, data retention and deletion timelines, and the prohibition on re-disclosure or commercial use of student data.
Districts should maintain a centralized vendor inventory that lists every third-party service with access to student data, the categories of PII shared, the legal basis for disclosure, the DPA expiration date, and the results of any security assessment. The Student Data Privacy Consortium (SDPC) National DPA template is widely used and provides a strong contractual framework that addresses FERPA's school official requirements.
iboss CASB visibility is essential for enforcing vendor management policies. Shadow IT — unauthorized applications accessed by staff or students — can result in student data flowing to vendors without DPAs in place. The iboss cloud application discovery feature identifies all SaaS applications in use across the district, enabling the technology team to evaluate and either sanction or block each application.
- Execute Data Privacy Agreements with every vendor receiving student PII
- Use the SDPC National DPA template or equivalent legal framework
- Maintain a centralized vendor inventory with data categories, legal basis, and DPA status
- Conduct security assessments of high-risk vendors (those receiving Tier 2 or Tier 3 data)
- Use iboss CASB to discover unauthorized cloud applications (shadow IT)
- Block unsanctioned applications that lack valid DPAs
- Review vendor inventory annually and remove inactive or non-compliant vendors
- Include data deletion/return requirements in all DPAs and verify compliance at contract end
Breach Response Procedures
While FERPA itself does not include a specific breach notification mandate, the Department of Education's guidance (PTAC guidance documents) makes clear that districts have an obligation to mitigate harm when a breach of student records occurs. Furthermore, nearly every state has enacted its own data breach notification law, many of which specifically cover education records. Districts must develop breach response procedures that satisfy both FERPA obligations and applicable state law.
A breach of education records occurs when PII from education records is accessed, disclosed, or acquired by an unauthorized person, or when a security incident compromises the confidentiality of such records. Common breach scenarios include: an employee emailing a spreadsheet of student records to the wrong recipient, a ransomware attack exfiltrating student data, a vendor suffering a data breach that exposes district records, or an unauthorized individual gaining access to the SIS.
The breach response procedure should include immediate containment and assessment steps, a severity classification framework, notification requirements (internal stakeholders, affected families, the state attorney general if required by state law, and the Department of Education if systemic), remediation actions, and a post-incident review. The response team should include the superintendent, technology director, district counsel, communications director, and the district privacy officer.
Notification timelines vary by state — some require notification within 30 days, others within 60 or 72 hours. Districts operating in multiple states or serving military families should default to the most stringent applicable timeline.
- Establish a breach response team with named roles and 24/7 contact information
- Define breach severity levels (low, medium, high, critical) with corresponding response actions
- Document containment procedures: isolate affected systems, preserve evidence, revoke compromised credentials
- Determine notification obligations under applicable state breach notification laws
- Prepare template notification letters for affected families
- Notify the Student Privacy Policy Office if the breach involves systematic FERPA non-compliance
- Conduct a post-incident review within 30 days and document lessons learned
- Update security controls and DLP policies based on breach findings
Audit Trail Requirements
Maintaining comprehensive audit trails is essential for demonstrating FERPA compliance and investigating potential violations. Audit logs should capture who accessed what records, when, from where, and what actions were taken. The Department of Education expects districts to be able to account for disclosures of education records and to detect unauthorized access.
Under 34 CFR § 99.32, districts must maintain a record of each request for access to and each disclosure of PII from education records. This record must include the parties who requested or received the information and the legitimate interests those parties had in requesting or obtaining the information. This disclosure log must be maintained as long as the education record itself is maintained.
Technical audit logs should complement the administrative disclosure records. All systems containing education records — the SIS, LMS, special education platforms, assessment systems, and data warehouses — should generate access logs capturing user identity, timestamp, records accessed, and actions performed (view, export, modify, delete). These logs should be centralized in a SIEM or log aggregation platform and retained for a minimum of three years, or longer if required by state law.
iboss provides a critical layer of audit logging at the network level. Web activity logs capture all data transmission events, and DLP logs specifically document instances where student PII was detected in outbound traffic. These logs provide evidence that the district is actively preventing unauthorized disclosures and can be invaluable during Department of Education investigations.
- Maintain FERPA disclosure logs as required by 34 CFR § 99.32
- Enable and centralize access logs on all systems containing education records
- Capture user identity, timestamp, records accessed, and action type in all logs
- Retain administrative disclosure logs for the life of the education record
- Retain technical access logs for a minimum of three years
- Review access logs quarterly to detect anomalous or unauthorized access patterns
- Archive iboss DLP incident logs as evidence of ongoing data protection
- Include audit trail documentation in the annual FERPA compliance review
iboss Configuration Guide for FERPA
The following iboss configuration steps establish a comprehensive FERPA data protection framework. These settings work in concert with administrative policies and access controls to create defense-in-depth for student education records. Each configuration should be documented with screenshots and archived as compliance evidence.
- Enable SSL/TLS Decryption to allow DLP inspection of encrypted outbound traffic
- Create a FERPA DLP Profile with Exact Data Matching using hashed student PII datasets (upload via iboss EDM tool)
- Configure PII pattern detectors: SSN (XXX-XX-XXXX), student ID format, name+DOB combinations
- Set DLP policy action to BLOCK for Tier 3 data detected in outbound traffic to external domains
- Set DLP policy action to COACH for Tier 2 data, requiring users to provide business justification before upload proceeds
- Set DLP policy action to LOG for Tier 1 directory information in outbound traffic
- Configure CASB discovery to identify all cloud applications accessed by staff and students
- Create an approved vendor application list in the CASB policy and block data uploads to unsanctioned apps
- Enable inline CASB DLP for Google Workspace — inspect sharing actions for external recipients and PII content
- Enable inline CASB DLP for Microsoft 365 — inspect OneDrive/SharePoint shares and Outlook attachments
- Configure DLP incident notifications: email alerts to the district privacy officer for all BLOCK and COACH events
- Set log retention to a minimum of 3 years for DLP event logs
- Generate a monthly FERPA DLP Summary Report and archive for compliance evidence
- Schedule quarterly DLP policy effectiveness reviews: analyze false positive rates and policy gaps