Security

1. Tenant isolation

Every per-organization row carries an org_id column. Postgres row-level security (RLS) on every per-tenant table forces queries to filter by the signed-in user's org. The application code filters on org_id as well — defense in depth, not the primary guarantee.

2. Authentication

• Managers (Org Admin, Site Manager, Supervisor, Evidence Coordinator, Client POC, Attorney) sign in with email magic links via Supabase Auth. No passwords stored.
• Officers never have manager user accounts. Each officer gets an emailed magic-link to the guard portal (32-byte random token, SHA-256 stored). Sites may additionally require a per-site or per-shift bcrypt-hashed PIN on top of the magic link. After authentication an HMAC-signed cookie binds the session to the specific access-token row, so a stolen cookie alone is insufficient if the token has been revoked.
• External contractors (drug-test attendant, uniform vendor, etc.) receive scoped magic-link invites with a permission matrix (e.g. clear:drug_test, view:checkin_dashboard) — they never see surfaces outside the granted scope.
• Client POCs and Attorneys may also be granted hashed-token portal links scoped to a single site for read-only access without a full user account.
• Post visits are confirmed by a rotating QR token (24-byte random, SHA-256 stored). Rotating invalidates all prior QRs.
• Check-In kiosk tablet uses a bcrypt-hashed PIN on the device + a 12-hour cookie session bound to the tablet token, not to any user identity.

3. Authorization (server-side)

Six manager roles — Org Admin, Site Manager, Supervisor, Evidence Coordinator, Client POC, Attorney — each with a defined surface area. Officers are non-user records on the org roster. External contractor invites carry their own permission matrix. Every mutation API verifies the actor server-side against role and (for invites) the granted permissions. Hidden buttons in the UI are not security boundaries; they are UI hints.

4. Encryption

• In transit. TLS 1.2+ everywhere; HSTS on the application domain.
• At rest. Encrypted at the database layer (Supabase / AWS RDS storage encryption with AWS-managed keys).
• Secrets. Service-role keys, Stripe secrets, and webhook signing secrets are stored in the hosting provider's encrypted env-var store and only loaded server-side. The Supabase service-role key bypasses RLS — its module guards against being imported in browser code.
• PINs and tokens. Bcrypt for PINs; SHA-256 for URL tokens. We never store the plain values.

5. Chain of custody on legal exports

Every PDF export ends with a SHA-256 hash computed over a canonical JSON serialization of the report payload. The serialization sorts keys recursively so the same data produces the same hash byte-for-byte. A modification to any field — including a single character of an incident narrative — produces a different hash.

The export is logged in an exports ledger row with the actor, the byte size, and the hash. The PDF itself is persisted in private Supabase Storage and re-downloadable on demand.

6. Audit logging

A central audit_log table records every meaningful action — org created, site created, guard assignment created, portal link issued, portal link revoked, export generated, incident resolved, plan changed, Strike Mode toggled, payment events. Each row carries the actor, the resource, and a timestamp.

7. Vulnerability management

• Dependencies are tracked via the package manager's lockfile; security advisories from npm, GitHub Dependabot, and the underlying ecosystems are reviewed weekly.
• Critical advisories receive same-day patches; high severity within 7 days; medium within 30 days, where a patched version exists.
• Build-time TypeScript and ESLint enforcement; deterministic chain-of-custody hash test included in CI (pnpm test:canonical).

8. Incident response

On confirmation of a security incident affecting customer data:

• Containment within the first hour where technically feasible.
• Internal investigation with a written timeline.
• Affected-customer notice within 72 hours of confirmation, including nature of the incident, data categories involved, and recommended actions.
• Public post-incident summary on the status page for material outages.

9. Backups and continuity

• Daily automated database backups via Supabase, retained 7 days on the free tier and longer on paid tiers.
• Storage-bucket contents (legal-export PDFs) replicated alongside the database.
• Quarterly restore drill (planned post-launch — not in place yet).
• Recovery Point Objective: 24 hours. Recovery Time Objective: 24 hours. These are targets, not guarantees.

10. Vendor management

See the privacy policy for the current sub-processor list. We require sub-processors to commit to data-protection terms at least as protective as our own commitments to customers.

11. Access controls (internal)

• Production access uses individual accounts with required two-factor authentication.
• Service-role keys are not stored on engineer laptops; production deploys run from CI.
• Periodic access reviews on departure or role change.

12. Data residency

All Customer Data is currently processed in the United States. Customers with regional residency requirements should contact security@strikeleap.com before purchasing.

13. Roadmap (no commitment)

We do not hold the certifications below. Nothing in this section is a commitment, a timeline, or a representation that work is underway today. It is a list of items we expect to pursue and is provided so customers can ask informed questions about our direction. If a procurement process requires any of these as a precondition, please treat that condition as unmet and contact security@strikeleap.com before purchasing.

• SOC 2 Type II audit (not started; no auditor engaged).
• ISO 27001 certification (not started; no auditor engaged).
• Public data-processing addendum (DPA) template.
• Customer-side audit-log streaming.
• Single sign-on (SAML / OIDC) for Org Admin / Site Manager roles on Enterprise tier.

14. Reporting a vulnerability

Please send technical details to security@strikeleap.com. We acknowledge within 48 hours and follow standard responsible-disclosure timelines: 90 days from acknowledgment, or sooner if a patch is widely available. Please do not publicly disclose before we've had a chance to fix.

We do not currently run a bug-bounty program. Researchers acting in good faith and within these guidelines will not face legal action from us.