Data Security and Privacy Plan

Where this stands

This plan says what we do for a school’s data and marks, for each part, whether it is in place today or finished before a school signs: 14 of the framework’s 23 categories are in place today. We will not sign before the rest are.

The plan

1. How we implement the data security and privacy requirements over the life of the agreement. We sign the district’s data privacy agreement, including its Parents’ Bill of Rights, before any student’s information is entered, and keep to it for as long as we or our services hold the district’s data. The commitments in this plan, our security page and our privacy notices are written in our code, where automated tests check them on every change.

2. The administrative, operational and technical safeguards we have in place. Administrative: student data is used only to run the school’s teams, never sold or used for marketing, and reached only by people who need it. Operational: every change is reviewed and tested before production, and requests to correct, return or delete data have set times. Technical: encryption at rest and in transit, access checked on every request, private files, an activity log that cannot be edited, and daily backups. The framework table below gives each in detail, with what is finished before a school signs.

3. Training for our people and our subcontractors. Everyone at Athlete Orchard who could reach a school’s data will be trained on the federal and state laws on the confidentiality of student data, including Education Law 2-d and FERPA, before receiving access, and will sign an acknowledgment we keep; the training and acknowledgments are finished before a school signs. Our services are bound by their data processing agreements.

4. How our people and subcontractors are bound by written agreement. Our people will agree in writing to the confidentiality and data security terms of the district’s agreement before they receive access (with the training, finished before a school signs). Each service listed below is bound by a written data processing agreement to use the data only to provide its service, no less protective than our agreement with the district, and we review a service’s security before using it.

5. Managing incidents, finding breaches and reporting them. A suspected breach is contained, assessed and reported by our written incident plan. We tell the district within 7 calendar days of discovery, sooner where its agreement says so, in writing, with a brief description of what happened; the dates it happened and was discovered; the kinds of personal information involved; an estimate of how many records; what we are doing to investigate, or plan to; and a person families can contact for help; cooperate with the district, the state and law enforcement; and pay for, or promptly reimburse the district for, the full cost of the notifications a breach attributed to us requires. Our own error log alerts the founders at once to anything serious.

6. Returning data to the district. At the end of the agreement, or when the district asks, we give it a complete copy of its data in a standard format (spreadsheet or structured file), or transfer it to a successor the district names.

7. Secure destruction, and how it is certified. Within 90 days of the agreement ending, or of the district’s request, we delete its data from our systems and our services, and give the district a written certificate of deletion. Copies in our database’s daily backups are gone 7 days after that.

8. How we align with the district’s own policies. We read the district’s data security and privacy policy before signing and follow it. Where it asks more than this plan, the district’s agreement and policy govern.

9. How we align with the NIST Cybersecurity Framework. The table below takes each of the framework’s 23 categories (version 1.1) in turn and says what we do, and whether it is in place today or finished before a school signs.

The NIST Cybersecurity Framework, category by category

Identify

• ID.AM Asset management (In place). Every service that holds data is listed below, and every piece of student information the system can hold is listed in one place in our code, which our automated tests check against the database itself, so a new field cannot be added without the list changing.
• ID.BE Business environment (In place). We run team management for clubs and school teams: registration, rosters, schedules, messages, attendance and payments. Our dependencies are the services listed below.
• ID.GV Governance (Before a school signs). Our founders own security and privacy. Our public promises (the security page, the privacy policy, the children’s privacy notice and this plan) are written down and held to the code by automated tests. Left to do: a written information security policy, and a New York education lawyer’s review of this plan and the incident plan.
• ID.RA Risk assessment (Before a school signs). Every change is reviewed by a second party and an automated code review before it reaches production, and every change to the database is first proved against production data in a run that is rolled back. Left to do: a yearly independent penetration test, the first before a school signs.
• ID.RM Risk management strategy (In place). We collect the least we can about a student, keep access to the club or school that entered it, and fail closed: when a check cannot be made, access is refused.
• ID.SC Supply chain risk management (Before a school signs). Each service we use is bound by its data processing agreement to use the data only to provide its service to us. Left to do: each service’s signed agreement saved in one place, and their US data location confirmed in writing.

Protect

• PR.AC Identity management and access control (Before a school signs). Adults sign in through a dedicated sign-in service; students have no accounts. Each person’s access follows the role their club or school gives them, checked by our servers on every request, and no club can see another’s records. Our founders reach a school’s data only while one of its administrators grants it, for a day or a week; every grant is in the school’s activity log, and every page a founder opens that shows students is listed for the school. Left to do: a school’s staff act there only with a second sign-in step (an authenticator app), which the code requires; our sign-in service is set to offer it before the first school club is marked.
• PR.AT Awareness and training (Before a school signs). Everyone at Athlete Orchard who could reach a school’s data will be trained on the federal and state laws on the confidentiality of student data before they receive access. Left to do: the training written, and each person’s signed acknowledgment kept.
• PR.DS Data security (In place). Data is encrypted at rest and in transit (TLS, with browsers told never to use a plain connection). Files are private, and permission is checked every time one is opened. A student’s name is never sent to the payment processor, and a roster photographed for import is read on the coach’s own device. A spreadsheet imported for a roster is kept only while the import is checked. Daily backups age out after 7 days.
• PR.IP Information protection processes and procedures (In place). Every change goes through review, automated tests and a second party’s approval before production. A club or school can download a copy of everything it holds at any time, as spreadsheets. Its owner can have it deleted: the deletion waits at least 30 days so it can be cancelled, then erases everything at once, files included, and emails a certificate of deletion. When an agreement ends, or a district asks, we start that deletion ourselves, so it is finished well within 90 days.
• PR.MA Maintenance (In place). Our software and its dependencies are updated through the same reviewed changes; the infrastructure is maintained by the services listed below.
• PR.PT Protective technology (In place). Every page is served with standard security headers, and no other site can frame our pages. Staff edits to a student’s details and registrations are kept in an activity log that cannot be edited, and every time someone on a club’s staff, or one of us, opens a page, a message or a download that shows students, it is logged: who, when, where, which students and what kind of detail, kept 13 months. The one place a student’s name reaches staff unlogged is a sign-up sheet’s “Ava’s family” label, which every family on the team sees too.

Detect

• DE.AE Anomalies and events (Before a school signs). Unusual sign-ins and unusual reads of student records will raise an alert to our founders. Left to do: the alerts themselves (build 4).
• DE.CM Security continuous monitoring (In place). Errors on our servers, in the morning run and in people’s browsers are recorded in our own database, with no outside service: counted by kind and hour, scrubbed of addresses, ids, numbers and quoted values, and kept 90 days. The founders get them by email every morning there are any (and every Monday regardless, so a stopped monitor is noticed), and at once for anything touching money, a club’s deletion or export, sign-in, the activity log or the record view log, or any burst.
• DE.DP Detection processes (Before a school signs). Who watches, what counts as an incident and how a suspected breach is escalated are written down in our incident plan, and will be practised twice a year. Left to do: the first practice run, held before a school signs (build 4).

Respond

• RS.RP Response planning (In place). A suspected breach is handled by our written incident plan: recorded, contained, investigated, the affected school told, put right and learned from, in that order, with a person named for each step.
• RS.CO Communications (In place). We tell the school or district within 7 calendar days of discovering a breach, sooner where its agreement says so, in writing, with a brief description of what happened; the dates it happened and was discovered; the kinds of personal information involved; an estimate of how many records; what we are doing to investigate, or plan to; and a person families can contact for help. We cooperate with the district, the state and law enforcement, and pay for, or promptly reimburse the district for, the full cost of the notifications a breach attributed to us requires.
• RS.AN Analysis (In place). An incident is investigated from the activity log (every change, kept), the log of who opened which student’s record (kept 13 months) and our own error log (kept 90 days), to establish what was reached and by whom.
• RS.MI Mitigation (In place). We can revoke a person’s access, end sessions and replace credentials at once, and roll back an import.
• RS.IM Improvements (Before a school signs). Each incident and practice run will end with what changes, and this plan will be updated. Left to do: the first practice run (build 4).

Recover

• RC.RP Recovery planning (In place). The database is backed up daily, with 7 days of backups to restore from, and a bulk import can be undone in one step.
• RC.IM Improvements (Before a school signs). Recovery will be reviewed after each incident and practice run. Left to do: the first practice run (build 4).
• RC.CO Communications (In place). During recovery we keep the school or district informed, and say nothing publicly about its data without it.

The services that would hold a school’s data

• Supabase, database and file storage. Holds: Every record a club or school keeps. Where: United States (AWS us-east-1).
• Vercel, application hosting. Holds: Requests while they are served, and short-lived server logs. Where: United States (Washington, D.C. region).
• Clerk, sign-in for adults. Holds: Adult accounts only; students have no accounts. Where: United States.
• Resend, email delivery. Holds: Emails to parents and staff, which can name a student. Where: United States.
• Stripe, payments. Holds: A parent’s payment details; never a student’s name. Where: United States, with global processing.
• Anthropic, the in-app assistant and reading a practice plan photo. Holds: Nothing for a school club: both features are off for school clubs, and a photo of a plan is read on the device instead, until Anthropic agrees in writing to keep nothing. Where: United States.

Supplemental information for the district’s Parents’ Bill of Rights

• Contractor: League Orchard, LLC, which runs Athlete Orchard.
• Purposes: Running the school’s sports teams: registration, rosters, schedules, messages to families and staff, attendance, and fees.
• Type of information: Student information (no teacher or principal evaluation data).
• Contract term: As set in the district’s agreement.
• Subcontractors: Used, each under a written agreement at least as protective as ours (listed on this page).
• At the end of the agreement: Data returned to the district or its successor in an agreed format, then securely deleted within 90 days, with a certificate.
• Challenges to accuracy: Parents, students, teachers and principals ask the district; we make a correction within 21 days of the district’s written request.
• Where it is stored: Cloud infrastructure owned and hosted by third parties, in the United States.
• Encryption: Encrypted while in motion and at rest.

Questions

A district reviewing this plan can ask for our written policies at legal@athleteorchard.com.