Information Security Program

Why this page exists

4thCoach processes video of children. Children's privacy law requires that a service handling that kind of data maintain a written information security program and post it publicly, rather than simply asserting that it takes security seriously. This is that program. It is deliberately specific enough to be checked.

Who owns it

Bryan Elkus, on behalf of 4TH COACH TECHNOLOGY COMPANY, is the designated owner of this program and of any security or safety incident. 4thCoach is built and operated by one person; there is no security team and no second responder. That is stated plainly because it affects response times, and it's listed as a known gap below.

Report a vulnerability or a suspected incident to bryan@4thcoach.com. We will acknowledge a credible report within three business days. We do not currently run a paid bug bounty, and we will not pursue action against anyone who reports a flaw in good faith without accessing other people's data.

The risks this program addresses

The safeguards in the next section were chosen against these specific risks, in rough order of how much harm they'd cause:

• One account reading another's clips. The worst realistic outcome, because the content is video of somebody's child.
• Video persisting long after it's useful, widening the blast radius of any future breach.
• Over-broad internal access — an operator or an automated agent reading user data without a reason or a record.
• Credential or API-key exposure through source control, logs, or a build artifact.
• Unsafe or inappropriate model output reaching a child. Handled as a safety risk with its own reporting path, not only as a quality problem.
• Accidental destruction of user data by our own deploy, migration, or cleanup job.
• A vulnerable third-party dependency reaching production.

Safeguards in place

Access control

• Every clip and document is scoped to the account that owns it by server-enforced authorization rules. Cross-account reads are denied by the storage and database layers themselves, not only by application code.
• All traffic is encrypted in transit (TLS). Stored data is encrypted at rest by our infrastructure provider.
• Administrative access is an explicit allowlist, not a role anyone can assume. Every administrative read of user data is attributed to an identity and logged.
• API keys and signing secrets live in a managed secret store. Environment files are never committed to source control, which is enforced by an automated check rather than by convention.

Data minimization

• Clip video is deleted automatically 180 days after upload — see the Data Retention Policy. Less retained video is the single largest reduction in breach impact available to us.
• The age check stores only whether the account holder is an adult. We deliberately do not store anyone's date of birth.
• No advertising identifier is collected, and there is no advertising, attribution, or data-broker integration anywhere in the product.
• Image-similarity vectors used to suggest which athlete is in a clip are computed on your device and never leave it.

Resilience

• The production database has point-in-time recovery, deletion protection, and a daily backup schedule with a rolling retention window. Deletion protection means the database cannot be dropped by an API call or a console mistake without a separate deliberate step.
• Production deploys are gated behind a release tag and a manual approval, and every deploy has a corresponding one-command rollback to a previously shipped version.

Child safety

• Clip analysis runs only on an enterprise model endpoint under processing terms that prohibit training on submitted content. It never runs on a consumer AI surface.
• Content-safety thresholds are pinned on every analysis and chat call, and the coaching assistant's scope is constrained by automated tests, not only by prompt text.
• Any response can be reported from inside the app in one tap. Reports land in a dedicated queue — never mixed in with feature requests — and an unaddressed report older than 24 hours escalates automatically.

How these are tested

• Every code change. Authorization rules are covered by an automated test suite that runs against a real emulator on every proposed change, alongside route-level integration tests, type checks, and unit tests.
• Daily. An automated job compares the authorization rules actually deployed in production against the rules in source control and fails loudly on any drift. This exists because a rules regression once shipped and went unnoticed for two days. A separate synthetic probe exercises the full upload-and-analyze path against production daily.
• Daily. Dependency advisories are scanned automatically, and crash and error rates are monitored with alerting thresholds that page the owner.
• Annually. This program, the risks above, and the retention windows are reviewed and this page is updated. Next review: July 2027.

Known gaps

Publishing only the strengths would make this document useless. As of the effective date above:

• No backup responder. One person owns security and safety response, so a report filed at the start of a week away may wait. We are not able to guarantee same-day acknowledgement until a second person exists to name.
• No third-party penetration test or security audithas been performed. The controls above are self-assessed.
• The contact address is an individual's inbox, not a monitored role address. A dedicated safety address is planned.

If any of these change, this page changes with them.

Contact

Security reports, questions, or requests: bryan@4thcoach.com. See also our Privacy Policy and our Data Retention Policy.

4TH COACH TECHNOLOGY COMPANY
30833 Northwestern Highway, Suite 204
Farmington Hills, MI 48334
United States