FERPA and Cloud Computing: What Universities Need to Know
The Family Educational Rights and Privacy Act (FERPA) remains one of the most misunderstood federal privacy statutes in higher education, particularly as institutions increasingly migrate student records to cloud-based systems. While FERPA itself doesn't explicitly prohibit cloud computing, the regulation's requirements create specific compliance obligations that universities must carefully navigate when selecting, implementing, and managing cloud service providers.
Unlike HIPAA or GDPR, FERPA doesn't require encryption, specific security standards, or data processing agreements in its regulatory text. This absence of prescriptive technical requirements can create false comfort among compliance teams—but it also means FERPA compliance depends heavily on institutional controls and vendor relationships. Understanding this distinction is critical to avoiding enforcement actions.
The Core FERPA Requirements You Cannot Delegate
FERPA's foundational obligation appears in 34 CFR §99.3: institutions must ensure that education records are maintained with "appropriate safeguards." This is not a suggestion—it's a legal standard that applies regardless of where your data physically resides. The regulation defines education records broadly as records "directly related to a student" and "maintained by an educational institution," which includes cloud-hosted systems.
A critical misunderstanding among many universities: simply signing a data processing agreement with a cloud vendor does not transfer your FERPA obligations. 34 CFR §99.37 addresses disclosure of records and requires that institutions maintain "effective policies and procedures to ensure that school officials obtain access to education records only in cases in which they have a legitimate educational interest." When you move to cloud infrastructure, you are still responsible for defining and enforcing who can access what data—your cloud vendor executes your policies; they don't create them.
The second core requirement involves your notification obligations under 34 CFR §99.37(a). You must inform students of their rights to access and amend their records. Cloud migration doesn't change this requirement, but it may change your technical ability to fulfill it. If your cloud system doesn't support the access and amendment processes you've promised students, you have a compliance gap before your first data record moves to the cloud.
Practical Compliance Steps for Cloud Migration
Step 1: Inventory Your Education Records Carefully
Before selecting a cloud provider, conduct an honest audit of what data you currently maintain and what you intend to move. Many institutions discover they've been treating non-FERPA data as if it were protected, or conversely, they've failed to recognize that certain systems contain education records. Directory information (name, address, phone number, email, photo, honors) has special status under FERPA—it can be disclosed unless a student opts out—but you must actively manage these distinctions in your cloud architecture.
Step 2: Evaluate Your Vendor's Safeguards Against Your Risk Profile
Since FERPA doesn't specify encryption or security standards, you must determine what "appropriate safeguards" means for your institution. This requires honest risk assessment. A small liberal arts college storing records in a major cloud provider's data center likely has different risk profiles than a large research university processing sensitive biometric or health data alongside student records. Your safeguard requirements should be documented and then used to evaluate vendors. Ask detailed questions about data location, access controls, audit logging, incident response procedures, and data retention. Document their answers and require contractual commitments.
Step 3: Establish a Data Processing Agreement
While not explicitly required by FERPA's regulatory text, a well-drafted data processing or business associate agreement serves as your primary control mechanism. This agreement should specify: (1) what data the vendor will process and for what purposes; (2) your authorization requirements for any secondary uses; (3) the vendor's obligation to implement security safeguards; (4) restrictions on subcontractors; (5) your right to audit and inspect systems; (6) data breach notification timelines; and (7) requirements for data deletion or return upon contract termination. This agreement documents that you've exercised your institutional responsibility to ensure appropriate safeguards.
Step 4: Maintain Internal Access Controls and Audit Trails
Your cloud vendor manages infrastructure, but you manage access policy. Document which institutional personnel can access student records in the cloud system and verify their access quarterly. Most cloud security failures in education result not from vendor negligence but from over-provisioned internal access—employees retaining system access after role changes, or having access to more data than their job requires. Your cloud vendor should provide audit logging; you must review it.
Step 5: Plan for Data Breach Response
FERPA doesn't require notification of breaches, but most states do, and the Department of Education's Office for Civil Rights increasingly expects it. Your vendor contract should require notification of any suspected breach within specified timeframes (typically 24-48 hours). Your institution should then investigate whether there was unauthorized access and follow your state notification laws.
Common Pitfalls to Avoid
Institutions frequently assume that using a major cloud provider (AWS, Azure, Google Cloud) automatically ensures FERPA compliance. It doesn't. These providers offer tools and infrastructure; compliance is your responsibility. Conversely, don't assume that your cloud vendor cannot be trusted. Instead, establish contractual relationships that align their incentives with your compliance obligations.
Finally, avoid treating FERPA as a checkbox exercise. The regulation's flexibility regarding technical standards is a feature, not a bug—it allows you to implement security appropriate to your context. Use that flexibility thoughtfully.