FERPA Compliance During School Data Migration

What is FERPA?

The Family Educational Rights and Privacy Act (FERPA) is a federal law enacted in 1974 that protects the privacy of student education records. Any educational institution that receives funding from the U.S. Department of Education must comply with FERPA. This includes public K-12 schools, school districts, and most colleges and universities.

FERPA gives parents certain rights regarding their children's education records, and these rights transfer to the student when they turn 18 or attend a postsecondary institution. Under FERPA, schools must have written permission from parents or eligible students to release any personally identifiable information (PII) from a student's education record, with certain exceptions for school officials with legitimate educational interest.

What constitutes an "education record" under FERPA? Almost any record maintained by the school that is directly related to a student qualifies, including grades, transcripts, class schedules, disciplinary records, attendance logs, special education records, health records, and even emails containing student information. Backups and archives containing these records are also protected.

Migration-Specific FERPA Risks

Data migration introduces several unique FERPA compliance risks that don't exist during normal operations. Understanding these risks allows you to build appropriate safeguards.

1. Data in Transit Vulnerabilities

Student records moving between systems can be intercepted if proper encryption isn't used. Unencrypted CSV files attached to emails, FTP transfers without TLS, or APIs without HTTPS all create interception points where PII could be exposed. During migration, data often traverses multiple networks—your LAN, a vendor's VPN, and cloud infrastructure—multiplying exposure points.

2. Vendor Access and Control

Migration consultants, vendor support teams, and third-party ETL tool providers may need access to live student data during the migration. Under FERPA, these third parties must be designated as "school officials" with a "legitimate educational interest," and they must agree in writing to data protection standards. Verbal assurances are not sufficient.

3. Incomplete or Corrupted Transfers

Partial migrations can create orphaned records, duplicate entries, or mismatched data that may inadvertently grant access to the wrong people or create security gaps. A student record partially migrated might lack the enrollment restrictions that prevent them from seeing another student's data.

4. Audit Trail Gaps

FERPA requires schools to maintain records of who accesses student data and why. Migration periods often involve high-volume data processing that can overwhelm standard logging systems, creating gaps in your audit trail. If you cannot prove who touched student data during migration, you cannot demonstrate compliance.

FERPA Compliance Checklist for Migration

Use this comprehensive checklist to ensure your migration meets all FERPA requirements. We recommend printing this and having your legal counsel and IT director sign off on each phase.

Working with Vendors and Contractors Under FERPA

FERPA permits schools to disclose student records to outside parties only under specific conditions. For migration vendors, the "school official" exception is your primary path to compliance, but it has strict requirements.

The "School Official" Exception Requirements

Under 34 CFR § 99.31(a)(1), a school may disclose PII from education records without consent to "school officials" whom the school has determined to have a "legitimate educational interest." For a vendor to qualify as a school official:

• The vendor must perform a service that the school would otherwise perform internally (data migration qualifies)
• The vendor must be under the "direct control" of the school regarding the use and maintenance of the data
• The vendor must agree in writing not to redisclose the data for other purposes
• The vendor must use the data only for the authorized purpose and return or destroy it when done

Required Contract Elements (Data Processing Agreement)

Your DPA with any migration vendor must include these elements to satisfy FERPA:

• A specific list of permitted uses of the data (only migration-related activities)
• A prohibition on redisclosure to third parties without school consent
• Security requirements (encryption standards, access controls, breach notification timelines)
• Data retention limits and deletion requirements with certification of destruction
• Audit rights for the school to inspect vendor security practices
• Indemnification for data breaches caused by the vendor's negligence
• Subprocessor disclosure — if the vendor uses subcontractors, they must be listed and bound by equivalent terms

Encryption Requirements Under FERPA

While FERPA doesn't explicitly mandate encryption in statute, the "reasonable methods" standard effectively requires it for digital records. The U.S. Department of Education's guidance on cloud computing states that encryption of data in transit and at rest is a best practice that schools should implement to meet their FERPA obligations.

Acceptable Encryption Standards for School Data Migration

• Data in transit: TLS 1.2 or higher for web transfers; SFTP with SSH-2 for file transfers; VPN with AES-256 for direct database connections
• Data at rest: AES-256 encryption for databases and storage volumes; encrypted backups with separate key management
• Key management: Encryption keys should be stored in a separate Key Management Service (KMS), accessible only to authorized personnel, with rotation policies
• End-to-end encryption: For highly sensitive records (medical, disciplinary), consider end-to-end encryption where the vendor cannot decrypt without school participation

If your migration involves transferring data outside your school's network (to a cloud SIS or LMS), encryption is not optional—it's the minimum standard to protect student PII from interception. Unencrypted transfers during migration are one of the most common findings in Department of Education compliance reviews.

Breach Response Plan

Despite best efforts, data breaches can happen during migration—stolen laptops, compromised vendor credentials, or misconfigured cloud storage. Your migration plan must include a breach response protocol.

Detection and Containment

• Real-time monitoring: Set up alerts for unusual access patterns during migration (e.g., downloads outside business hours, bulk exports)
• Immediate containment: Have the authority to suspend migration and revoke access credentials instantly, without waiting for vendor approval
• Forensic preservation: Preserve all logs and system states for investigation before they rotate out
• Isolation: Segregate affected systems from the network to prevent lateral movement

Notification Requirements

While FERPA doesn't have a mandatory breach notification timeline like GDPR, the U.S. Department of Education expects "timely notification" when unauthorized disclosure of PII occurs. Many states have their own student data breach notification laws with specific deadlines (e.g., 30-60 days).

Your notification should include:

• What happened and when, with specific systems and data types affected
• What types of student information were involved (directory info vs. sensitive PII)
• What steps you've taken to contain the breach and prevent recurrence
• What steps affected individuals can take to protect themselves (credit monitoring, password changes)
• Who to contact for more information, with direct phone and email

Documentation Requirements

Maintain thorough documentation of any breach, including:

• Date and time of discovery and who discovered it
• Description of the incident with technical details
• Root cause analysis with contributing factors
• Remediation steps taken and verification of effectiveness
• Notifications sent and to whom, with copies
• Lessons learned and process changes for future migrations

FERPA Migration FAQs

Q: Can we use a migration vendor that stores data on servers outside the US?

A: Possibly, but with significant caution. FERPA doesn't explicitly prohibit international data transfers, but you must ensure the vendor complies with FERPA requirements. Some vendors have implemented EU-U.S. Data Privacy Framework compliance, which can help. However, many schools prefer domestic data hosting for simplicity and to avoid jurisdictional complexity. Consult your legal counsel before transferring student data internationally.

Q: Do we need parental consent to migrate student data to a new SIS?

A: Generally no, provided the migration is part of normal school operations and the new system serves legitimate educational purposes. The "school official" exception covers routine data management activities. However, if the new system will use data for purposes beyond normal educational functions (like selling data to third parties or using it for non-educational AI training), consent would be required. Review your new vendor's data use policies carefully.

Q: How long must we retain migration logs?

A: FERPA requires that records of access to education records be maintained "as long as the education records themselves are maintained." Since student records are typically kept for years (sometimes permanently for transcripts), you should plan to retain migration audit logs indefinitely or at least for the duration you keep the associated student records. Check your state records retention laws for specific minimums.

Q: What if our old SIS vendor refuses to sign a DPA?

A: This is a significant red flag. If the old vendor (source system) won't sign a DPA, they are essentially refusing to acknowledge their FERPA obligations. Options: (1) Escalate within the vendor's organization—someone in legal or compliance should understand FERPA requirements; (2) If you control the database (on-premise installation), you may not need a DPA from them since you're extracting data you already control; (3) Consider whether you can extract data yourself using built-in export tools, avoiding the need for vendor access to your data.