FERPA Compliance
Last updated: April 15, 2026
Protecting student education records is at the core of everything we build. This page details how I Love My Class safeguards data in compliance with the Family Educational Rights and Privacy Act (FERPA), from database-level security policies to institutional controls and contractual agreements.
1.What is FERPA?
The Family Educational Rights and Privacy Act (FERPA), 20 U.S.C. § 1232g, is a federal law that protects the privacy of student education records. It applies to all educational institutions that receive funding from the U.S. Department of Education, including K-12 schools and postsecondary institutions.
FERPA gives parents and eligible students (those over 18 or attending postsecondary institutions) the right to:
- Inspect and review education records maintained by the school
- Request amendments to records they believe are inaccurate or misleading
- Consent to disclosures of personally identifiable information (PII) from education records
For EdTech platforms like I Love My Class, FERPA compliance means implementing rigorous technical and organizational safeguards to protect any student education records that flow through the platform, and ensuring institutions retain full control over their data.
2.Our Role Under FERPA
Designation: School Official with Legitimate Educational Interest
Under 34 CFR § 99.31(a)(1)(i)(B), I Love My Class operates as a “school official” with a legitimate educational interest when providing institutional services. This means:
- The institution remains the data controller. We are a service provider processing data under the institution's direction and within the scope they define.
- We operate under direct control of the institution with respect to the use and maintenance of education records.
- We use education records only for the purposes for which the disclosure was made — delivering the LMS and attendance services requested by the institution — and do not re-disclose PII without authorization.
- We do not use student data for any commercial purpose beyond providing the contracted educational services. No advertising, no profiling, no data mining.
3.Complete Data Inventory
The following table lists every category of data collected by the platform, the purpose for collection, retention period, and who can access it.
| Category | Data Collected | Purpose | Retention | Access |
|---|---|---|---|---|
| Account Data | Full name, email address, role (teacher/professor/admin), institution affiliation, profile bio, department, title | User identification, authentication, role-based access control | Active account lifetime; anonymized upon deletion request | Account owner; platform admins (for support only) |
| Course Data | Course content, modules, blocks (text, quiz, assignment, resource), learning outcomes, grading schemes, diary entries | Core LMS functionality: course creation, delivery, and assessment | Retained until teacher deletes; soft delete with 30-day recovery window | Course author and invited collaborators only (enforced by RLS) |
| Attendance Records | Student identifier (name, nickname, student ID, or roster entry), check-in timestamp, session code used | Classroom attendance tracking for the instructor | Retained for the academic period; deletable by the creating teacher | Creating teacher only (RLS-enforced); students cannot view others' records |
| Collaboration Data | Course collaboration invitations, shared course access, collaborator roles | Enabling co-teaching and course sharing between instructors | Active until collaboration is removed by the course author | Course author and invited collaborators only (enforced by RLS) |
| Usage Data | Page visits, feature usage patterns (aggregated) | Platform functionality and performance optimization only | Aggregated; no individual behavioral profiles | Platform operations team (aggregated only; no individual tracking) |
| Device / Network Data | IP addresses | Rate limiting and abuse prevention only; NOT used for tracking or profiling | Rate limit log entries auto-purged on a sliding window (minutes); IP in attendance records stored for abuse prevention | Service role only (server-side rate limiting); never exposed to client |
4.Institutional Control
Institutions retain full ownership and control of all education records processed through the platform. Here is how this is enforced:
Teacher Data Ownership
Teachers own their course data and student records. No other teacher, admin, or platform employee can access a teacher's courses unless explicitly invited as a collaborator.
RLS Data Isolation
Row Level Security policies enforce data isolation at the PostgreSQL level. Every query is filtered through the requesting user's identity. There is no global 'view all' capability.
No Platform-Wide Access
There is no administrative backdoor to view individual student records. Audit logs track every sensitive operation (data exports, admin actions).
Data Export & Deletion
Institutions can request a full JSON export of their data (GDPR Right to Access) or complete deletion. Deletion cascades through all user-generated content with audit trail preservation.
5.Technical Safeguards
Security is implemented at every layer of the stack, from the database to the edge network. Each safeguard is designed to prevent unauthorized access to student education records.
Encryption in Transit
TLS 1.3 on all connections. Vercel edge network enforces HTTPS; Supabase endpoints are TLS-only. No unencrypted data ever leaves a browser.
Encryption at Rest
AES-256 encryption on all PostgreSQL storage managed by Supabase. Database backups are encrypted.
Row Level Security
Every table has RLS enabled with FORCE ROW LEVEL SECURITY. Default-deny policies ensure no data is accessible without an explicit policy grant. Even database owners cannot bypass RLS.
Authentication
Supabase Auth with stateless JWT. Short-lived access tokens (1 hour) with automatic refresh rotation. Email verification required before account activation.
Rate Limiting
Persistent IP-based rate limiting backed by a database table. Survives serverless cold starts and scales across instances. Fail-closed design: if rate limiting itself errors, requests are denied.
Edge Middleware Protection
All authenticated routes are protected at the Vercel edge before reaching the application. Unauthenticated requests are redirected to login with full path preservation.
Input Validation
Zod schema validation on every API endpoint. All user input is validated and sanitized before processing. Structured error responses with consistent codes.
SQL Injection Prevention
All database queries use parameterized queries via the Supabase client. No raw SQL is ever constructed from user input. SECURITY DEFINER functions use SET search_path to prevent injection.
6.Attendance Data Protection
The attendance system is designed with privacy-first principles and allows anonymous student participation (no student account required):
Flexible Student Identification
Teachers choose how students identify themselves: full name, nickname, student ID number, or from an uploaded class roster. The platform does not require student accounts.
IP Addresses: Rate Limiting Only
IP addresses are stored in attendance records solely for abuse prevention. They are never used for location tracking, behavioral profiling, or any purpose beyond security.
Device Cooldown
A 3-minute per-device cooldown prevents students from sharing check-in links. This is enforced via an HTTP-only cookie and IP-based rate limiting (10 check-ins per 60 seconds per IP).
Immutable Records
Attendance records are immutable: there are no UPDATE or DELETE RLS policies for students. Once checked in, the record is the authoritative audit trail.
Teacher-Only Visibility
Only the creating teacher can view attendance records for their classes. No other teacher, student, or platform administrator can access these records.
7.Zero Commercial Use of Student Data
Our revenue model is simple and transparent: Platform revenue comes solely from teacher subscription fee. Students never pay, and student data is never the product. This alignment ensures our business incentives are fully compatible with FERPA requirements.
8.Data Retention & Deletion
Active Accounts
Data retained while account is active. Users can update or remove personal information at any time through their profile settings.
Course Data
Retained until the teacher deletes it. Deletion is a soft delete with a 30-day recovery window, after which data is permanently purged by an automated scheduled function (purge_expired_soft_deletes) that runs daily across all 18 tables with soft-delete support.
Attendance Records
Retained for the academic period. Teachers can delete attendance classes, which cascades to all sessions and records for that class.
Account Deletion
Complete cascade deletion processed within 30 days of request. The execute_data_deletion() database function removes all user-generated content across every table, anonymizes the profile (preserving referential integrity for audit logs), revokes all active authentication sessions and refresh tokens to prevent continued access, and records the deletion in the immutable audit log.
9.Breach Notification
In the event of a security breach affecting education records, we commit to:
72-Hour Notification
All affected institutions notified within 72 hours of breach confirmation.
Detailed Incident Report
Nature of the breach, specific data affected, timeline of events, immediate containment actions taken, and long-term remediation plan.
Ongoing Communication
Regular updates to affected institutions until full resolution, including a final post-incident report with preventive measures implemented.
10.Subprocessors
The following third-party services process data on our behalf. All subprocessors are US-based and maintain their own security certifications.
| Provider | Location | Purpose | Data Processed |
|---|---|---|---|
| Supabase Inc. | United States | Database hosting, authentication, storage, real-time subscriptions | All application data (encrypted at rest and in transit) |
| Vercel Inc. | United States | Application hosting, edge network, serverless compute | HTTP requests and responses; no persistent student data storage |
| Sentry | United States | Error monitoring and performance tracking | Error stack traces and performance metrics only; no student education records |
11.Contact
Questions about FERPA compliance?
Our compliance team is here to help with any questions about data privacy, student records, institutional agreements, or security practices.
contact@ilovemyclass.comWe respond to institutional inquiries within 2 business days.