FERPA Compliance for Ed-Tech: What Engineers Actually Need to Know

FERPA (the Family Educational Rights and Privacy Act) is the law that governs how student education records are handled. If you’re building software that touches student data, you need to understand it. Not as a legal abstraction, but as a set of constraints that affect how you design and build your system.

Most FERPA guidance is written by lawyers for lawyers. This post is written by engineers for engineers. We’ll skip the legislative history and focus on what actually matters for your architecture, your data handling, and your vendor review process.

What FERPA Actually Requires

FERPA applies to educational institutions that receive federal funding, which is essentially all public schools and most colleges. The law itself doesn’t directly regulate ed-tech vendors. It regulates the schools, and the schools pass those obligations to you through contracts.

Here’s what that means in practice:

Schools must control their student data. When a school shares student records with your platform, they’re doing so under the “school official” exception. You’re acting as an agent of the school. You don’t own that data. You can only use it for the purposes the school authorized.

You cannot use student data for non-educational purposes. No advertising. No profiling for marketing. No selling data. No building user profiles that persist after the school relationship ends. This is where a lot of ed-tech companies get into trouble, sometimes intentionally, sometimes through sloppy data architecture.

Parents (and eligible students over 18) have the right to inspect and amend records. Your system needs to support data access requests. If a parent asks the school to see what data your platform holds about their child, the school will ask you, and you need to be able to produce it.

You must protect the data with reasonable security measures. FERPA doesn’t prescribe specific technical controls the way HIPAA does. It requires “appropriate” safeguards. This is both a blessing (flexibility) and a curse (ambiguity). In practice, districts are increasingly defining what “appropriate” means through their vendor review processes.

Directory information has different rules. Student name, grade level, enrollment status. This can be shared more broadly unless parents opt out. But be careful. Many platforms treat directory information as freely usable, which creates problems when parents have opted out and your system doesn’t track that.

Common Engineering Mistakes

We work with ed-tech companies regularly, and these are the patterns that cause the most problems.

Commingling data across tenants. Multi-tenant architecture is fine. Shared databases with soft tenant isolation are common. But your data architecture needs clean separation of student data by school or district. When a district asks you to delete their data, can you actually do it without affecting other tenants? If your analytics pipeline merges data across districts before storing it, you have a problem.

Retaining data after the relationship ends. When a school stops using your platform, their student data needs to go. Not archived. Not anonymized and kept for analytics. Deleted or returned. Your data lifecycle needs to account for this. Build the deletion capability before you need it, not when a district sends you a 30-day notice.

Using student data for product development without authorization. Training ML models on student work, analyzing usage patterns to improve recommendations, A/B testing features using student interactions. All of these can be legitimate if they serve the educational purpose the school authorized. They become FERPA problems when they exceed that scope. The line is blurry, so get it in writing with the school.

Logging and monitoring that captures PII unnecessarily. Your application logs probably contain student names, email addresses, and other identifiers. Are those logs secured the same way your primary data stores are? Do they respect the same retention and deletion policies? We’ve seen companies with locked-down databases and wide-open Elasticsearch clusters full of student PII in log messages.

Third-party sub-processors with access to student data. Your analytics provider, your error tracking tool, your customer support platform. If student data flows through them, they’re sub-processors, and the school needs to know about them. Map every service that touches student data. You’ll probably be surprised by the list.

Data Flow Mapping: The Exercise You Can’t Skip

If you take one thing from this post, let it be this: draw your data flow diagram.

Start at the point where student data enters your system. Follow it everywhere it goes. Every database, every cache, every queue, every analytics pipeline, every third-party service, every log file, every backup.

Here’s a template for the exercise:

1. Data ingestion. How does student data get into your system? CSV upload, API integration, SSO/roster sync (Clever, ClassLink), manual entry? Document each path.

2. Data storage. Primary database, read replicas, caches (Redis, Memcached), search indexes (Elasticsearch), data warehouses, file storage (S3).

3. Data processing. Background jobs, analytics pipelines, ML training, reporting.

4. Data transmission. API responses, webhooks, email notifications, PDF generation, exports.

5. Data sharing. Third-party services that receive student data, even transiently.

6. Data deletion. What happens when a record needs to be deleted? Can you trace it through every location and confirm removal?

We usually do this exercise on a whiteboard with the engineering team. It takes 2-3 hours. Every time, we find data flowing somewhere nobody expected. A reporting dashboard that pulls directly from production. An error tracking service that captures request bodies. A developer’s local database backup from six months ago.

The diagram becomes your source of truth for FERPA compliance. It tells you what to encrypt, what to monitor, what to include in deletion workflows, and what to disclose to districts.

What Districts Look For in Vendor Reviews

District technology directors have gotten significantly more sophisticated about vendor security reviews in the past five years. Here’s what they’re actually evaluating.

Data governance agreements. Most districts require a signed agreement (often a DPA, or Data Privacy Agreement, sometimes following the Student Data Privacy Consortium template) before they’ll let you touch student data. These agreements specify what data you’ll collect, how you’ll use it, how long you’ll keep it, and what happens when the contract ends. Read these carefully. They’re binding.

Your privacy policy. Districts will read it. If your privacy policy says you “may share data with third parties for business purposes,” that’s a red flag. Be specific about what you share, with whom, and why.

Technical security controls. Encryption at rest and in transit (TLS 1.2+, AES-256). Access controls and authentication (do your employees use MFA?). Vulnerability management. Incident response procedures. Increasingly, districts want evidence, not just assertions. A SOC 2 report goes a long way here.

Sub-processor transparency. Which third-party services process student data? Districts want a list, and they want to know what controls you have over those sub-processors.

Data deletion capability. Can you delete a specific student’s data on request? Can you delete an entire district’s data? How long does it take? Is it permanent?

Breach notification. If you have a data incident, how quickly will you notify the district? FERPA requires “reasonable” notification. Most DPAs specify a concrete timeline, often 24-72 hours.

State-specific requirements. FERPA is federal, but many states have additional student privacy laws. California (SOPIPA), New York (Education Law 2-d), Colorado, Connecticut. Know which states your customers are in and what those laws add to your obligations.

Practical Implementation Guidance

Here are specific technical recommendations that address the requirements above.

Tenant isolation. Use schema-per-tenant or database-per-tenant for districts above a certain size. For smaller tenants, row-level security with tenant ID enforcement at the ORM or query layer. Test your isolation by attempting cross-tenant data access.

Encryption. TLS 1.2+ for everything in transit. AES-256 for data at rest. Use AWS KMS or similar managed key services. Consider per-tenant encryption keys if your architecture supports it. It makes data deletion much cleaner: destroy the key, and the encrypted data becomes unrecoverable.

Access controls. Role-based access with least privilege. No employee should have standing access to production student data. Use just-in-time access with audit logging for when engineers need to troubleshoot production issues. We usually implement this with AWS SSM Session Manager or a bastion host with session recording.

Audit logging. Log every access to student data. Who accessed what, when, and why. This log is your evidence trail for compliance and your investigation tool for incidents. Store it separately from your application logs, with longer retention and stricter access controls.

Data minimization. Only collect what you need. If your application doesn’t require a student’s date of birth, don’t collect it. Every field you store is a field you have to protect, include in access requests, and delete on termination.

Deletion workflows. Build automated, auditable deletion workflows. When a district offboards, a process should identify all data associated with that district across every store (databases, caches, search indexes, backups, logs) and remove it. Generate a deletion certificate that confirms what was removed and when.

Incident response. Have a plan specific to student data incidents. Know your notification obligations under FERPA and any applicable state laws. Have draft notification templates ready. When an incident happens at 2 AM, you don’t want to be writing notification letters from scratch.

A Note on Emerging Requirements

The student privacy landscape is tightening. States are passing new laws. Districts are joining purchasing cooperatives that enforce standardized security requirements. The 1EdTech (formerly IMS Global) Trusted Apps program is gaining adoption.

If you’re building an ed-tech product, treat FERPA as the floor, not the ceiling. Build your data architecture with privacy as a design constraint from the beginning. It’s dramatically cheaper than retrofitting it later.

We’ve helped ed-tech companies at every stage, from seed-stage startups trying to close their first district deal to growth-stage companies preparing for state-wide deployments. The technical work is similar. The cost of doing it late is always higher.

Build the data flow diagram. Get your DPA template right. Implement real deletion. The districts that will become your best customers are the ones asking the hardest questions, and they’ll remember which vendors had good answers.