Exam Objective 4.1 asks you to establish and maintain an incident response plan. This is the playbook that tells an organisation exactly what to do when something goes wrong — a data breach, a ransomware attack, a system failure — so that the damage is contained, evidence is preserved, and the business can keep running. As a future information security manager, you are not expected to write code or configure firewalls, but you must know how to build a plan that guides technical teams through chaos.
Jump to a section
A simple way to picture Incident Management and Response Planning
A busy restaurant kitchen has a pre-written plan for a grease fire. The plan is not a single document, but a set of protocols: who pulls the fire alarm, who grabs the Class K extinguisher, who evacuates the dining room, and who calls the fire department. The head chef is the incident manager, but every station has a specific role.
When the fire starts (the incident), the first cook who sees it shouts 'Fire!' — this is detection. Without a rehearsed plan, each cook would improvise: one might throw water (making the fire worse), another might try to lift the burning pan (spreading flames), and the hostess might evacuate customers through the kitchen door (into the fire). With a plan, the team works in parallel: the extinguisher is deployed, the gas line is shut off (containment), and the fire department is already en route.
After the fire is out, the team does not just clean up. They hold a debrief: why did the grease ignite? Was the hood exhaust clogged? Did a new cook not know the procedure? They update the plan to install automatic shut-off valves and schedule monthly drills. This cycle of preparation, detection, containment, recovery, and improvement is exactly how organisations manage cyber incidents — from a harmless login alert to a full ransomware attack that paralyses an entire business.
An 'incident' in information security is any event that threatens the confidentiality, integrity, or availability of information. Confidentiality means keeping data private — only the right people can see it. Integrity means data is accurate and has not been tampered with. Availability means systems and data are accessible when needed. When any of these three is threatened or actually harmed, you have a security incident.
'Incident response' is the structured approach to handling such incidents. It is not a panic-driven scramble; it is a set of repeatable steps that an organisation follows every time. The document that defines these steps is the 'incident response plan' (IRP). The IRP is the playbook for the security team, the legal department, public relations, and senior leadership. It answers questions like: who is on the incident response team? What communication channels do they use? When do we shut down a compromised server versus leave it running for forensic evidence? How do we notify customers whose data may have been exposed?
Why does an organisation need a formal plan instead of just 'being careful'? Because without a plan, human psychology takes over. People freeze. They try to hide the problem. They delete logs by accident. They make decisions that help in the short term but hurt in the long term — like paying a ransomware demand without first assessing whether backups can restore the data. A plan turns a chaotic emergency into a process.
Every incident response plan follows a lifecycle. The most common model has four phases:
Preparation: This is the 'before the bad thing happens' phase. You train staff, buy tools (like malware analysis sandboxes or disk imaging software), establish communication lines (email trees, encrypted messaging), and run tabletop exercises — which are like fire drills for cyber incidents. Without preparation, the rest of the plan is useless.
Detection and Analysis: The organisation must be able to notice that something is wrong. This happens through monitoring tools that flag unusual activity — a user logging in from a foreign country ten minutes after logging in from the office, or a server sending gigabytes of data to an unknown IP address. The analysis step confirms whether the event is truly malicious or just a false alarm (e.g., a legitimate software update that looked suspicious).
Containment, Eradication, and Recovery: Once an incident is confirmed, the goal is to stop it from getting worse. Containment might mean disconnecting a server from the network, blocking a malicious IP address at the firewall, or resetting every user's password. Eradication means removing the root cause — deleting the malware, patching the vulnerability, or closing the backdoor. Recovery is the slow, careful process of bringing systems back online, often from clean backups, and verifying that no trace of the attacker remains.
Post-Incident Activity: After the fire is out, the team does a 'lessons learned' review. What worked? What did not? What evidence was lost? The plan is updated based on these findings. This is also when legal and regulatory obligations kick in — for example, notifying affected customers within 72 hours under GDPR.
A critical concept in incident response is the 'chain of custody'. If an incident leads to a lawsuit or regulatory fine, the organisation must be able to prove that the digital evidence (logs, disk images, network captures) was collected, handled, and stored in a way that preserved its integrity. Any break in the chain — like a file that was copied onto a non-forensically-clean USB drive — can make the evidence inadmissible in court.
CISM exam questions often test whether you understand that the plan must be maintained, not just created. An IRP that sits in a binder and is never updated or practised is not a plan — it is a security blanket. The organisation must review the plan after every incident, at least annually, and whenever the IT environment changes significantly (e.g., migrating to the cloud, adopting new software). The plan itself must be stored in a location that is accessible even when the main systems are down — you cannot rely on a company wiki that goes offline during a ransomware attack.
Another key point: the incident response plan is not just for the IT department. It involves human resources (for employee misconduct), legal counsel (for liability and notification requirements), public relations (for managing the media narrative), and executive leadership (for approving major decisions like paying a ransom or shutting down operations). The CISM exam will test your ability to identify who should be on the incident response team and when each stakeholder should be included.
Preparation
Before any incident occurs, the organisation builds the foundation. This includes forming the incident response team, assigning roles, acquiring necessary tools (forensic software, communication platforms), drafting the incident response plan document, and running tabletop exercises where the team walks through a fake scenario. Without this step, every other phase is impossible.
Detection and Analysis
The organisation identifies a potential incident. Detection happens via monitoring tools (e.g., security information and event management systems, or SIEM), user reports, or automated alerts. Analysis is the process of triaging the alert to confirm that it is a genuine security incident and not a false alarm. During this step, the incident handler assigns a severity level (e.g., low/medium/critical) and decides whether to activate the full incident response team.
Containment
The immediate goal is to stop the incident from spreading or causing more harm. This might involve isolating a compromised server from the network, blocking a malicious IP address, or resetting compromised user accounts. The containment strategy is chosen based on the type of incident: for ransomware, you might disconnect the infected machine; for a data exfiltration, you may block outbound traffic. The plan should have pre-defined containment strategies for common incident types.
Eradication
Once the incident is contained, the team removes the root cause. This means deleting malware, closing the vulnerability that was exploited, disabling compromised accounts, and removing any unauthorised changes made by the attacker. Eradication must be thorough — if any remnant of the attack is left behind (like a hidden backdoor user account), the attacker can come back.
Recovery
The affected systems are brought back into normal operation. This typically involves restoring data from clean backups, reinstalling operating systems, and applying security patches. Recovery must be done carefully: systems are often brought back one at a time and monitored closely for signs that the attacker has returned. After recovery, normal business operations resume.
Post-Incident Activity
After the incident is fully resolved, the team conducts a structured review called 'lessons learned'. They answer: what went well? What went wrong? What evidence was lost? The incident response plan is updated with improvements. This is also when legal and regulatory notifications are finalised (if not already done). Without this step, the same mistakes can happen in the next incident.
Consider a mid-sized e-commerce company called 'ShopStream' that sells streaming audio equipment. They have an IT team of ten people, a CISO (Chief Information Security Officer), and about 200 employees. One Tuesday morning, the helpdesk receives a flood of reports from customers saying their accounts have been used to purchase thousands of dollars in gift cards they did not authorise. At the same time, the security monitoring tool alerts on an unusual amount of data being transferred from the customer database server to an IP address in Eastern Europe.
The helpdesk follows the 'first response' step in the incident response plan. They do not ignore the reports or try to fix it themselves. Instead, they open a ticket as a 'high-severity security incident' and immediately notify the security team via the designated encrypted chat channel. The incident response plan specifies that within the first 15 minutes, a lead incident handler must be assigned. The CISO is on holiday, so the backup incident handler — the senior security analyst — takes charge.
The incident handler activates the incident response team. The team includes:
A 'forensics lead' who will begin preserving server memory and logs.
A 'network lead' who will block the suspicious IP at the firewall and isolate the affected server.
A 'communications lead' from the legal department who will draft a holding statement for customers.
A 'systems lead' from IT who will work on restoring services from clean backups.
Each person checks their specific checklist in the incident response plan. The forensics lead uses a tool called a 'forensic acquisition tool' to make a bit-by-bit copy of the database server's hard drive — this preserves the evidence without altering the original. The network lead uses the firewall management console to create a rule that blocks all traffic from the attacker's IP address. They also apply a 'containment rule' that blocks all outbound data from the affected server except to a specific forensic analysis machine.
The detection phase reveals that the attacker gained access through a phishing email sent to a customer support agent three days ago. The agent clicked a link that installed a 'remote access Trojan' (RAT) — a type of malware that lets the attacker control the agent's computer. From there, the attacker moved laterally across the network to the database server using stolen administrative credentials that were stored in a plain-text file on the agent's desktop (a terrible security practise).
During containment, the incident handler decides not to disconnect the database server immediately because shutting it down would destroy volatile evidence in memory that could show exactly what data was stolen. Instead, they use a network 'kill switch' — a pre-configured firewall rule — to block all traffic to and from the server while keeping it powered on. This is a decision that was practised during a tabletop exercise three months ago. The team already knew the balancing act between preserving evidence and stopping data loss.
Eradication involves removing the RAT from the agent's computer and all other systems the attacker touched. The team resets all 4000 customer passwords globally (a painful but necessary step). They apply a security patch to the phishing software that prevented the original attack. The recovery process restores the database server from a backup taken before the compromise, but only after a full malware scan of the backup to ensure the attacker is not lurking inside it.
In the post-incident phase, the team holds a formal 'lessons learned' meeting. They discover that the incident response plan did not include a clear process for notifying affected customers within GDPR's 72-hour window — a gap that is immediately added. They also realise the authentication system did not require multi-factor authentication (MFA) for administrative accounts, so MFA is rolled out to all employees within two weeks. The updated plan is approved by the CISO and stored both in the cloud (with encryption) and on a printed copy in a safe that does not require network access to open.
The CISM exam tests 'Incident Management and Response Planning' (Domain 4) heavily — expect around 24% of exam questions to come from this domain. The questions are scenario-based: you are given a short description of an incident and asked what the security manager should do next. The correct answer nearly always follows the incident response lifecycle in order. Traps are set to test whether you skip phases or confuse roles.
Specific concepts the exam loves to test:
The difference between an 'event' and an 'incident': An event is any observable occurrence in a system (e.g., a user logs in, a server reboots). An incident is an event that violates security policy or threatens the three security goals. The exam will present a scenario where a system administrator notices a log entry showing a failed login attempt (an event) and ask when it becomes an incident — the answer is when it indicates actual or probable harm.
The order of the incident response phases: Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity. A common trap question asks: 'After an incident is contained, what should the team do next?' The wrong answers might say 'immediately restore systems' or 'notify the public'. The correct answer is 'conduct forensic analysis' (part of containment/eradication) or 'review lessons learned' (post-incident).
Notification requirements: The exam expects you to know that legal and regulatory obligations dictate when and how to notify affected parties (customers, regulators, law enforcement). Under GDPR, notification to the supervisory authority must happen within 72 hours of becoming aware of a breach. The exam might ask who is responsible for making that notification — the answer is usually the data protection officer (DPO) or the security manager, not the IT technician.
The role of the incident response team: The team includes technical roles (forensics analyst, network engineer) and non-technical roles (legal counsel, PR manager). The exam tests whether you know that the CISO or an incident manager leads the team, and that communications with external parties (media, regulators) should be channelled through one designated person.
Evidence preservation (chain of custody): Questions will describe a scenario where a technician wants to analyse a compromised laptop by booting it up and poking around. The correct answer is that you must first create a forensic image (bit-for-bit copy) of the hard drive and work from the copy, not the original. Any action that alters the original evidence is wrong.
Common trap patterns:
Trap: 'The incident is over. What is the most important next step?' Wrong answers often say 'celebrate' or 'bill the customer'. The correct answer is 'perform a lessons learned review and update the incident response plan'.
Trap: 'The attacker is still active in the network. What should the manager do first?' Wrong answers say 'start notifying customers' or 'pull the plug on all servers'. The correct answer is 'contain the incident to prevent further damage while preserving evidence'.
Trap: 'The incident response plan is outdated. What should management do?' Wrong answers suggest 'ignore it' or 'wait for the next incident to rewrite it'. The correct answer is 'review and update the plan at least annually and after significant changes'.
Key definitions to memorise:
'Incident response plan': The documented, tested set of procedures for handling security incidents.
'Tabletop exercise': A walkthrough of an incident scenario with key stakeholders to test the plan.
'Forensic image': A bit-for-bit copy of a storage device used for evidence analysis.
'Lessons learned': The post-incident review process that identifies improvements to the plan.
'Containment strategy': The specific approach used to stop an incident from spreading (e.g., isolation, network segmentation, account suspension).
'Eradication': The step of removing the root cause of an incident from all affected systems.
The exam also tests the difference between 'incident response' and 'disaster recovery'. Incident response handles the immediate security threat (like a hacker). Disaster recovery handles the restoration of systems after a major event (like a fire in the data centre). Do not confuse them: disaster recovery is the broader process of getting the business back to normal, while incident response is specifically about managing the security breach itself.
An incident response plan must be a living document that is tested and updated regularly, not a one-time write-and-file exercise.
Every incident must follow the four-phase lifecycle: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity — never skip a phase.
The chain of custody for digital evidence must be preserved from the moment an incident is detected to maintain admissibility in legal proceedings.
Incident response is a cross-functional effort involving IT, legal, HR, PR, and executive leadership — not just the security team.
Containment is always prioritised over eradication or recovery because stopping the spread of damage limits overall harm.
After an incident, the most critical step is a 'lessons learned' review that leads to specific improvements in the incident response plan.
An event becomes an incident only when it threatens the confidentiality, integrity, or availability of information — not every abnormal log entry is an incident.
Forensic analysis must be performed on a bit-for-bit copy of the original data, not the live system, to avoid altering evidence.
These come up on the exam all the time. Here's how to tell them apart.
Event
Any observable occurrence in a system (e.g., a user logging in, a server reboot).
Does not necessarily violate security policy or cause harm.
Requires logging but no immediate escalation unless it meets incident criteria.
Incident
An event that actually threatens confidentiality, integrity, or availability.
Always violates security policy or causes harm (or has high probability of harm).
Triggers the incident response process and requires immediate action.
Incident Response Plan
Focuses on managing a security breach (hacker, malware, insider threat).
Phases: Detection, Containment, Eradication, Recovery, Lessons Learned.
Typically shorter time frame — hours to days.
Disaster Recovery Plan
Focuses on restoring operations after a major disruptive event (natural disaster, power outage, building fire).
Phases: Assess damage, restore infrastructure, switch to alternate site, resume operations.
Time frame ranges from days to weeks or months.
Tabletop Exercise
Discussion-based; no actual systems are touched.
Participants talk through a scenario and make decisions verbally.
Lower cost and lower risk; ideal for testing decision-making and communication.
Live Simulation Exercise
Hands-on; actual systems may be attacked in a safe, controlled environment.
Tests technical response capabilities (e.g., blocking an IP, restoring from backup).
More expensive and riskier but provides realistic testing of technical skills.
Containment
First priority after confirming an incident.
Goal is to stop the incident from spreading (e.g., isolate server, block IP).
Temporary measure — does not remove the root cause.
Eradication
Happens after containment is achieved.
Goal is to remove the root cause (e.g., delete malware, patch vulnerability, disable compromised accounts).
Permanent measure — if done poorly, the attacker can return.
Forensic Image
Bit-for-bit copy of entire storage device, including free space and deleted files.
Created for evidence preservation; chain of custody is documented.
Used once for analysis and then stored securely as evidence.
Regular Backup
Copy of working data, does not include free space or deleted files.
Created for operational recovery; chain of custody is not typically documented.
Restored multiple times for recovery; not treated as legal evidence.
Mistake
An incident response plan only matters for large companies with big security budgets.
Correct
Every organisation that stores any digital data — even a small charity with ten employees — benefits from an incident response plan. The plan can be simple: who to call, how to disconnect from the internet, which backup to restore. Without it, a single ransomware attack can destroy a small business completely.
Beginners often think cyber attacks only target 'big fish'. In reality, small businesses are frequently targeted because they lack defences. The misconception comes from news stories that only cover large breaches.
Mistake
Once the incident is over, the plan is done and can be filed away until next time.
Correct
The plan must be updated after every incident and at least annually. Cyber threats evolve, technology changes (new software, cloud migrations), and team members come and go. An old plan is nearly as dangerous as no plan.
People view plans as static documents. But in IT, threat actors change tactics constantly — the plan must evolve to address new attack vectors like deepfake social engineering or zero-day exploits.
Mistake
If you have good security software (antivirus, firewall), you do not need an incident response plan.
Correct
Security software reduces the likelihood of an incident but cannot prevent every attack. Sophisticated attackers bypass antivirus using novel malware. A plan ensures the human team acts correctly when software fails.
Security tool vendors market their products as comprehensive solutions. Beginners assume a product can solve all problems, not understanding that people and processes are equally important.
Mistake
The IT department should handle the entire incident response alone without involving management or legal.
Correct
Incident response requires cross-functional input: legal for regulatory notifications, PR for customer communication, HR for employee-related issues (if an insider is responsible), and executive leadership for major decisions (like paying a ransom or shutting down operations). The IT team handles technical containment but does not make these broader decisions independently.
Beginners from non-business backgrounds often think 'security' is purely a technical domain. They do not realise the legal and reputational risks that require non-technical expertise.
Mistake
If you have a backup, you can just restore everything and the incident is handled.
Correct
Restoring from backup is part of recovery, but it must happen after containment and eradication. You must first ensure the attacker is no longer present in the environment, or the restored backup will be re-infected immediately. Also, you must verify that the backup itself is not compromised. Incident response is a sequence; skipping steps causes failure.
Backups are often presented as a silver bullet in general tech advice. Beginners do not understand the concept of 'persistence' — attackers can hide dormant malware inside backups.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An event is any observable occurrence in a computer or network — like a user logging in or a system reboot. An incident is an event that actually threatens the security of information (confidentiality, integrity, or availability). All incidents are events, but not all events are incidents.
The CISM best practice is to review and update the plan at least once per year and after every significant incident or major change to the IT environment (like moving to a new cloud provider). The plan is required to be a living document.
The team should include technical roles like a forensics analyst and network engineer, plus non-technical roles including legal counsel, public relations, human resources (if an employee is involved), and a senior executive (like the CISO) who can make high-level decisions. The exact composition depends on the incident type.
A tabletop exercise is a discussion-based session where the incident response team walks through a fictional incident scenario to practise their roles and test the plan. No systems are actually attacked — it is like a fire drill for cyber incidents. It reveals gaps in the plan before a real incident occurs.
The timing depends on applicable laws such as GDPR (which requires notification within 72 hours of becoming aware of the breach) or local data breach notification laws. The incident response plan should list all relevant regulations and include a template notification letter that can be customised quickly.
You must create a forensic image (a bit-for-bit copy) of the hard drive and work from that copy. Using the original machine can alter data — for example, the operating system writes temporary files during boot-up — which could destroy evidence and make it inadmissible in court.
The first step is containment — isolate the affected system from the network to stop the ransomware from spreading to other devices. Do not pay the ransom immediately, and do not shut down the system (which could destroy evidence). Then, follow the incident response plan: detect the scope, preserve evidence, and begin eradication.
You've finished Incident Management and Response Planning. Continue through the CISM study guide to build a complete picture of the exam.
Done with this chapter?