Incident Management Procedure (A.5.24)

Document ID: incident-management-procedure
Version: 1.0
Effective from: 2025-01-01
Owner: ISMS owner
Review cycle: Annual (or after any Sev1 incident)

note

This document is aligned to ISO/IEC 27001:2022 Annex A as a self-assessment. SigmaShake holds no ISO 27001 certification.

---

Incident classification

This table follows docs/compliance/incident-response-plan.md section 3, which is the controlling document.

Severity	Definition	Status page (target)	Postmortem (target)
Sev1	Customer data exposure, Tier-1 service unavailable for more than 30 minutes, or confirmed key compromise	Within 15 minutes	Within 5 business days
Sev2	Tier-2 service unavailable for more than 2 hours, Tier-1 degraded, or control failure with no confirmed exposure (includes an external vulnerability report)	Within 1 hour	Within 10 business days
Sev3	Operational issue without customer impact, or a non-critical gap left unremediated past its target	Internal log only	At the discretion of the ISMS owner
Sev4	Trivial, cosmetic, or contained operationally	Internal log only	None

Every time in this table is an unmeasured target. It is not an SLA and not a guarantee. No 24/7 coverage exists, no paging vendor exists, and no mechanism measures these times. Alerts are Discord posts that a person must read.

Detection

Incidents may be detected via:

• Automated gap alerts from collectors (Discord webhook)
• cron-health flagging stale evidence
• External vulnerability disclosure
• Customer report via support portal
• Cloudflare security alerts
• GitHub Dependabot alerts (dep-vulns collector)

Response procedure

Step 1 — Detect and log

1. Record the incident in the compliance portal (/compliance/risks → create incident)
2. Classify severity (Sev1–4)
3. Set status to open

Step 2 — Contain

For Sev1/2:

• Rotate any suspect credentials immediately (rotate through the secret's own store: vault service, Cloudflare Secrets Store or wrangler secret put)
• Revoke affected access (GitHub org, Cloudflare account)
• If signing key compromised: set state to revoked in signing_keys, generate new key
• Enable IP allowlist break-glass if needed

Step 3 — Investigate

• Correlate with evidence_runs and audit_events
• Pull relevant evidence from R2 for the affected time window
• Determine root cause

Step 4 — Eradicate and recover

• Deploy fix
• Verify evidence collection resumes normally
• Run full cron trigger to regenerate any missing evidence

Step 5 — Post-incident review

• Sev1: target of 5 business days for the postmortem. Sev2: target of 10 business days (unmeasured targets, not an SLA)
• Upload postmortem to R2, link in incident record
• Review whether controls need strengthening

Breach notification

This section follows docs/compliance/breach-notification-procedure.md section 7.1. If the numbers differ, that section applies.

• Customer notice: affected customers receive notice within 72 hours of confirmation of a Personal Data breach. For a Sev1 incident that exposes customer data, the notice is an email from [email protected]. The email states what happened, the data classes potentially exposed, the window of exposure, the containment actions taken, the remediation steps for the customer, and a contact for follow-up (docs/compliance/incident-response-plan.md section 7.1).
• Customer as controller: where the customer is the controller and SigmaShake is the processor, the target is 36 hours of confirmed awareness, without undue delay. This is a target, not a guarantee.
• Supervisory authority (SigmaShake as controller): SigmaShake notifies the supervisory authority within 72 hours of awareness (GDPR Art. 33(1)), as docs/compliance/breach-notification-procedure.md section 5 sets out.

If California breach criteria are met, notice follows section 9 of that procedure.

Evidence

Collector	Cadence	Control
incident-log	Monthly	A.5.24–A.5.28
cron-health	Daily	A.5.36, A.8.16