The Compliance Gap Nobody Talks About
RFC 5545 non-compliance isn't just a technical issue for universities. It's a FERPA violation waiting to happen.
When a student subscribes to a course schedule feed from Banner, PeopleSoft, or Canvas, that ICS file contains directory information: student name in organizer fields, course enrollment data, and sometimes student ID references. Under FERPA §99.3, this is an education record. When the feed URL is bookmarked in Apple Calendar or Google Calendar, those third-party services cache that data. Your registrar just granted unauthorized access.
Universities using legacy SIS platforms face this exact issue: there is no native way to sanitize calendar metadata before it reaches student devices. Direct export means direct exposure.
---
What is FERPA?
FERPA (Family Educational Rights and Privacy Act) requires universities to protect student education records from unauthorized disclosure. Calendar feeds exported from SIS and LMS platforms contain directory information, which qualifies as a student record under 34 CFR §99.3. Universities must ensure third-party calendar services do not receive persistent access to this data without explicit consent.
LMS platforms contain directory information, which qualifies as a student record under 34 CFR §99.3. Universities must ensure third-party calendar services do not receive persistent access to this data without explicit consent.**
FERPA defines two categories of student data:
1. Directory Information (Name, enrollment status, dates of attendance). Requires opt-out notices.
2. Non-Directory Records (Grades, SSN, discipline records). Requires explicit consent.
Calendar feeds typically contain directory information: course names, instructor names, student names in ORGANIZER fields. The issue isn't the content. The issue is persistent third-party access to that content.
---
The Technical Problem: Calendar Feeds Are Education Records
What's Actually in an ICS File?
Here's a typical Banner export:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Ellucian//Banner Student v9//EN
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:BANNER-12345-STUDENT-001@university.edu
SUMMARY:CHEM 101 - General Chemistry
DTSTART:20260115T090000
DTEND:20260115T100000
LOCATION:Science Hall 204
ORGANIZER;CN="Dr. Sarah Johnson":mailto:s.johnson@university.edu
ATTENDEE;CN="Jane Smith":mailto:jane.smith@university.edu
DESCRIPTION:Enrolled students: 24. Section A.
END:VEVENT
END:VCALENDAR
The Violations:
- ORGANIZER field: Contains instructor name (directory information)
- ATTENDEE field: Contains student name and email (education record)
- UID field: May contain student ID references
- DESCRIPTION field: Enrollment count (potentially identifying)
When a student subscribes to this feed in Apple Calendar, Apple's servers fetch and cache this data every 15 to 60 minutes. You just gave Apple persistent access to a student record without a FERPA-compliant agreement.
---
The Regulatory Gap: FERPA §99.31 Exception Analysis
Common Misconception: "It's Just a Calendar"
Registrars often assume calendar subscriptions are exempt under FERPA §99.31(a)(1) as school officials with legitimate educational interest. This fails on two counts:
1. Apple and Google are not school officials. They're third-party contractors.
2. Persistent server access is not temporary viewing. FERPA requires that contractors only access records "to the extent necessary."
The Compliance Test
Ask your IT team:
- Where are calendar subscription requests served from? (Banner server? Calendar proxy?)
- Who has access to those server logs? (Your team? Apple? Both?)
- How long is the data cached on third-party servers? (15 minutes? Forever?)
If the answer to question 3 is "We don't control that," you have a FERPA exposure.
---
The Solution: Zero-Persistence Proxy Architecture
How a Compliance Proxy Works
Instead of publishing ICS feeds directly from Banner or Canvas, universities route calendar URLs through a zero-persistence proxy. The proxy:
1. Fetches the source feed on-demand (when a student device requests it)
2. Normalizes the RFC 5545 structure (fixes VTIMEZONE, RRULE, line-folding)
3. Sanitizes directory information per university policy (strips ATTENDEE fields, anonymizes UIDs)
4. Delivers the compliant feed to the student device
5. Discards all data (no storage, no logs of student identifiers)
Technical Implementation
The proxy rewrites sensitive fields:
Before (Direct Export):
ATTENDEE;CN="Jane Smith":mailto:jane.smith@university.edu
UID:BANNER-12345-STUDENT-001@university.edu
After (Proxy Normalization):
# ATTENDEE field removed (not required for subscription calendars)
UID:LOKR-EVENT-a3f8d9e2@university.edu.lokr.co
The event content (course name, time, location) remains intact. The identifying metadata is stripped.
---
Compliance Verification: The 4-Point Audit
Run This Test on Your Current Feeds
1. Export Test: Pull an ICS file from Banner or Canvas. Search for student names, emails, or IDs.
2. Subscription Test: Subscribe to the feed in Apple Calendar. Check Activity Monitor for third-party server requests.
3. Persistence Test: Disconnect from Wi-Fi. Do events still appear? (If yes, data is cached externally.)
4. Log Audit: Ask your SIS vendor: "Do you store calendar subscription request logs? For how long?"
If any test reveals persistent third-party access to student identifiers, your calendar system is FERPA non-compliant.
---
The Results: Real Compliance at 50+ Universities
Case Study: Large Public University System
Before:
- 12,000 students subscribed to Banner feeds directly
- Apple and Google servers cached student directory information
- No contractual FERPA agreement with Apple or Google
- Annual compliance audit flagged calendar exports as non-compliant
After:
- All calendar URLs routed through zero-persistence proxy
- Student identifiers stripped at proxy layer
- Third-party services receive only normalized event data (no student records)
- Compliance audit: ✅ Pass
Impact:
The registrar eliminated a 6-year FERPA exposure without changing the student experience. Calendars still sync. Events still update. The difference is invisible to students but critical to auditors.
Broader Applications
This same proxy architecture applies to corporate training programs managing employee development records where GDPR or SOC 2 compliance requires controlling third-party access to calendar metadata. The principle is identical: normalize the data pipeline between your system of record and end-user devices.
---
Compliance Without Compromise
FERPA compliance for calendar feeds doesn't require shutting down calendar subscriptions. It requires controlling the data pipeline between your SIS and student devices.
Universities using Ellucian Banner, Canvas LMS, or PeopleSoft Campus Solutions can implement proxy normalization in under 10 minutes. No code changes to your SIS. No disruption to students.
Want to verify your current feeds? Validate your ICS structure for FERPA exposure now.
Ready to eliminate FERPA calendar risk?
50+ universities use Lokr to maintain compliance while delivering reliable calendars.