CyberForte
0/32 guides done, see your progress

Home Secure by Design and Default Playbook 12

Playbook 12 of 22 · Secure by Design · Operational Integrity

Incident response and recovery

Hope for the best, plan for the bad day, and rehearse it.

Operational IntegritySecure by Design
CyberForte's summary · not ENISA text

In plain words

Something will go wrong eventually: a leaked key, a compromised account, ransomware. The difference between a bad day and a disaster is usually preparation. Decide now who leads, who decides, and who talks to customers.

Write a short runbook (spot it, size it, contain it, fix it, recover, learn), make sure you can quickly revoke keys, disable accounts and roll back releases, and keep tested backups. Then spend 30 to 60 minutes each quarter walking through one realistic scenario.

Picture this: "We found an API key on a public website" is a great tabletop exercise. Who rotates it, how fast, and who tells which customers?

Your turn

Practical checklist

A short, practical version for small teams, written by CyberForte from the ENISA playbook. The full ENISA checklist, evidence list and release gate are in the original text below. Your ticks are saved only in this browser.

Original text · unchanged

The full ENISA playbook

Source: ENISA Secure by Design and Default Playbooks, 12-incident-response-and-recovery.md, European Union Agency for Cybersecurity (ENISA), licensed under CC BY 4.0. Reproduced word for word; only converted from Markdown to this page.

Incident response and recovery

Principle

(secure by design)

Developers must be prepared to respond quickly and effectively to security incidents that affect their products in the field, including vulnerabilities, compromised code, malicious updates and misuse of product functionality.

Objective

Detect, contain and recover from security incidents quickly while limiting customer impact and preventing recurrence. The priority is a clear playbook, defined ownership, fast triage and reliable restore/rollback, supported by the minimum logging and backup evidence needed to act decisively.

Checklist

Define roles, escalation and decision authority

  • Name an incident lead and backups. Define escalation thresholds, when senior management should be informed and who can approve customer communications, access elevation and emergency changes.
  • Maintain an on-call/escalation contact list (internal + key suppliers).

Create a minimal incident runbook

  • Steps: detect, triage, contain, eradicate, recover, lessons learned.
  • Include checklists for common scenarios (account takeover, leaked API key, ransomware/supply-chain alert, compromised device fleet).

Prepare containment controls

  • Make sure that it is possible to revoke/rotate credentials and keys quickly.
  • Make sure that it is possible to disable accounts, block IPs, quarantine services/devices and roll back releases / config changes.
  • Ensure that break-glass access exists, is logged and is time bound.

Ensure recovery capability

  • Backups are automated, tested and protected (immutability where feasible).
  • Restore procedures are documented for critical systems (data, configs, secrets, device firmware if applicable).
  • Define RTO/RPO targets appropriate to the business.

Exercise and improve

  • Run a lightweight tabletop exercise (30–60 minutes) quarterly on one realistic scenario.
  • Record and review incidents, near misses and exercise findings. Track actions to closure and update risk assessments, threat models, runbooks, detections and controls as appropriate.

Minimum evidence

  • Defined roles: incident-response contact list + roles (owner, backups and escalation paths established).
  • Runbooks: one-page incident runbook and at least one scenario checklist.
  • Containment proof: documented steps and permissions to revoke keys, disable accounts and roll back deployments.
  • Backup/restore proof: backup configuration and one recent restore test result (or evidence of a successful restore).
  • Post-incident, near-miss or tabletop notes showing findings, actions and resulting improvements.

Release gate

  • [ ] IR roles and escalation contacts are current
  • [ ] Incident runbook exists and covers detect/triage/contain/recover with at least one common scenario
  • [ ] Containment actions are ready
  • [ ] Backups enabled for critical data/config; restore procedure documented and tested recently
  • [ ] Post-incident, near-miss or tabletop notes exist and are updated
↑ ↓ to moveEnter to openEsc to close