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.

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.

Migration-Specific FERPA Risks

Data migration introduces several unique FERPA compliance risks that don't exist during normal operations:

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.

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.

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 that violate FERPA's "reasonable methods" requirement.

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.

FERPA Compliance Checklist for Migration

Use this comprehensive checklist to ensure your migration meets all FERPA requirements:

Pre-Migration Phase

• ☐ Inventory all PII fields — Student names, addresses, student IDs, dates of birth, Social Security numbers (if stored), grades, disciplinary records, IEPs, health information, and any other identifying data
• ☐ Map data sensitivity levels — Not all PII is equal. Medical records and disciplinary files require higher protection than directory information
• ☐ Review your school's annual FERPA notification — Ensure parents have been notified about directory information policies
• ☐ Identify data that requires parental consent — Certain records (like mental health notes) may need explicit consent before transfer
• ☐ Document your "legitimate educational interest" policies — Who normally has access to what data in your current system?

During Migration

• ☐ Encrypt all data in transit — Use SFTP (port 22) with SSH keys or HTTPS with TLS 1.2+ for all data transfers. Never send PII via regular email or unencrypted FTP
• ☐ Use time-limited credentials for vendor access — Create temporary accounts that expire automatically after migration completion
• ☐ Enable full audit logging — Log every data read, write, and delete operation during migration with timestamps and user identifiers
• ☐ Limit data exposure in test migrations — Use anonymized or synthetic data for testing whenever possible. If real data is required, minimize the dataset to the smallest viable sample
• ☐ Verify encryption at rest in the target system — Ensure the new system uses encrypted storage for all student records

Post-Migration Phase

• ☐ Review access controls in the new system — Verify that only authorized staff have access to student records and that role-based permissions are correctly configured
• ☐ Retain migration audit logs for the required period — FERPA requires access records to be kept as long as the education records themselves
• ☐ Securely delete data from temporary storage — Any temporary files, caches, or backup copies used during migration must be securely deleted
• ☐ Update your directory information notice if needed — If the new system changes what information is considered directory information, parents may need new notification
• ☐ Document the migration for audit purposes — Maintain a complete record of the migration process, including vendor names, dates, data volumes, and security measures used

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.

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

Required Contract Elements

Your Data Processing Agreement (DPA) with any migration vendor must include:

• A specific list of permitted uses of the data (only migration-related activities)
• A prohibition on redisclosure to third parties
• Security requirements (encryption, access controls, breach notification)
• Data retention and deletion requirements
• Audit rights for the school
• Indemnification for data breaches caused by the vendor

Encryption Requirements Under FERPA

While FERPA doesn't explicitly mandate encryption, the "reasonable methods" standard effectively requires it. 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

• 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; encrypted backups with separate key management
• Key management: Encryption keys should be stored separately from encrypted data and accessible only to authorized personnel

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.

Breach Response Plan

Despite best efforts, data breaches can happen during migration. Your migration plan must include a breach response protocol:

Detection and Containment

• Real-time monitoring: Set up alerts for unusual access patterns during migration
• Immediate containment: Have the authority to suspend migration and revoke access credentials instantly
• Forensic preservation: Preserve all logs and system states for investigation

Notification Requirements

While FERPA doesn't have a mandatory breach notification timeline like GDPR or state laws, 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
• What types of information were involved
• What steps you've taken to contain the breach
• What steps affected individuals can take to protect themselves
• Who to contact for more information

Documentation Requirements

Maintain thorough documentation of any breach, including:

• Date and time of discovery
• Description of the incident
• Root cause analysis
• Remediation steps taken
• Notifications sent
• Lessons learned 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. 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), 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), you should plan to retain migration audit logs indefinitely or at least for the duration you keep the associated student records.

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.