SchoolAthleticsHQSchoolAthleticsHQ Privacy Policy (school edition)
Effective: [date]. Version: [draft 0.1].
SchoolAthleticsHQ is the high-school edition of a software platform that schools use to run athletic programs: rosters, schedules, attendance, messaging, registration and fees, forms and e-signatures, tournaments, stats and related tools.
1. Who is responsible for what
- The school is the customer and controls its students' information. The school decides who gets accounts, which features are turned on, and what is entered. We process that information on the school's behalf to run the service.
- SchoolAthleticsHQ provides the software, keeps it secure, and handles support. We use school data only to run, support and secure the service for that school.
- This policy covers the SchoolAthleticsHQ web and mobile apps. It does not cover the school's own policies on student records; ask the school for those.
2. What we collect, and about whom
Students (the demo school covers grades 6-12; real schools set their own levels)
- Name, date of birth, graduation year, grade/level, positions, height, jersey preferences, photo (optional), notes entered by the school.
- Team membership, schedules, attendance and absence notices, stats and awards, tournament results.
- Coach notes and evaluations (staff-only; see section 4).
- Forms and e-signature records the school sends (for example waivers). There is no student eligibility or physicals feature. Background-check status applies to staff (coach/director), not students.
- Messages the student sends or receives through the platform, where the school permits student messaging.
- Optional recruiting profile (stats, measurables, highlight video; with the Recruiting Hub module also GPA/test scores and college-interest data). It becomes public only when a guardian's signed consent is on file and the player is 13 or older with a date of birth recorded. The Recruiting Hub module itself is off by default. The consent text is still a placeholder that says it must be replaced with attorney-reviewed copy before real families use it.
Parents/guardians
- Name, email, phone, relationship to the student, login credentials (password stored hashed), messages, signed forms, payment records (see Payments below), notification settings and device tokens for push notifications.
School staff (athletic director, coaches, administrators)
- Name, email, phone, role, login credentials, optional two-factor authentication settings, and background-check status and dates where the school tracks it (status, dates and an uploaded proof document, not the underlying screening report).
Everyone
- Technical data: IP address, device/browser type, and log data used for security and reliability. An audit log records who did what to which record (actor, action, record, timestamp, IP and user agent).
Payments. Card and bank details are collected by Stripe and are not stored on our servers. We keep payment status, amounts, dates and Stripe reference IDs, and for saved cards only the brand, last four digits and Stripe identifiers.
3. Students under 13 and ages 13-17
What the product does today:
- A student under 13 cannot have a login when a date of birth is on file. Account creation is refused and an existing player login is refused at sign-in. Both checks run only if the date of birth is known, so a student with no date of birth is not blocked from having a login. The intended access for an under-13 student is a guardian's account.
- The platform does not send club email to the address on a known under-13 student's record: the shared helper returns no address for them and the send paths we checked use it. An unknown date of birth is not treated as under 13 for email, so a student with no date of birth can still be emailed at their own address. We did not audit every email send path.
- Under-13 students (and students with no date of birth) are never shown publicly through the recruiting features. Students 13+ are shown publicly only if a recruiting profile exists, is enabled, and a signed, non-revoked guardian consent is on file. The same age rule keeps them out of the monthly recognition and signage birthday displays.
- Any non-team message thread that includes school staff and a student under 18 automatically includes every guardian on file, re-checked before each message. "Under 18" uses the date of birth when we have one and falls back to the team's age bracket when not.
- Student profiles are not public or searchable by default.
- No advertising cookies, no selling, and no use of student data for advertising or marketing.
Not covered: a student with no date of birth can still have their own email and phone stored, and rows that held such details before the rule existed are not cleaned until a one-time script is run, which has not happened in production and which currently targets club-type organizations, not schools. The school is responsible for any consent it needs before entering a child's data (Terms section 4). The deletion route a parent has is the Data Erasure tool in section 7, run by the school.
4. Who can see what
| Role | Sees |
|---|---|
| Athletic director / school administrator | Their school's data only, per the permissions they configure. |
| Coaches and staff | Their teams' rosters, schedules, attendance, stats, and coach notes. Coach notes and evaluations are never shown to players or families and are excluded from the family data export. Directors, administrators and platform super-admins can read every player's coach notes in the school; coaches and communications directors see notes only for players on their own teams or assigned clinics. |
| Parents/guardians | Their own linked students, family payments and signed forms, and messages they are part of. |
| Students 13+ with a login | Their own profile and information the school makes available to them. |
| Public | Only what the school publishes on its public site, and recruiting profiles that meet the rules in section 3. |
| SchoolAthleticsHQ staff | Limited, for support and security. Platform administrators can "view as" or impersonate a user for support (token-based). The start of an impersonation or view-as is written to the audit log with the real actor's id and email, later actions in that session carry the real actor id, and the exit is logged. While impersonating, money and consent routes answer 403. |
Schools are separated from each other by school ID, and API access is scoped to the caller's school.
5. How we use information
To run the features a school has turned on; to send notifications and emails on the school's behalf; to secure accounts and detect misuse; to provide support; and to keep backups. We do not sell personal information and do not use it for advertising; no advertising SDK appears in the backend, web app or mobile app.
AI features. The platform has the features below, all calling Anthropic's API.
| Feature | What is sent to Anthropic |
|---|---|
| Stats question-and-answer assistant | The question and the team/club stat results needed to answer it, which include player names (a parent or player sees other families' children trimmed to "First L."). The question and answer are stored and deleted after 90 days. |
| Season narrative | Team stats via the same tools. The generated text is stored in the database until deleted. |
| Director scheduling assistant and coach schedule-change assistant | The request text and schedule data (events, teams, courts, coaches). Proposals only; nothing is applied without a click. |
| Writing-polish tool | The draft message text the staff member typed, which may contain names. |
| FAQ auto-answer bot | A family member's question, plus the school's FAQ entries and public About text. |
| Help assistant | The user's how-do-I question after personal-data redaction and help-article text; no club or student data. Stored question/answer rows are deleted after 30 days. |
| Season Planner assistant |
Self-harm phrases are intercepted before any AI call and answered with a fixed crisis-resource message; a crisis turn is not stored in the stats-chat log. Usage rows (tokens and estimated cost, no content) are kept per school, with a default per-school daily cost ceiling of 500 cents.
Can school student data reach the AI provider? A school's own directors cannot turn AI off. The prompts and stats tools are written for volleyball clubs.
6. Service providers (subprocessors)
| Provider | What it handles | Data it sees |
|---|---|---|
| OVHcloud (VPS) | Application servers and database | All stored data (hosting). |
| Cloudflare | DNS, edge/CDN, Turnstile bot protection, R2 object storage for uploads and backups, optional email routing | Traffic metadata; files such as photos, forms, signed PDFs, attachments; database backups (R2). |
| Resend | Transactional and broadcast email; inbound replies | Recipient addresses, names, message content. School mail is sent from a configured sender address when set. |
| Stripe | Payments (only if the school connects Stripe) | Payer details, card data (held by Stripe), amounts, program and child names on invoices. |
| Documenso | E-signatures (only if used) | Signer names/emails, document contents, signatures. Self-hosted by us (its own container and database, backed up to R2), so it is our infrastructure, not a separate company holding a copy. |
| Expo (then Apple and Google) | Native mobile push, only when the push setting is on (default off) | Device tokens, notification title and body text. |
| Browser push services (Google, Apple, Mozilla) | Web push (PWA), only when VAPID keys are set | Browser push endpoint, notification payload. |
| Sentry | Error monitoring (only when a DSN is set) in the API, worker, web app and mobile app | Error traces. Request bodies, headers, cookies, user info and stack-frame variables are switched off in the API and in the web app. |
| Anthropic | AI features (see section 5) | Text of the question or draft, and tool results. |
| Slack | Operator alerts (job failures, cost-ceiling alerts) | Intended: none. Alert text names schools and error summaries. |
| Google Analytics | Marketing websites only; never the app | Page-visit and conversion events. The school site loads GA only in a production build with a measurement ID set; there is no cookie banner in that app. The web app and mobile app contain no analytics SDK. |
| Background-check provider | None connected | No real provider is wired; a provider-agnostic interface exists. Applies to staff, not students. |
Push notifications carry the notification title and body text (the message or event reminder), so a push may contain a student's name if the sender typed it; device tokens are deleted by the Data Erasure tool.
7. Retention and deletion
What is real today:
- A school administrator or director can run a Data Erasure for one student and family: a dry-run preview, then an execute step that needs the caller's password, runs all-or-nothing, and is audit-logged. It deletes or anonymizes notes, evaluations, attendance, roster rows, recruiting data, photos, messages, receipts, saved cards and the family's logins, and ends their sessions.
- Automatic purges, all configurable defaults: tournament guest rosters and contacts 90 days after the event; public contact-form messages anonymized after 365 days; coach job applications deleted after 365 days; stats-chat and Season Planner assistant logs 90 days; help-assistant rows 30 days; Stripe webhook payload detail redacted after 90 days. Tournament spectator follows are also purged.
- Data export. A guardian can request their student's data and a school administrator or director can request a full export, but there is no download button: the request creates a tracked row and emails the operator, and a super-admin compiles the ZIP and delivers it by hand. The school-wide export is one folder per player with profile, attendance, evaluations, stats, messages and signed contracts; coach notes are excluded. It is a player-data export, not a copy of everything the school entered (for example schedules, announcements and tournament data are not in it).
- Backups. Nightly database dumps are kept as the newest 14 plus anything under 30 days; pre-deploy dumps newest 10 plus anything under 14 days; Documenso's database likewise 14/30; the file-storage mirror keeps deleted or overwritten files 30 days. Erasure does not reach backups until they age out.
The stats-chat and help rows expire on their own (90 and 30 days); season narratives do not expire. Cloudflare and Anthropic copies are likewise outside the tool. These are handled by hand.
- When a school stops using the service. There is no offboarding action and no automatic deletion. Whole-school deletion is a manual operator process with no tool. The per-student erasure tool can be run student by student, but it is off by default and is not a school-deletion tool.
8. Security
Real measures (no certifications are claimed): Two-factor is not enforced and is not offered to parent or player accounts, and there is no single sign-on.
- Uploaded files are type-checked and virus scanned with ClamAV; if scanning is configured but unreachable, the upload is rejected.
- An append-only audit log enforced by a database trigger. The trigger does not protect against a compromised database owner, and logs are not shipped off the server.
Production is a single server and no uptime commitment is made. They are not independent third-party penetration tests and must not be described as such.
No system is perfectly secure. If we confirm unauthorized access to a school's student data, we notify the school within 72 hours of confirmation.
9. Parent and guardian rights
Guardians can ask the school to review the information held about their student, request correction or deletion, and refuse further collection. Requests go to the school first; we assist the school and can also be contacted directly. We act on a school's instruction for student records. Correction is done by the school editing the record; there is no guardian self-service correction or export download. "Refuse further collection" has no product mechanism other than the school removing the data or the erasure tool.
10. Cookies
The web app sets two sign-in cookies, access_token and refresh_token, both httpOnly, optionally with a __Host- prefix, and a theme cookie remembering light or dark mode. The web app also keeps interface preferences in the browser's local storage. We found no advertising or analytics code in the web or mobile app. The school marketing site may load Google Analytics (section 6).
11. Changes
We will post material changes and ask users to accept new terms in the product where required.
12. Contact
support@schoolathleticshq.com (help and privacy requests) and hello@schoolathleticshq.com (general).