Data Retention Policy

Document ID: RU-DRP-2026-001 — Version: 0.1 — Date: 2026-05-17

This Written Data Retention and Disaster Recovery Program (“DRP” or “Program”) is established by Phareon LLC (“Company,” “we,” “us”) in satisfaction of the requirements under 16 CFR 312.10 (data retention) and 16 CFR 312.4(d) (public disclosure requirement) of the amended COPPA Rule.

1. Purpose, Scope, and Applicability

1.1 Data Retention. Documenting the lawful basis and calendar-day retention period for each category of personal information held by CollegeRoster, with particular focus on children's personal information under 16 CFR 312.2. Retention periods are set at the minimum necessary to fulfill the stated collection purpose, satisfy legal obligations, and support legitimate operational needs.

1.2 Disaster Recovery. Documenting the backup strategy, failover architecture, recovery procedures, and testing schedule that enable CollegeRoster to restore operations and protect data integrity following system failure.

2. Definitions

RTO (Recovery Time Objective): The maximum tolerable duration of downtime following a disaster. RPO (Recovery Point Objective): The maximum tolerable amount of data loss measured in time. Tier 1 systems (auth, user data, billing) have RTO: 4 hours, RPO: 1 hour.

3. Designated Program Owner

Program Owner: Jon Harris
Title: Founder / Operator, Phareon LLC
Contact: privacy@collegeroster.org
Reports to: Conductor (Jon Harris, Founder, Phareon LLC)

4. Data Retention Schedule (16 CFR 312.10)

4.1 Retention Principles

All retention periods comply with the COPPA “reasonably necessary” standard (16 CFR 312.10). Children's personal information is deleted rather than anonymized wherever possible. Each category with a fixed period has an automated deletion mechanism (pg_cron).

Category 1: User Account Data

FieldRetention PeriodLegal Basis
Active account dataDuration of active account relationshipContractual necessity
Soft-deleted user account30-day grace period, then hard deleteOperational (chargeback, account recovery window)
Hard-deleted user account (is_minor = true)0 days — immediate destructionCOPPA 312.10: no purpose remaining

Category 2: Athlete Profile Data

FieldRetention Period
All athlete profile fields (active account)Duration of active account
Athlete profile (post-account hard delete)0 days — deleted with account via foreign key cascade

Category 3: Parental Consent Records

FieldRetention PeriodLegal Basis
Active and revoked consent recordsDuration of consent relationship + 7 years16 CFR 312.5(e); GDPR Art. 17(3)(e)
VPC session records30 days from creationOperational (session management)
Consent invite tokens90 days or on consumption, whichever earlierOperational (token expiry)

Category 4: Media Files

FieldRetention Period
Active media filesDuration of active account
Soft-deleted media files24-hour grace period, then hard delete
Hard-deleted media files (R2 objects)0 days — deleted by cleanup worker
cleanup_audit_log records1 year from event date

Category 5: Authentication and Session Data

DataRetention Period
Active sessionsDuration of session (JWT expiry + refresh)
Auth data post-account deletion0 days — deleted with account

Category 6: Communications Data

DataRetention Period
Outreach messages (athlete-side)Deleted on athlete account deletion
Outreach messages (coach-side)2 years from creation, or until account deletion, whichever comes first
Notifications90 days from creation

Category 7: Audit and Forensic Log Data

DataRetention Period
audit_log (general security events)1 year. Audit log records are retained for 1 year from the date of the event, after which they are permanently deleted.
cleanup_audit_log (media hard-delete forensics)1 year
Moderation events (content_reports, moderation_queue)3 years

Category 8: Payment and Subscription Data

DataRetention Period
Subscription tier, billing recordsDuration of active subscription + 7 years (IRS 26 U.S.C. 6001)
Raw payment card dataNever collected — Stripe tokenized

5. Deletion Mechanisms (16 CFR 312.10)

CollegeRoster uses pg_cron (PostgreSQL scheduled jobs) as the primary automated deletion mechanism:

Job NameScheduleFunction
cleanup_expired_mediaDaily 02:00 UTCHard-delete media_files past grace period; delete R2 + Bunny videos
cleanup_expired_tokensDaily 01:00 UTCDelete expired consent_invite_tokens
cleanup_vpc_sessionsDaily 01:30 UTCDelete vpc_sessions older than 30 days
cleanup_audit_logDaily 03:00 UTCDelete audit_log rows older than retention period
cleanup_cleanup_audit_logDaily 03:30 UTCDelete cleanup_audit_log rows older than 1 year
process_hard_deletionsDaily 04:00 UTCHard-delete user accounts past 30-day grace period
cleanup_notificationsDaily 05:00 UTCDelete notifications older than 90 days
reconcile_bunny_orphansWeekly Sunday 06:00 UTCCross-check Bunny library against media_files; delete orphans

5.2 Developer Device Policy. Developer devices must not contain local copies of production personal information. Database dumps and backups containing personal data must not be downloaded to developer machines.

6. System Tier Classification and RTO/RPO Targets

Tier 1 — Critical (Supabase PostgreSQL, Supabase Auth, Vercel): RTO 4 hours, RPO 4 hours. 7-day daily backup retention via Supabase Pro tier.

Tier 2 — Important (Cloudflare R2, Bunny Stream): RTO 24 hours, RPO 24 hours. R2 versioning: enabled (default Cloudflare R2 bucket configuration).

Tier 3 — Supporting (derived data, notification queue, Tavily): RTO 72 hours, RPO 7 days.

7. Backup Strategy

7.1 Database Backups. Supabase performs daily automated snapshots. 7-day daily backup retention via Supabase Pro tier.

7.2 Object Storage. Cloudflare R2 provides automatic cross-region replication with 99.999999999% (11 nines) durability SLA.

7.3 Application Layer. Vercel retains deployment artifacts for 90 days. Recovery from source via GitHub is available in worst case.

8. Failover Architecture

Vercel deploys to a global edge network with automatic multi-region routing. DNS is managed via Vercel DNS for collegeroster.org.

Supabase manages database high availability with automated failover. In the event of a Supabase platform-wide outage, recovery requires restoring from the most recent PITR snapshot (within Tier 1 RTO of 4 hours).

9. Disaster Scenarios and Response Procedures

Response procedures are documented for: full region outage, individual service outage (Stripe, Resend, Bunny, Tavily), data corruption, ransomware, cryptographic key compromise, and insider threat. In all cases, the Conductor is notified within 1 hour of any disaster declaration.

Email retry mechanism: Transactional email delivery is handled via Resend with built-in retry queue. Email delivery failures are logged and retried automatically.

Status page: A public status page is planned (BetterUptime or equivalent) before public launch.

10. Recovery Procedures

The Supabase PITR restore playbook targets 2–4 hours to operational state. Application layer recovery via Vercel deployment rollback takes 5–15 minutes. R2 object recovery requires versioning to be enabled (see Section 6).

11. Testing Schedule

Annual full DR exercise (PITR restore in test environment), quarterly partial restore test, annual Bunny orphan audit, and post-incident retrospective within 5 business days of any declared event.

13. Privacy Notice Disclosure Requirement (16 CFR 312.4(d))

The retention schedule in Section 4 must be reflected in CollegeRoster's Privacy Notice with specific retention periods (in calendar days or years), deletion mechanisms, and parental deletion rights. Privacy Notice update is a blocking pre-launch requirement under 16 CFR 312.4(d) and 312.10.

15. Version History

VersionDateSummary
0.1 DRAFT2026-05-17Initial draft — Conductor + outside counsel review required before legal effectiveness

This Program is not legally effective until approved and signed by the Conductor and outside counsel. Phareon LLC is a Tennessee limited liability company.