Security & architecture

This page is written for the person who has to approve us. It describes how the system is actually built, what we hold, who else touches it, and what we have not done yet. Where we are missing something a district might expect, it says so rather than leaving you to find out in a questionnaire.

Where data lives

The application runs on Vercel; the database, authentication and file storage are Supabase (managed PostgreSQL) in a United States region. Data is encrypted in transit with TLS 1.2 or better, and at rest with AES-256 by the underlying provider. We do not operate our own servers and we do not replicate student data outside the US.

How records are isolated

Every table that holds student data has PostgreSQL row-level security enabled, and access is expressed as policies on the database rather than checks in application code. This matters because it means a bug in a page or an API route cannot return another school's athletes: the query itself comes back empty. Access is derived from three relationships — an athlete to their own record, a parent or guardian to a linked athlete, and staff to athletes in an organization they belong to.

Staff access is scoped further. A coach assigned to specific sports sees only those sports, on the roster and in every export. Athletic directors and delegated admins see the whole department. Read-only access exists for counselors who need visibility without the ability to change a record.

Authentication

• Email and password, or Google, through Supabase Auth. Passwords are never stored by us in any form.
• Optional time-based one-time-password (TOTP) two-factor authentication, available to every account.
• Sessions are listed in-account and can be revoked globally.
• Sign-ins are recorded with timestamp and IP so an account holder can see activity they don't recognize.
• Schools may verify an email domain so staff join the right department on sign-in. Verification requires a DNS TXT record on the school's own domain — a claim alone grants nothing, and public mailbox providers cannot be claimed at all.

What we collect, and what we don't

We collect what the product needs: name, email, date of birth, graduation year, sport, school, courses and grades entered by the athlete or their school, test results taken in the product, and the content of tools the athlete uses. We do not collect Social Security numbers, we do not buy or enrich student data from third-party brokers, and we do not sell data or share it for advertising. There is no advertising on PlayEligible.

Students under 13 are handled under our Parents' Bill of Rights, which includes verifiable parental consent and a narrower default set of tools.

Who else touches the data

Every third party that processes data on our behalf is listed, with its purpose and location, on the subprocessors page. We update that list before adding a new one, so a district can subscribe to it as a change notice.

Retention and deletion

Retention periods by record type are published on the data retention page. Any account holder can export everything we hold about them as a file, and can request deletion, which runs after a 30-day grace window so an accidental request can be reversed. Billing facts we are legally required to keep are separated from the identity they belonged to before the account is destroyed.

When a school removes a staff member, that person loses access immediately. Records they created — grades they entered, notes they recorded — remain with the school, because those are the school's records and not the departing employee's.

Availability and incidents

The application is served from a global edge network with automatic failover; the database is managed, with automated daily backups and point-in-time recovery retained by our provider. We do not publish an uptime SLA at our current stage, and we would rather say that than print a number we have no contractual ability to honor.

If we become aware of a breach involving student data, we will notify affected account holders and the contracting school or district without undue delay and in any case within 72 hours of confirming it, with what we know, what we do not yet know, and what we are doing. Report a suspected vulnerability to security@playeligible.com; we will not pursue legal action against good-faith research that avoids privacy violations and service degradation.

Compliance posture — stated plainly

We build to the substance of the regulations that govern student data, and we say precisely where we stand on each:

• FERPA. Where a school contracts with us, we act as a school official with a legitimate educational interest, under the school's direct control, and we use education records only for the purposes the school directs.
• COPPA. Verifiable parental consent for under-13 accounts, with a reduced default tool set and parent-visible controls.
• SOPIPA and state student-privacy laws, including New York Education Law §2-d. No targeted advertising, no sale of student data, no profiling for non-educational purposes.
• CCPA / CPRA. Access, deletion, correction and portability are self-serve in-account rather than a support request.
• SOC 2. We are not SOC 2 certified. The controls this page describes are the groundwork for it, and we will publish the report when we have one. If your procurement process requires a current SOC 2 Type II today, we do not meet that bar today.

Data processing agreement

We sign a DPA. Districts commonly require their own paper, a state alliance addendum, or the SDPC National Data Privacy Agreement, and we will work from yours rather than insisting on ours. Email security@playeligible.com with the agreement your district uses.

Accessibility

Our conformance status, known gaps and remediation plan are on the accessibility statement.

Questions this page didn't answer

Security questionnaires are welcome and we would rather answer one properly than have you guess from a marketing page. security@playeligible.com.