FERPA — the Family Educational Rights and Privacy Act — is one of the most commonly cited and least precisely understood pieces of legislation in higher-education software procurement. When it comes to housing platforms specifically, the question "are we FERPA compliant?" gets answered with marketing copy more often than with a clear-eyed reading of the law.

This guide is a practical breakdown: what FERPA actually requires of housing software, where typical deployments fall short, and a checklist your IT and legal teams can take into a vendor review.

Disclaimer: this article is for educational reference, not legal advice. Talk to your institution's general counsel before relying on any of this for procurement or compliance decisions.

What FERPA actually covers

FERPA protects "education records" — broadly, information directly related to a student that's maintained by an educational institution. In a housing context, that includes:

  • Housing applications and supporting documents
  • Room assignments and roommate pairings
  • Accommodation requests (which often include medical info)
  • Conduct records related to housing
  • Maintenance requests when they reveal student-specific info
  • Communications between students and residence life staff

FERPA does not cover "directory information" (name, address, dates of attendance) unless a student has requested non-disclosure. But housing software typically touches both categories, which is why default access controls matter.

What FERPA requires of housing software

1. Access controls aligned to legitimate educational interest

Staff can access student records, but only those with a legitimate educational interest in the specific student. Your software should enforce this through role-based access controls: an RA shouldn't see records from a different building, a maintenance worker shouldn't see roommate match data, and a housing director should see everything for their domain but not necessarily for the whole institution.

2. Audit logging

When a student requests access to their own records — or when an institution responds to a subpoena — you need to be able to show who accessed what, when. Logs should cover record views, edits, exports, and deletions, and they should be tamper-evident.

3. Consent for non-directory disclosures

If your housing platform shares information with a third party that isn't covered by the "school official" exception — say, an external roommate-matching service — that disclosure typically requires written consent. Your software should make consent tracking auditable, not just operational.

4. Data minimization

FERPA doesn't explicitly mandate data minimization, but the broader principle — collect only what you need, retain only as long as you need it — reduces breach exposure and simplifies compliance. Software that lets you set retention policies per record type, and that purges expired data automatically, makes this easier to maintain than software that stores everything forever by default.

5. Vendor data handling

If your platform is SaaS, the vendor is a "school official" under FERPA only if they meet specific criteria: they perform a service the institution would otherwise perform itself, the institution maintains direct control over their use of the data, and the vendor is subject to FERPA-compliant data use restrictions. Your contract should explicitly cover this.

Where typical deployments fall short

Shared logins

The single most common compliance gap: residence life teams that share a single account because individual seat licenses are expensive. This makes audit logging meaningless. If your vendor charges so much per seat that staff share accounts, the vendor is the compliance problem.

Over-broad default access

"Read all records" as a default role for new staff hires is a FERPA red flag. New staff should default to the narrowest access that lets them do their job, with broader access granted explicitly.

Exports without logging

Many platforms log views but not exports. The biggest data exposure risk is bulk export — a CSV download with thousands of students' info — and that's exactly the action most likely to go unlogged in legacy systems.

Backups that outlive retention policies

If your policy says student data is purged after seven years but your backups go back ten, your real retention is ten. Backup retention has to align with policy retention.

A FERPA-readiness checklist for vendor review

  • Does the platform enforce role-based access controls?
  • Are individual user accounts required (no shared logins)?
  • Are record views, edits, and exports all audit-logged?
  • Are audit logs tamper-evident and retained for at least 7 years?
  • Can you configure retention policies per record type?
  • Is automated data purging available?
  • Does the vendor agreement explicitly meet the "school official" criteria?
  • Is the vendor's data center in a jurisdiction your institution accepts?
  • Does the platform support SSO through your campus identity provider?
  • Are backups retention-aligned with policy retention?

Any "no" on that list isn't necessarily a deal-breaker, but it is a conversation you should have with the vendor and with your counsel before signing.