Topics in this domain
- Event vs Incident vs Breach
- Developing the Incident Response Plan
- Incident Response Team Roles and Authority
- Incident Classification and Severity Levels
- Incident Response Playbooks and Decision Trees
- Escalation and Communication Plans
- Business Impact Analysis
- RTO, RPO, MTD and Recovery Prioritisation
- Business Continuity Planning and Strategies
- Crisis Management and Continuity Governance
- Disaster Recovery Planning
- Recovery Sites: Hot, Warm and Cold
- Backup Strategies and Cloud DR
- Incident Response Training
- Testing Plans: Tabletop, Functional and Full Interruption
- Evaluating Exercises and Improving Readiness
- Security Event Detection and Monitoring Methods
- SIEM, the SOC and Event Correlation
- Threat Intelligence and Indicators of Compromise
- Incident Triage and Initial Investigation
- Evidence Preservation, Forensics and Chain of Custody
- Containment Strategies: Short-Term and Long-Term
- Making Containment Decisions
- Breach Notification and Regulatory Reporting
- External Communications: Customers, Media and Law Enforcement
- Eradication, Recovery and Return to Normal Operations
- Post-Incident Review and Root Cause Analysis
- Lessons Learned and Incident Trend Analysis
Developing the Incident Response Plan
Plan before you need it
Incidents happen at the worst times, under pressure, with incomplete information. A plan agreed in calm conditions tells people what to do, who decides and who to call, so the first hours aren’t wasted arguing. One CISM task is to establish and maintain an incident response plan, in alignment with the business continuity plan and disaster recovery plan.
The incident life cycle
| Phase | Purpose |
|---|---|
| Prepare | Plan, team, tools, contacts, training. The most important phase. |
| Detect and analyse | Identify incidents, confirm them, classify severity |
| Contain | Limit the damage and spread, preserving evidence |
| Eradicate | Remove the cause: malware, accounts, vulnerabilities |
| Recover | Restore normal operations safely, with monitoring |
| Lessons learned | Root cause, improvements, plan updates |
What the plan contains
- Scope and definitions: what counts as an incident; severity levels.
- Roles and authority: the team, the incident manager, and who may decide what (shutting systems down, calling law enforcement, notifying regulators).
- Procedures and playbooks for each phase and common incident types.
- Communication and escalation: internal, regulators, customers, media.
- Tools and resources: forensic tools, contact lists, retainers, out-of-band communication channels.
- Links to the BCP and DRP: when a major incident becomes a disaster.
Developing the plan
- Sponsor: senior management commitment.
- Inputs: risk assessment, BIA, legal requirements, past incidents.
- Draft with IT, legal, HR, communications and the business.
- Approve: senior management, giving the team its authority.
- Train and test: tabletops and simulations.
- Maintain: update after incidents, tests and significant change.
Keep copies offline or out of band: a plan stored only on systems an incident could take down is useless.
Aligning with BCP and DRP
- Incident response investigates, contains and eradicates the threat.
- Disaster recovery restores systems and data, from clean backups.
- Business continuity keeps critical processes running in the meantime.
- They need shared triggers: an agreed point when an incident escalates into BCP or DRP.
Example. During a ransomware attack, the IR team contains the spread while DR restores finance systems from immutable backups and the BCP moves order-taking to manual forms. Because the three plans share a declaration process and a contact list, they run in parallel without confusion.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Most important phase of incident response | Preparation |
| Who approves the incident response plan? | Senior management |
| The incident response plan must align with… | The BCP and DRP |
| Where to keep copies of the plan | Accessible offline or out of band |
| When to update the plan | After incidents, tests and significant change |
In short
- Establishing and maintaining an incident response plan aligned with the BCP and DRP is a CISM task.
- The plan defines scope and definitions, roles and authority, procedures, communication and escalation, tools and resources, and links to BCP and DRP.
- It supports the incident life cycle: prepare, detect and analyse, contain, eradicate, recover, and learn.
- Senior management approves the plan, giving the team the authority it needs during a crisis.
- Preparation is the most important phase: plan, team, tools, contacts and practice before anything happens.
- The plan is tested, reviewed after incidents and exercises, and kept available offline.
Exam traps
- A plan written during an incident is too late.
- A plan without defined authority leads to arguments when fast decisions are needed.
- Storing the only copy on systems an incident could take down makes it useless.
- The IRP, BCP and DRP must be aligned; a ransomware attack can trigger all three.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The incident life cycle
What the plan contains
1 / 9