ir-runbooklisted

# IR Runbook > **Operational discipline**: a runbook steers people under pressure; ambiguity costs time. Keep procedures concrete and testable — a step that cannot be executed at 03:00 without personal interpretation is not operational. Legal and regulatory aspects (breach notification, NIS2 incident reporting, contract clauses with customers/suppliers) are part of the runbook but require DPO/legal input for final decisions — this skill structures, it does not replace a lawyer during an incident. ## When to use An incident is not the moment to design procedures. This skill helps in advance with runbook construction and during with scenario selection, phase transitions, and regulatory timelines. Triggers on: - A question like "write a ransomware runbook", "what do we do on a suspicious phishing report from a user", "is this a data breach under AVG", "design a BEC procedure", "post-incident review structure". - An active incident response where phase determination or a regulatory question (NIS2 24h, AVG 72h, DORA 4h) needs clarity. - A handoff from `secrets-scanner` (leak confirmed, escalating to IR), `cve-triage` (CVE with confirmed exploitation), `forensics-assist` (forensics running in parallel with IR). - A tabletop exercise where you test the runbook. - Periodic runbook review (at least annually or after every significant incident). ### When NOT (handoff) - Policy-level IR policy itself (purpose, scope, roles at management level) → `policy-drafter`. An IRP policy is