← Security overview
Security policy

Incident Response Plan

Roles, severity tiers, triage → contain → eradicate → notify phases, sub-processor inheritance, post-incident review template, and the 72-hour customer breach-notification commitment.

Canonical source under version control · provided in writing to any customer that requests it as part of vendor due diligence.

Soundcheck Insights — Incident Response Plan

Owner: Valter Klug, Founder & CEO Version: 1.0 — June 2026 Review cadence: at least annually, or after any security incident.

This is the written incident-response plan referenced in §Q10 of the Vendor Security Questionnaire. It is intentionally short and operational. Soundcheck Insights is currently founder-operated; this plan scales to that reality and is updated as headcount grows.

1. Definitions

  • Security incident — any event that compromises (or may have compromised) the confidentiality, integrity, or availability of Client Data, the Platform, or Soundcheck's sub-processor credentials. Examples: unauthorized account access, leaked API key, database breach, sub-processor outage with data exposure, malicious code in a dependency, supply-chain compromise, accidental public exposure of a private project.
  • Confirmed breach — an incident that has actually exposed Client Data outside the contractual access perimeter. A suspected incident becomes "confirmed" after triage, not before.
  • Affected customer — any operator whose project content, uploaded files, share links, or operator credentials are confirmed or reasonably likely to have been exposed.

2. Reporting an incident

External reports → info@soundcheckinsights.com, subject line Security report. Acknowledged within one (1) business day.

Internal triggers → any super-admin or Soundcheck contractor who observes an incident-class event escalates directly to the founder within two (2) hours.

Every report is logged with timestamp, reporter, and short summary.

3. Roles

At the current scale, the founder fills every role. As headcount grows, the roles below are populated by name.

Role Responsibility Held by
Incident Commander Owns the response, makes containment + disclosure calls. Founder
Technical Lead Investigates root cause, applies fixes, captures evidence. Founder
Communications Lead Customer + sub-processor + (if required) regulator comms. Founder
Legal Lead Notification obligations, contract review, evidence preservation. Founder; external counsel engaged for any confirmed breach.

4. Response phases

4.1 Detect & triage (target: ≤ 4 hours from first signal)

  1. Acknowledge the report.
  2. Reproduce / verify. If the signal is a false positive, log + close.
  3. Classify severity:
    • Sev 1 (Critical) — confirmed data exposure, credential compromise, or active intrusion.
    • Sev 2 (High) — suspected exposure not yet confirmed; or vulnerability that could plausibly lead to exposure.
    • Sev 3 (Moderate) — operational issue with no apparent data impact.

4.2 Contain (target: ≤ 8 hours for Sev 1/2)

  • Revoke compromised credentials immediately (Clerk session revocation, Vercel env-var rotation, Anthropic API key rotation, Neon role disable).
  • Block the attack surface (CSP tightening, Vercel WAF rule, function shutdown).
  • Snapshot evidence: function logs, Inngest run logs, database state, Vercel deployment record.

4.3 Eradicate & recover (target: ≤ 72 hours from confirmation)

  • Apply code fix (patch, dependency update, schema change).
  • Verify all sub-processor environments are clean.
  • Re-issue credentials and confirm rotation across every system.
  • Restore service. Confirm full functionality on every product surface (research generation, dashboards, monthly updates, Telegram bot, share links).

4.4 Notify (statutory + contractual)

  • Customers (affected agencies): notify the agency admin via email without undue delay and no later than 72 hours after a confirmed breach affecting their data, with: scope of data affected, sub-processors involved, what we have done, what they should do, single point of contact for follow-up.
  • Sub-processors: notify any relevant sub-processor (Clerk, Vercel, Neon, Anthropic, Inngest, Tavily) per their notification channels if the incident touches their layer.
  • Regulators: evaluate notification obligations under the Florida Information Protection Act (FIPA) and any other applicable US state breach-notification statute. No EU customers are currently on the platform; GDPR Article 33 timing is monitored for future enrollment.

4.5 Post-incident review (target: within 2 weeks)

  • Written report: timeline, root cause, customer impact, remediation, follow-up actions. Stored under docs/security/incidents/YYYY-MM-DD.md.
  • Update this plan if the incident exposed a gap.

5. Contractual commitments

  • Breach notification window: 72 hours from confirmation, to all affected customers.
  • Acknowledgement window: one (1) business day for any external security report.
  • Evidence retention: raw logs and forensic snapshots are kept for at least one (1) year after incident closure.

6. Standing controls that reduce blast radius

Already shipped as of June 2026:

  • TLS in transit (Vercel); AES-256 at rest (Neon, Vercel Blob).
  • Server-only Anthropic and Telegram API keys; never reachable from a browser.
  • Single scoped-query helper for every tenant read (no raw queries bypass it). Logged.
  • Soft-delete by default; hard delete only via written request + founder action.
  • Top Secret / Incognito Mode toggle blocks even super-admin reads on flagged projects.
  • Webhook signature verification on every Clerk, Inngest, and Telegram inbound.
  • Strict security headers: HSTS, CSP, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin, Permissions-Policy with all sensitive browser APIs disabled, Cross-Origin-Opener-Policy same-origin.
  • MFA enforced on every super-admin account (Clerk-backed), and on every external admin console used to operate the platform (GitHub, Vercel, Neon, Anthropic, Inngest, Tavily — all backed by Google OAuth with MFA enforced upstream).
  • Per-IP rate limit on every /share/* public route at 60 requests/minute, returns 429 with Retry-After on overage.
  • Anthropic DPA + Standard Contractual Clauses in force via Anthropic's Commercial Terms of Service (auto-incorporated, March 2026 policy). ZDR requested from Anthropic support.
  • Continuous static analysis (CodeQL security-extended query suite on every push, PR, and weekly cron) + dependency vulnerability audit (pnpm audit --prod --audit-level=high on every push, PR, and daily cron) + Dependabot weekly bumps. Findings land in the GitHub Security tab.
  • Public Vulnerability Disclosure Policy with safe harbor at /security/disclosure, paired with /.well-known/security.txt per RFC 9116.

Planned (not gating this plan): formal third-party penetration test, SOC 2 readiness assessment, published GDPR DPA template, GitHub Team plan upgrade to make branch protection rules enforceable on the private repository (today the rules are configured but advisory under the GitHub Free tier for private repos; CI status checks still run on every push).

7. Sub-processor incident inheritance

If a sub-processor (Clerk, Vercel, Neon, Anthropic, Inngest, Tavily) declares an incident that may have touched our environment, this plan triggers automatically. We treat it as a Sev 2 until we can confirm we were not in the impact window.

8. Document control

  • Storage: repository under version control. Every change is a git commit attributable to a named actor.
  • Review: annually in June, or immediately after any Sev 1 or Sev 2 incident.
  • Distribution: linked from the Soundcheck Security page (/security) and provided in writing to any customer who requests it as part of vendor due diligence.

Soundcheck Insights LLC · Florida, United States · © 2026