Creating an incident response plan: template, roles, notification chains
An incident response plan defines who decides, who receives notifications and the order for shutting down, isolating and restoring systems before a crisis. It references the five core controls cyber insurers require: MFA, EDR, segregated backups, a patch process and the documented IR plan itself. It also assigns binding notification deadlines under revFADP (revised Federal Act on Data Protection), ISG, FINMA and DORA to specific roles and response times. Without this plan, teams improvise the 72-hour response, and insurers can contest the payout.
How this compares to neighbouring topics
This page describes the plan itself, meaning the document and roles that must exist before an incident. The actual execution including forensics, containment and communication during a crisis sits on Incident response within 72 hours. The ransomware-specific recovery strategy is on Ransomware backup strategy. Notification deadlines and warranties towards insurers are covered on SOC and cyber insurance. Regulatory notification chains are on revFADP and SOC and ISG notification duty. The operational picture is in the pillar SOC as a Service Switzerland.
Why an IR plan is mandatory, not optional
Cyber insurers in Switzerland and the EU require a documented incident response plan among the five core controls on their proposal forms. If it is missing during a claim, insurers reduce or deny cover. revFADP (revised Federal Act on Data Protection) (article 24), ISG (notification duty for critical infrastructure), FINMA (Guidance 05/2020, refined by Guidance 03/2024; resilience expectations under Circular 2023/1) and DORA (articles 17 to 23) require documented response capability. They also specify notification deadlines. Without decision-makers and communication chains fixed in advance, teams cannot meet these deadlines.
The biggest mistake is marking a plan as 'in place' on the proposal form when it lacks current contacts, roles and exercise history. Insurers scrutinise these details during a claim.
Mandatory content of a reliable IR plan
- Roles and deputies: incident commander, communications lead, legal and data protection contact, technical lead, executive sponsor. For each role primary and deputy contact including private numbers.
- Classification scheme: low, medium, high, critical, with clear criteria per level (crown jewels affected, personal data exposure, regulatory notification duty, business impact).
- Escalation path with time targets (first alert to first decision, first decision to executive communication, first decision to regulatory notification).
- External notification chains: customer, DPO or FDPIC, regulator (FINMA, OFCOM, cantonal), insurer, law enforcement, public. Draft language for the first two hours.
- Technical playbooks per scenario: ransomware, BEC in M365, token theft, data exfiltration, DoS. References to concrete runbooks rather than full text inside the master plan.
- Exercise and update cadence: at least one tabletop exercise per year, with a technical purple or red team element every two years. Review the plan after every incident and every exercise.
Alignment with the five insurer core controls
Five controls appear on nearly every Swiss and European proposal form. They include MFA for all privileged and remote access, EDR covering all endpoints, and segregated, tested backups. A maintained patch process and the documented IR plan complete the list. The plan must specify an owner, an evidence cycle and a response playbook link for each control. Quarterly backup restore tests are one example of an evidence cycle.
| Core control | What the IR plan pins down | Reference during a crisis |
|---|---|---|
| MFA | Owner, exception register, review cycle. | On compromise: session revocation and MFA re-enrolment as the first step. |
| EDR | Coverage rate, blind spots, isolation authority. | Isolation decision without ticket detours, documented with time stamps. |
| Segregated backups | Immutability rule, restore test history, recovery SLA. | Recovery sequence, see Ransomware backup strategy. |
| Patch process | SLA by criticality, exception approval, audit trail. | Emergency patching mandate and communication to operations. |
| IR plan (this document) | Version, approval, last exercise run, next review. | Draft language for communications with authorities and the insurer during the first 24 hours. |
Anchoring notification deadlines in the plan
- revFADP (revised Federal Act on Data Protection) article 24: notification to the FDPIC as soon as possible when there is a high risk to the rights of affected individuals.
- ISG notification duty: 24-hour initial report, then intermediate report after the initial notification, then final report.
- FINMA Guidance 05/2020, refined by Guidance 03/2024: initial notification of material cyber attacks within 24 hours of discovery, full report within 72 hours via the EHP. Circular 2023/1 sets the general operational resilience expectations.
- DORA article 19: initial, intermediate and final reports with clearly separated windows.
- Insurer: notification typically within 24 to 72 hours per policy. Delay is a frequent reason for cover reduction.
How ANOMAL operationalises the plan
ANOMAL develops the IR plan with the client using the existing crown jewel analysis, compliance scope definition and cyber insurance policy. The compliance scope covers revFADP (revised Federal Act on Data Protection), ISG, FINMA and DORA. ANOMAL links the plan to the operational SOC playbook so that detection signals automatically alert the correct roles. The process includes one tabletop exercise per year, documented follow-up and updates after every real incident. Combined with Incident response within 72 hours, this creates a unified cycle of planning and execution.
Frequently asked questions
How long should an IR plan be?
The master plan stays deliberately short, typically 15 to 30 pages, because it must be read during a crisis. Technical playbooks per scenario are separate runbooks referenced from the plan. A 200-page document that nobody opens under pressure satisfies no control.
How often does the plan need to be exercised?
Conduct at least one tabletop exercise per year with executive participation. Add a technical element every two years (purple team, see [Red team assessment](/en/services/red-team-assessment)). Every real incident counts as an exercise if the team documents the follow-up and updates the plan.
Can the plan start from an internet template?
An internet template can provide the structure. The content must reflect company-specific roles, contacts, classification, notification chains and regulatory scope. A generic plan does not pass an insurer's review during a claim.
What is the difference between an IR plan and a business continuity plan?
The IR plan governs the response to a security incident (detect, contain, communicate, notify). The BCP governs the continuity of critical business processes across any outage type. In a ransomware case both overlap, which is why the IR plan must explicitly reference BCP triggers.
Who should approve the plan?
The executive committee or the board should approve the plan and document the date and version. For FINMA-supervised institutions, this is an explicit supervisory expectation. Without executive approval, the plan cannot provide a reliable basis for decisions during a crisis.
Related terms
- Incident Response Incident Response is the structured process of containing, eradicating, and recovering from a security incident.
- Playbook A playbook is a predefined procedure describing how a SOC responds to a specific type of security incident.
- Runbook A runbook is a detailed operational procedure outlining the technical steps for a specific task.
- Tabletop Exercise A tabletop exercise simulates a security incident to test roles, decisions, and communication in a real emergency.
- Digital Forensics Digital forensics secures and investigates digital traces so an incident can be reconstructed and used as evidence.