Security Incident Response Plan

This plan describes how FalconEye-Faceoff Intelligence System LLC (“FalconEye”) detects, contains, investigates, and reports security incidents affecting the FalconEye platform, including Customer Content (video footage, scouting notes, player data, and statistics) and Account Information. It applies to all systems FalconEye operates or controls, including its Google Cloud/Firebase infrastructure, and to data processed on FalconEye's behalf by its subprocessors.

FalconEye currently operates as a small team. Until a dedicated security role is established, the following responsibilities are held by the founder: monitoring FalconEye's systems and infrastructure for potential security incidents; leading triage, containment, investigation, and remediation for any confirmed incident; determining notification obligations and notifying affected Customers and, where required, regulators or other authorities; coordinating with subprocessors on any incident originating in their systems; and maintaining and updating this plan.

Any of the following triggers this plan: unauthorized access to, or acquisition of, Customer Content or Account Information (e.g., a compromised admin credential, a database security-rule misconfiguration exposing tenant data, an exposed API key); loss, corruption, or unavailability of Customer Content outside normal service disruptions; compromise of a subprocessor that plausibly affects FalconEye customer data; malicious code, unauthorized changes to production data or backend functions, or evidence of account takeover; or any credible report from a customer, researcher, or automated alert suggesting one of the above.

Incidents may be identified through: cloud infrastructure security alerts and anomaly notifications; routine security-rule audit review, performed by the Incident Lead; customer or user reports submitted to chris@falconeyefaceoff.com; and routine review of the admin panel's audit log and API usage dashboard for anomalous activity or unexpected cost spikes.

Step 1 — Triage (target: within 24 hours of detection). Confirm the report is credible and determine what system(s), tenant(s), and data types are potentially affected. Classify severity: Critical (confirmed unauthorized access to Customer Content or credentials), High (suspected but unconfirmed exposure), Low (isolated, no data exposure).

Step 2 — Containment. Revoke or rotate any compromised credentials or API keys. Tighten or correct database and storage security rules if a misconfiguration is the cause. Disable the affected account, tenant, or backend function if needed to stop ongoing exposure. Preserve logs before they roll off retention, for later investigation.

Step 3 — Investigation. Determine root cause, scope (which tenants/customers/individuals are affected), data types involved, and whether the exposure was actually accessed or merely accessible. Document findings and timeline as they are established.

Step 4 — Notification. For incidents confirmed to involve unauthorized access to, or acquisition of, Customer Content or personal information: affected Customers are notified without unreasonable delay and in no case later than 72 hours after FalconEye confirms an incident meets the definition in Section 3. Notification is sent to the Customer's designated account contact via email, with a phone or video follow-up offered for Critical-severity incidents. Notification includes what happened, what data was involved, what FalconEye has done to contain it, and what the Customer should consider doing. Where a Customer is subject to a state ed-tech breach law or district-specific reporting requirements, FalconEye will reasonably cooperate with the Customer's own notification obligations and timelines, which may be shorter than the 72-hour commitment above. FalconEye will not publicly disclose incident details that could identify an affected Customer or individual without that Customer's consent, except as required by law.

Step 5 — Remediation & Post-Incident Review. Apply permanent fixes beyond the immediate containment step. Document a brief post-incident summary: what happened, root cause, what was fixed, and what will change to prevent recurrence. Update this plan if the incident revealed a gap in the process itself.

If a subprocessor reports an incident that plausibly affects FalconEye customer data, FalconEye will evaluate the report against Section 3 and follow the same notification timeline in Section 5, Step 4, measured from FalconEye's confirmation of impact.

This plan is reviewed at least annually and after any Critical-severity incident. As FalconEye adds staff, formal SOC 2-aligned controls, or additional subprocessors, this plan will be updated to reflect expanded roles and escalation paths.

Security incidents and questions about this plan: chris@falconeyefaceoff.com