Skip to content

Incident Response

Statement

ClaimGuard treats security incidents — confirmed compromise, suspected compromise, data exposure, availability events with a security cause — as first-class events that require named owners, documented decisions, and a written post-incident record. The current process is intentionally small for the team's size: a single primary responder (the founder on call), a documented intake channel, and a written record in the same hardening journal that captures cloud-posture changes.

There is no live 24/7 on-call rotation, no formal severity grading matrix, and no tabletop-exercised runbook yet. Those are the gaps that keep this control at partial until SOC 2 fieldwork.

Implementation

Intake channels

There are three ways an incident can be opened:

  1. External report via the Vulnerability Disclosure Policy: security@dtectvision.ai. SLAs in that document apply.
  2. Internal observation by an engineer — for example, an unexpected audit-log event, a Snyk finding that turns out to be exploitable, or anomalous traffic. The engineer notifies the founder pair directly.
  3. Cloud-side signal — alerts from GCP audit logs (immutable, 400-day retention; see Audit logging). Today these are reviewed reactively, not via a real-time alerting pipeline; that gap is named below.

Roles

Until a rotation exists, the founder pair (roee@dtectvision.ai, dor@dtectvision.ai) splits the incident-response responsibilities:

  • Incident Commander (IC) — owns the response timeline, decides on escalation, owns external comms.
  • Operator — runs the technical investigation: log queries, IAM changes, secret rotations, snapshot restores.

For now both roles default to the founder who first picks up the alert, with the other looped in within an hour. This is a known single-points-of-failure setup; documented as a gap.

Lifecycle

A response moves through these phases. The phases are nominal — we do not enforce a ticket workflow yet.

  1. Triage. Decide severity using the rough rubric below. If unclear, default up.
  2. Contain. Stop the bleeding: revoke a leaked credential, drop a firewall rule, restrict a user, take a snapshot before further changes.
  3. Investigate. Pull audit logs, application logs, and any relevant pm2 / system logs into a working document. Establish a timeline.
  4. Eradicate. Remove the cause: rotate secrets, fix the bug, close the misconfiguration.
  5. Recover. Restore service, verify health, monitor for recurrence.
  6. Post-incident write-up. Add a HARDENING-LOG.md entry with the full What/Why/Commands/Verify shape. For higher-severity events, write a stand-alone post-mortem document.

Severity (working rubric)

Level Definition Examples
SEV-1 Active compromise of production data or credentials. Confirmed JWT secret leak; live attacker in the VM; PII exfiltration.
SEV-2 High likelihood of compromise; not yet confirmed. Suspicious sustained outbound traffic from the VM; an audit-log event we cannot account for.
SEV-3 Security-relevant degradation without confirmed compromise. Public-facing dependency CVE we cannot patch in <24h; Snyk false-positive scan re-graded to true positive.
SEV-4 Reportable security finding from a researcher; no exploitation. Inbound VDP report.

These levels are guidance, not a contract — they primarily exist to align expectations on speed of response. SEV-1/2 are immediate; SEV-3 is same-business-day; SEV-4 follows the VDP SLA.

Containment toolbox

Pre-built containment actions, in rough order of severity:

  • Rotate JWT_SECRET in Secret Manager (forces every user to re-login). Procedure cross-references Secrets management.
  • Drop a project IAM binding for a suspect principal: gcloud projects remove-iam-policy-binding train-cvit2 --member=....
  • Revoke a service-account key if any exist: gcloud iam service-accounts keys delete ....
  • Take a forensic snapshot of the VM boot disk before further changes (procedure in Backups).
  • Tighten or drop a firewall rule to remove world-exposure of an affected port.
  • Stop the VM as the nuclear option: gcloud compute instances stop claim-guard-app-1 .... Customer impact, but it stops everything.

Comms

  • Internal-only events: logged in HARDENING-LOG.md and a private thread between the founders.
  • Customer-impacting events: decided by the IC on a case-by-case basis. There is no pre-built status page yet.
  • Researcher reports (SEV-4): handled per the VDP SLA — see Vulnerability Disclosure Policy.
  • Regulatory notification thresholds (e.g., GDPR 72-hour) are not yet codified in a runbook because we do not yet hold regulated-class data at material scale. This is documented as a gap to revisit before the first regulated-customer onboarding.

Evidence preservation

All privileged actions during a response are recorded in the project's _Required audit-log bucket with 400-day immutable retention. The written record in HARDENING-LOG.md is committed to git and is therefore versioned and reviewable. For an SEV-1 event, an immediate forensic snapshot of the VM boot disk creates an additional point-in-time copy independent of the running instance.

Status

partial — verified 2026-04-29.

What's in place:

  • A documented intake channel for external reports (security@dtectvision.ai) with published SLAs.
  • Named primary responders (founder pair).
  • A written rubric for severity grading.
  • A containment toolbox with procedures cross-linked to the relevant trust portal pages.
  • An immutable, 400-day audit log of every privileged action plus a written change journal.

Known gaps

  • No live on-call rotation. Both responders are founders; if both are unavailable, response is delayed. This is the single biggest gap and the reason this page is partial.
  • No formal post-mortem template distinct from the HARDENING-LOG.md shape. SEV-1 events warrant more than a journal entry; we have not had one to write yet.
  • No tabletop exercise has been run. The toolbox is documented but not drilled. A tabletop is scheduled before SOC 2 fieldwork.
  • No real-time alerting pipeline on GCP audit logs. Detection today is reactive (we'd notice a problem at the application layer or through a researcher report). Adding a Cloud Logging sink → Pub/Sub → notification on a defined alert set is a P2 roadmap item.
  • No status page for customer-facing comms during a high-severity event.
  • No codified breach-notification thresholds for GDPR / CCPA — we do not yet hold regulated-class data at material scale; this becomes required before the first regulated-customer goes live.

Roadmap

  • Tabletop SEV-1 exercise with a written post-mortem deliverable — before SOC 2 fieldwork.
  • On-call backup beyond the founder pair as the team grows past two engineers in scope.
  • Real-time alerting on a defined audit-log alert set (e.g., new roles/owner binding, world-open firewall rule, secret access from an unexpected IP).
  • Pre-built customer status page for the first material customer- facing incident.
  • Codified GDPR / CCPA breach-notification runbook before the first regulated-customer onboarding.