ISO/IEC 27035 Incident Response Playbook

Define the incident type and activation criteria first. Name the systems, services, data, users, suppliers, and environments the playbook covers, plus conditions that require a different playbook or specialist help. State the severity inputs, incident coordinator, response roles, alternates, decision authority, communication routes, safety constraints, and dependencies.

Then give an ordered but adaptable route through detection and validation, notification, triage, analysis, containment, eradication, recovery, reporting, and conclusion. Responders should be able to see the objective, required inputs, approved actions, evidence precautions, decision owner, output, and escalation trigger for every major step.

Build playbooks around the incident types and assets that the risk assessment says the organization needs to handle. ISO/IEC 27035-3 examples include malicious email or attachments, web attacks, brute-force or denial-of-service activity, supply-chain compromise, impersonation, improper use, and loss or theft of devices or media. These are starting points, not a complete taxonomy. Keep an exception route for an unknown incident type, with a default decision authority and a time limit for management approval.

Triage should confirm the report, identify the affected service or asset, assign priority from the organization's scale, and route the incident to people with the needed skills and authority. The playbook can offer scenario-specific questions, but it should not force an early conclusion when the facts are incomplete.

Analysis should separate observations from hypotheses. Record what happened, when it began, how it was detected, which accounts, hosts, data, services, and parties may be affected, what the adversary or failure can still do, and what information would confirm or reject each hypothesis. Correlate the incident with prior events and update scope and severity when new evidence appears.

Containment aims to limit continuing damage while preserving enough information to understand and resolve the incident. For each option, state the expected effect, operational cost, evidence risk, dependencies, approval, and rollback condition. Isolation, account disabling, filtering, or shutdown can protect services, but each can also destroy volatile data, interrupt critical operations, or hide activity.

Eradication removes incident components such as malicious code, compromised credentials, persistence, or unsafe configurations. Recovery restores systems, services, or data to an accepted operational state. The playbook should require clean sources, security hardening, credential actions, validation tests, monitoring for recurrence, business-owner acceptance, and a route back to analysis if recovery exposes new compromise.

Keep one chronological incident log that records observations, hypotheses, actions, results, approvals, evidence references, communications, and changes of direction. The playbook should tell responders where to record information and how to protect sensitive content; it should not scatter the authoritative chronology across chat, tickets, and personal notes.

List internal and external reporting routes by role, trigger, required facts, approval, channel, and source of the deadline. ISO/IEC 27035 supports timely, organized reporting but does not create a universal 24-hour or 72-hour legal limit. Legal, regulatory, contractual, insurer, customer, and law-enforcement decisions need their own applicability analysis.

Exercise the playbook at a depth proportionate to the scenario. A discussion can test roles and decisions; a simulation can test handoffs and communications; a technical exercise can test tools, access, evidence capture, containment, and recovery. Include relevant service providers when they hold logs, operate controls, or must approve or perform response actions.

Assign findings to owners and verify the resulting changes. Review the playbook after incidents, exercises, technology or supplier changes, threat changes, contact changes, and new legal or contractual obligations. Retire stale steps explicitly so responders do not follow an old system name, unavailable tool, expired credential, or departed contact.