Clerk.io

Information Security Incident Response Procedure

1. Purpose

Provide a structured approach for detecting, responding to and recovering from security incidents.

2. Scope

Applies to all information systems, personnel and third parties.

3. Definitions

4. Roles

Role Duty
Incident Commander Coordinates response; typically Head of Product
Communications Lead Handles internal/external comms; typically Head of Product (SRE Lead assists when urgent)
Technical Lead Performs investigation & remediation; typically SRE Lead
Timeline Documentation Post-incident timeline reconstruction; typically SRE Lead

5. Phases

  1. Preparation – Training, runbooks, tooling (Better Stack, Datadog).
  2. Identification – Alerts from Datadog, customer reports, Google/Slack security notifications.
  3. Containment – Short-term (isolate systems), long-term (patch, reimage).
  4. Eradication – Remove root cause (malware, vuln).
  5. Recovery – Restore services, monitor for re-occurrence.
  6. Lessons Learned – Post-mortem within 5 business days.

6. Severity Matrix

Sev Criteria Response Time
1 – Critical Data breach, widespread outage ≤ 15 min
2 – High Limited customer impact ≤ 30 min
3 – Medium Internal system issue ≤ 4 h
4 – Low No immediate impact Next business day

7. Notification Obligations

8. Evidence Handling

Logs are collected and queried via Datadog; evidence is exported from Datadog as needed. No formal chain-of-custody procedures are currently implemented.

9. Post-Incident Review

Root-cause analysis (RCA) meeting produces corrective actions logged in Linear; track to closure.

10. Testing

Conduct at least 6 tabletop exercises per year (bi-monthly); critical runbooks tested bi-monthly.


Version 1.1 — effective 2025-08-28