Information security program

Summary. This is OverTime Sport Operations, LLC’s written information security program. It is deliberately sized to what a very small company can actually do every day rather than what a large one can put in a brochure: few people with access, strong defaults, encryption everywhere, backups that can be restored and that honor deletions, logs that show who did what, a written plan for a bad day, and one review a year. It is published because a family deserves to check it, and because writing it down is what makes it real.

Scope: the OT Elevate app, the backend service, the database, the data pipelines, the backups, and the vendor accounts used to run them.

Owner: the Company’s principal, who is the security officer for this program. The Company has no second person today, so there is no deputy; if that changes, this page will name them.

1. Access control#

• Named accounts only. Every person and every vendor console uses an individual account. No shared logins.
• Multi-factor authentication is required on every account that can reach production, customer data, source control, the app store account, or email.
• Least privilege. Access is granted per role and only to what the role needs. Production database access is limited to the smallest possible set of people — at present, the principal.
• Contractors get scoped, time-limited access to what their work needs, under a written confidentiality and data-protection agreement, and it is revoked the day the work ends.
• Access review at least twice a year, and immediately when anyone’s role changes or ends: list every account on every system, confirm it is still needed, remove what is not.
• Customer data is not browsed. Support access to an account’s contents happens only when it is necessary to answer a request from that account or to investigate a safety or security issue, and it is logged.
• Devices used for development and administration have full-disk encryption, a screen lock, automatic OS updates, and remote wipe enabled.

2. Secrets#

• No secret — API key, database credential, signing key, provider token — is ever committed to source control. A secret scan runs before every commit and refuses one that contains a credential or a key file.
• Secrets live in the cloud provider’s managed secret store (Google Cloud Secret Manager), injected at runtime, never in a file on a laptop and never in a chat message or ticket.
• Separate credentials for development, staging, and production. Nothing in development can reach production data.
• Rotation: at least annually, and immediately on any suspected exposure or when anyone with access departs.
• Production data is never copied into a development environment. Test data is synthetic.

3. Encryption#

• In transit: TLS 1.2 or higher for everything — app to backend, backend to database, backend to every vendor API. HTTP Strict Transport Security is on. No unencrypted internal traffic.
• At rest: the database, object storage, and backups are encrypted with the provider’s managed keys, at minimum AES-256.
• No passwords. Families sign in with Apple. The Apple sign-in identifier is held by our sign-in provider, Firebase; we keep only the account number Firebase gives it, and there is no password anywhere for anyone to read.
• On the device: the app stores credentials in the iOS keychain and relies on the device’s file protection for local data. Consumer health data is excluded from iCloud backup and any iCloud sync surface, as stated in Privacy policy.
• Name scrubbing is not yet in place. Personal names are not yet taken out of text before it is sent to an AI provider, as Privacy policy says.

4. Backups, restore, and deleting from backups#

• What is backed up: the production database and the object storage that holds the athlete record. Backups are encrypted with the same standard as the live data and stored in the same country.
• Schedule: daily automated backups on a 30-day rotation. Backups older than 30 days are destroyed automatically, which is what makes the 35-day purge window in Retention schedule achievable.
• Restore testing: a restore to an isolated environment is performed and verified at least twice a year. A backup that has not been restored is not a backup. The test is written down: date, what was restored, how long it took, what failed.

Deletion-from-backups procedure. When a parent deletes data or an account:

1. The record is deleted from the production database and from object storage immediately, and the app stops showing it at once.
2. A deletion entry — identifiers only, no content — is written to a deletion ledger, with the timestamp and scope of what was deleted.
3. The deleted data ages out of the backup rotation, gone from every backup copy within 35 days, and the ledger entry’s clock confirms it.
4. If a backup is restored for any reason, the restore is not complete until the deletion ledger is replayed against the restored data: every deletion recorded since that backup was taken is re-applied before the restored system is allowed to serve traffic. This step is part of the restore runbook and part of the twice-yearly restore test.
5. The deletion ledger itself is retained for 24 months and contains no personal content.

5. Logging and audit#

• Application and server logs record requests, errors, and security events. They do not record conversation content, health data, or credentials, and they are retained for 90 days.
• Audit logs record the things a person should never be able to do quietly: administrative sign-ins, permission changes, production database access, data exports, deletions, secret rotations, and changes to the crisis protocol’s fixed responses or detection rules. Our own audit records are kept 90 days, as Retention schedule publishes. Separately, Google Cloud keeps its own record of every administrative action on our cloud account for 400 days; Google sets that period and nobody, including us, can shorten it.
• Logs are stored separately from the systems they describe. Google’s record of administrative actions cannot be edited or deleted by anyone at the Company. Our own audit records cannot be changed or removed through the service, and any direct access to the production database by a person raises an alert (below).
• Alerts go by email to the principal, who is the one person able to act on them, and fire on:
• error-rate spikes: more than 5 server errors from the service in 5 minutes, and any error the code did not catch (at most one email per 30 minutes);
• failed-login bursts: more than 30 refused sign-ins in 5 minutes;
• unexpected administrative access: every change to who can reach the cloud accounts or to the sign-in system’s settings, every time a person rather than the service reads or changes a secret, and every time a person connects to or changes the production database;
• production data export: every export, copy or restore of the production database, and any reading of stored family files by a person;
• and any failed run of the scheduled jobs that carry out the retention schedule.

The alert definitions are kept as files with the cloud setup runbook (docs/runbooks/cloud-setup.md §14), so what runs is what is written here. - Logs are reviewed weekly at a glance and in full during any incident.

6. Change and development security#

• All changes go through version control with a written history. Direct edits to production are not permitted except during an incident, and are logged and reviewed afterward.
• Every change is tested before it is merged — the full backend and app test suites — and the secret scan above runs on every commit. Dependencies are checked for known vulnerabilities before each release.
• Dependencies are updated on a regular cadence; a known-exploited or critical vulnerability in a dependency we use is patched within 7 days.
• The crisis protocol’s fixed responses and detection rules are treated as security-critical code: changes require a written justification in the commit and are captured in the audit log.

7. Incident response#

An incident is any suspected unauthorized access to customer data, loss of data, or compromise of a credential or vendor account.

• What a notification says: what happened, when, what data was involved, what we have done, what you should do, and who to contact. We do not minimize and we do not wait for certainty about every detail before telling people something happened.
• The incident runbook, docs/runbooks/incident-response.md, is kept with this program and rehearsed at the annual review. It covers who does what when the Company is one person; the first hour, step by step; the order in which credentials are rotated, and the one that is never rotated because deletions depend on it; revoking every sign-in session; taking the service offline; the evidence to keep; the contacts and escalation paths for each vendor we use; and the notification deadlines of Texas and California law, with the process for every other state. Counsel confirms the deadlines before they are relied on.
• Any incident involving consumer health data is treated as high severity by default.

8. Vendor review#

• Before a vendor touches customer data: check what data they would get, confirm a written data-processing agreement limiting them to our instructions and forbidding sale or their own use of the data, confirm encryption in transit and at rest, confirm a current independent security report where one exists, and confirm where the data is stored.
• AI providers additionally must be on a paid tier whose terms commit to no training on customer content, and must have a stated retention limit. If they will not commit in writing, we do not use them.
• Vendors are reviewed annually against the same checklist, and the processor table in Privacy policy is updated whenever a vendor is added, changed, or dropped.
• Subprocessors that a vendor uses are the vendor’s responsibility under the agreement; a vendor must notify us before adding one that would handle our data.

9. People#

• Everyone with access — employee or contractor — signs a confidentiality and data-protection agreement before access is granted.
• Access is removed the same day someone’s work ends, and the access review confirms it.
• Security expectations are part of onboarding: phishing, device hygiene, and the rule that customer data is never copied out of production.

10. Annual review#

Once a year, in September, the whole program is reviewed and re-dated:

1. Walk every section above and correct anything that is no longer true.
2. Run the access review and the restore test, and record both.
3. Review the vendor list and the processor table.
4. Review the retention schedule against what the systems actually delete — pick a few categories and verify.
5. Review the incident log and the post-incident fixes.
6. Rehearse the incident runbook.
7. Re-date this document and Retention schedule.

A review that finds nothing wrong is a review that was not done properly.

Contact#

Security reports, including vulnerability reports, go to support@otsportops.com with “security” in the subject. We will acknowledge within 48 hours and we will not pursue anyone who reports a vulnerability to us in good faith and does not access or damage other people’s data.