# Incident Response Plan Topology: One Master Plan, a Playbook per Incident

> How to structure incident response documents so they work under pressure: one master plan for what every incident shares, a playbook for each of 12 incident domains, supporting policies underneath, and severity routing that connects them.

Source: https://playciso.com/blog/incident-response-plan-topology · Published: 2026-10-29 · Publisher: PlayCISO (https://playciso.com)

---

Write **one master incident response plan** for everything every incident shares, a **playbook for each type of incident** for the technical work, and a small set of **supporting policies** underneath both. The master plan says who is in charge, how bad it is, who is told and when. The playbook says what to do with this kind of incident in the first hour. Keep them separate and they stay short enough to use at 2am. Merge them and you get a 90-page plan nobody opens during an incident. This guide explains the structure, the 12 incident domains, and how routing by severity connects them. The [incident response hub](/incident-response) has every checklist, tool and lab for each layer. ## What is an incident response plan topology? It is the shape of your incident response documents: what lives where, and how one document hands off to another. Most organisations have the content somewhere. The trouble is that it is spread across a policy, a wiki page, a few runbooks and someone’s memory, and nobody knows which one to open when the alert fires. A clear topology has three layers: - Master plan. One document. It applies to every incident. - Domain playbooks. One per incident type. Each applies only when its triggers are met. - Supporting policies. The standing rules both layers rely on: backups, retention, evidence handling, crisis communications and post-incident review. The test of a good topology is simple. When an alert arrives, can the person on call answer two questions in under five minutes: _which playbook do I open_, and _how severe is this_? ## What belongs in the master incident response plan? Everything that does not change with the type of incident. If you find yourself writing the same paragraph into three playbooks, it belongs in the master plan. - Roles and authority. The incident commander, technical lead, scribe, legal, communications and executive sponsor, with named deputies. Give the incident commander emergency change authority in writing, or your change board will hold up containment. - Severity levels. Three or four levels, defined by impact, with who must join at each level and how often updates go out. - Escalation and contact paths. Including out-of-band contacts for when email or chat may be compromised. - The incident log. One timeline, opened at declaration, with times recorded for first detection, declaration and awareness. Several regulatory clocks start from awareness, so this record matters. - Legal, notification and insurance. Who decides whether something is notifiable, who tracks the clocks, when the insurer is told and how privilege is handled. - Communications. Internal updates, customer notices, regulators, media and investors, with one approval path. - Closure and lessons learned. What “closed” means, and a review with owners and dates. The [Master Incident Response Plan Checklist](/tools/master-incident-response-plan-checklist) walks through each of these with sample answers, and the [RACI builder](/tools/incident-response-raci-builder) turns the roles into a matrix you can hand to the executive team. If you are starting from nothing, the [incident response plan builder](/tools/incident-response-plan-builder) produces a first draft. ## What goes in a domain playbook? A playbook is the technical procedure for one kind of incident. Give every playbook the same headings, so responders never hunt for the containment section: - Triggers. The signals that route an incident here. “Access key used from an unknown location” routes to cloud; “hidden forwarding rule on a mailbox” routes to email. - First-hour actions. Short, ordered, specific. Not “contain the threat” but “revoke all sessions and refresh tokens for the account”. - Containment options. With what each one costs and what evidence it destroys. - Evidence sources. Which logs prove what, and how long each is kept. Many default retention periods are measured in days. - Domain-specific clocks. For example, wire recalls in a BEC case work best within 24 to 72 hours. - Hand-offs. When this playbook should open another one, and when to raise severity through the master plan. A playbook does not repeat the master plan. It says “declare under the master plan” and moves on. ## Which incident domains need their own playbook? Twelve domains cover nearly every incident a security team will see. Each has its own guide, checklist and lab on the [hub](/incident-response). DomainTypical trigger [Identity compromise](/blog/identity-compromise-response-plan)Impossible-travel sign-in on a privileged account; MFA method added unexpectedly Email and BECHidden inbox rule; supplier bank-detail change by email [Data breach](/blog/data-breach-response-plan)Bulk export; data offered on a leak site Ransomware and extortionMass encryption; backup deletion; ransom note [Network breach](/blog/network-breach-response-plan)Exploited VPN or firewall; new domain admin [DevSecOps and supply chain](/blog/devsecops-breach-response-plan)Malicious dependency; secrets in a build log [Cloud breach](/blog/cloud-breach-response-plan)Leaked access key; IAM user you did not create [OT / ICS](/blog/ot-incident-response-plan)Unexpected setpoint change; IT incident moving toward the plant Third party and SaaSVendor breach notice; SaaS security advisory AI systemAI feature reveals data it should not; agent takes an unapproved action InsiderBulk downloads before a resignation M&ACompromise found in due diligence or after close You do not need all twelve on day one. Write the ones you are most likely to face first. For most organisations that is identity, email, ransomware, data breach and cloud. ## What are the supporting policies, and why are they separate? Some rules are not incident procedures but every incident depends on them: **backup and restore testing** (can you restore, and how fast), **retention and archiving** (are the logs still there when you need them), **evidence and chain of custody**, **crisis communications**, and **post-incident review**. They are owned by different people, change on different schedules and are audited separately. Keep them as their own documents and reference them from the plan and the playbooks. ## How does routing by severity work? Routing is two separate decisions, and mixing them up is the most common design flaw. - Which playbook? Decided by the trigger: what kind of incident is it? - What severity? Decided by the impact: what is affected, how sensitive it is, whether operations or safety are hit, and whether regulators or customers may need to be told. Severity then sets who joins, how often updates go out and who can approve decisions. It does not change which playbook you follow. One rule prevents most under-classification: **judge severity by what the compromised thing can reach, not by how the first alert looks.** A phished login on a finance analyst looks low severity. If that analyst’s group can sign in to the cloud console with broad permissions, it is a potential cloud breach and data breach from the first minute. The [Incident Severity Router](/tools/incident-severity-router) asks those reach questions for you and returns a playbook, a severity level and a call list. ## What happens when an incident spans several domains? Most serious incidents do. A stolen login becomes a cloud problem when the identity can reach the console, and a data breach when the cloud access reaches customer data. The topology handles this with one rule: **one incident, one commander, several playbooks.** The incident commander stays the same; the lead playbook changes as the incident moves; the master plan keeps one log and one set of clocks throughout. The hand-offs are where time is lost. Each playbook’s hand-off section should name the signal that opens the next playbook and who owns it. The [Cascade Incident Lab](/tools/cascade-incident-lab) follows one incident from a phished identity through the cloud, data-breach and master-plan steps, and labels every decision with the playbook that owns it, so a team can see exactly where its own hand-offs are weak. ## How do you keep the plan and playbooks from drifting apart? - The master plan defines the interface. Severity names, role names and log format are set once. Playbooks reference them and never redefine them. - Same headings in every playbook. A reviewer can compare them side by side. - Review after every real incident. Ask which playbook was opened, whether it was the right one, and what slowed the hand-off. - Test with tabletops. Run at least one multi-domain exercise a year. Single-domain tabletops never test hand-offs. - Score it. The Incident Response Readiness Scorecard shows which layers and domains are covered and which are still empty. ## Checklist: is your incident response topology in place? - One master plan, approved by leadership, with roles, severity, escalation, log, legal, communications and closure. - The incident commander has written emergency change authority. - A playbook exists for each of your top five likely incident types, with the same headings. - Every playbook has triggers, first-hour actions, evidence sources with retention periods, and hand-offs. - Severity is defined by impact and reach, and is separate from the choice of playbook. - Supporting policies for backup, retention, evidence, crisis communications and review exist and are referenced. - Out-of-band contact details are stored somewhere that does not depend on your own email. - At least one multi-domain tabletop has been run in the last 12 months. ## Frequently asked questions **What is the difference between an incident response plan and a playbook?** The incident response plan is the organisation-wide document: who is in charge, how severity is set, who is told and when, how legal and notification decisions are made and how the incident is closed. A playbook is the technical procedure for one type of incident, such as a cloud breach or ransomware. The plan applies to every incident; a playbook applies only when its triggers are met. **How many incident response playbooks does an organisation need?** Start with the domains you are most likely to face and that would hurt most. For most organisations that is identity compromise, email and business email compromise, ransomware, data breach and cloud. Add network, DevSecOps, OT, third-party, AI-system, insider and M&A playbooks as your environment and risk require. Twelve domains cover nearly every incident type; few organisations need all twelve on day one. **Who owns the master incident response plan?** Usually the CISO or head of security operations owns the document, but it is approved by executive leadership because it gives the incident commander authority across departments, including emergency change authority and the power to call in legal and communications. Each domain playbook should have its own technical owner. **Does severity decide which playbook to use?** No. Severity and playbook are separate decisions. The trigger, meaning what kind of incident it is, decides which playbook opens. The impact, meaning what is affected and how badly, decides the severity, and severity decides who joins, how often updates go out and who can approve decisions. **What framework should an incident response plan follow?** NIST SP 800-61 Revision 3 (2025) is a common reference: it frames incident response as part of cybersecurity risk management using the NIST Cybersecurity Framework 2.0 functions. ISO/IEC 27035 is the international standard for information security incident management. Either works as a backbone; the master-plan-and-playbooks structure fits both.