Incident Response Planning: Preparation, Identification, Containment, Eradication, Recovery, and Post-Incident Analysis

Imagine you are the manager of a busy bank. One quiet Tuesday morning, a teller calls you over and whispers that something strange is happening with the vault. The alarm did not go off. The cameras show nothing unusual. But some cash is missing, and a door that should be locked is slightly open. What do you do? If you have never thought about this moment before, you will panic. You will make decisions based on fear rather than knowledge. You might accidentally destroy the fingerprints on that door by touching it. You might call the wrong person first. You might fail to lock down the building before the thief escapes. Everything you do in those first minutes could make the situation much worse. Now imagine you had spent the last six months preparing for exactly this kind of moment. You have a written plan. You know who to call. Your team has practised what to do. You know which doors to lock, which cameras to check, and how to protect the evidence. Suddenly, the same terrifying situation becomes something you can handle. You move with purpose instead of panic. This is the heart of incident response planning in cybersecurity. The word "incident" here means any unexpected event that harms, or threatens to harm, a computer system, network, or the information stored inside it. An incident could be a single employee accidentally clicking a dangerous link in an email. It could be a criminal stealing thousands of customer passwords. It could be a ransomware attack, where criminals use harmful software to lock all of an organisation's files and demand money to unlock them. These events happen to organisations of all sizes, in every industry, every single day. The most important idea in modern cybersecurity is this: it is not a matter of if your organisation will face a security incident, but when. Experts and security professionals around the world agree on this point. No system is perfectly safe. No wall is perfectly high. The question is never "will we be attacked?" The question is "will we be ready when it happens?" To answer that question well, organisations use something called an Incident Response Plan, or IRP. This is a carefully written document that explains what to do before, during, and after a security incident. The most trusted and widely used guide for building such a plan comes from a United States government organisation called the National Institute of Standards and Technology, or NIST. Their guide, known as Special Publication 800-61, describes a six-phase approach to handling incidents. These six phases are Preparation, Identification, Containment, Eradication, Recovery, and Post-Incident Analysis. Think of them as the six chapters of a story that begins long before any attack happens and ends with the organisation becoming stronger because of what it experienced. Let us walk through each chapter together, using stories and examples to make them real. The first phase is Preparation, and it is the most important chapter of all, even though nothing dramatic is happening yet. Preparation happens before any incident occurs. It is the quiet, unglamorous work of getting ready for a fire before a single spark appears. Think of it like the work of a fire station. Firefighters do not wait for a fire to happen and then decide to buy hoses. They spend most of their time training, testing equipment, studying maps of buildings, and running drills. All of that invisible work is what makes them effective when the alarm finally sounds. In cybersecurity, preparation means several things happening at the same time. First, an organisation needs to form a team of people whose job it is to respond to incidents. This team is called a Computer Security Incident Response Team, or CSIRT. A CSIRT is not just made up of technical experts who understand computers. It also includes people who handle communication, such as public relations specialists who can speak to the media and customers. It includes legal advisors who understand the laws about data breaches in the country where the organisation operates. It includes senior managers who can make fast, important decisions. Every member of this team needs to know their specific role before any incident happens. This is crucial because during a real incident, there is no time to figure out who is supposed to be doing what. Second, preparation means acquiring and setting up the right tools. One of the most important tools is called a Security Information and Event Management system, or SIEM. Think of a SIEM as a very sophisticated listening device that sits at the heart of your computer network. Your network produces thousands of small log entries every minute, records of who logged in, which files were opened, which websites were visited, and so on. A SIEM collects all of these records from every corner of the network and analyses them automatically, looking for patterns that suggest something is wrong. Without a SIEM, finding a security threat in a large organisation's network is like trying to find one suspicious conversation in a stadium full of people, all talking at once. With a SIEM, you have something helping you listen for the right words. Third, preparation means establishing what is called a baseline. A baseline is a clear picture of what normal looks like on your network. How much data typically travels in and out of the network in an hour? Which servers are usually busy and which are usually quiet? Which accounts log in at unusual hours? You cannot recognise something as abnormal unless you first understand what normal looks like. A doctor cannot tell if your heart rate is dangerously high unless they know what a healthy heart rate is. In the same way, a security analyst cannot tell if something strange is happening on the network unless they have studied what ordinary activity looks like. Fourth, and perhaps most importantly, preparation means testing the plan. An untested plan is little more than a document sitting in a drawer. Organisations use something called tabletop exercises to test their plans without the cost and disruption of a real incident. In a tabletop exercise, the CSIRT team gathers in a room. A facilitator, meaning the person leading the session, describes a fictional attack scenario step by step. The team talks through what they would do at each stage. This sounds simple, but it almost always reveals important gaps in the plan that nobody had noticed before. Here is a real example of why this matters. A hospital in the United States formed a CSIRT and wrote a detailed response plan. They then ran a tabletop exercise based on a scenario where ransomware had locked all their patient record systems. As they walked through the plan, they discovered a serious problem. Their communication plan depended entirely on the internal email system and the internal phone network. But their scenario assumed that both of those systems were down, encrypted by the ransomware. Suddenly, the team had no way to contact each other. They had no backup. The plan they had spent months writing was useless in the exact moment they needed it most. Because they found this during a drill rather than a real attack, they were able to fix it. They set up a third-party encrypted messaging application on personal devices, ensuring they could always communicate even if every internal system was down. That one discovery, made during a quiet training exercise, could one day save the hospital from complete chaos during a real attack. The second phase is Identification. If Preparation is the quiet work of building a fire station, Identification is the moment someone sees smoke and has to decide whether it is a real fire or just someone cooking dinner nearby. This phase is about detecting unusual events and deciding whether they represent genuine security incidents. The challenge of identification is enormous. A large organisation's security tools generate thousands, sometimes millions, of alerts every single day. The vast majority of these alerts are what security professionals call false positives. A false positive is an alert that looks like a threat but is actually harmless. Imagine a smoke detector that goes off every time you make toast. Eventually, you start ignoring it. This is called alert fatigue, and it is a real danger in cybersecurity. When analysts are overwhelmed with false alarms, they may miss the one real alarm buried among them. Good identification requires analysts to look not just at individual alerts but at patterns. A single unusual login might mean nothing. But if that same account also accessed files it has never opened before, and then sent a large amount of data to an unknown external server, those three events together tell a very different story. This process of connecting separate events to build a fuller picture is called correlation. Consider the story of a financial services firm. Their SIEM generates an alert showing that a large amount of data has been transferred from a server that normally only handles internal processing. An analyst investigates. They discover that an administrator account, which should only ever be used during business hours from inside the office, is active at three in the morning from an IP address, which is a unique numerical label identifying a computer on the internet, located in another country entirely. The analyst then finds another alert showing malware, meaning harmful software, on that same server. These three pieces of information together, the late-night login, the foreign IP address, and the malware alert, paint a clear picture. This is not toast setting off the smoke detector. This is a real fire. At this point, the analyst formally declares an incident. This declaration is important. It is the moment the IRP is officially activated. Everyone on the CSIRT knows their role. The clock starts. And crucially, meticulous documentation begins. Every single action taken, every observation made, every piece of evidence found must be recorded with a timestamp. This record serves two purposes. First, it helps the team keep track of a rapidly changing situation. Second, it preserves evidence in a way that can be used in court if legal action is eventually taken against the attacker. Maintaining this careful record is sometimes called preserving the chain of custody, meaning the unbroken record of who had control of the evidence at every moment. The third phase is Containment, and if identification is spotting the fire, containment is closing all the doors and windows to stop it from spreading to the rest of the building. Speed is essential here, but so is care. Containment happens in two steps. The first is short-term containment, meaning immediate actions to stop the attack from getting worse right now. This might mean physically disconnecting an infected computer from the network. It might mean disabling a compromised user account, so the attacker can no longer use it to move around the system. It might mean blocking a malicious IP address at the firewall, which is a security barrier between a network and the outside internet, so no data can travel to or from that location. The second step is long-term containment, which focuses on keeping the organisation running while the damaged systems are being dealt with. If a critical server has been infected, a backup server might be brought online to take over its functions, so the business does not grind to a halt while the team investigates. There is an important and fascinating debate within the security community about one aspect of containment. Should you always isolate a compromised system immediately? Most of the time, yes. But some experts argue that in very sophisticated attacks, particularly from highly skilled criminal groups or even from groups connected to foreign governments, there may be value in watching the attacker for a period before acting. If you immediately cut off the attacker's access, they know you have found them. But if you carefully monitor them in a controlled environment called a honeypot, which is a fake system set up to attract attackers while you observe them, you can learn exactly which tools they are using, which parts of your system they are targeting, and what their ultimate goal might be. This knowledge can be used to build much stronger defences. However, this approach carries enormous risk. You are deliberately allowing a hostile actor to remain inside your systems. If your team loses control of that situation even briefly, the consequences could be catastrophic. This is a decision that requires very senior leadership approval and expert execution. Most organisations, especially smaller ones without dedicated security teams, should focus on containing and removing the threat as quickly as possible. Alongside short-term and long-term containment, the team should also create what is called a forensic image of the affected systems. A forensic image is a precise, complete copy of everything on a computer's storage, every file, every hidden file, every deleted file, every piece of temporary data. It is a snapshot of the system exactly as it was at the moment of the incident. Creating this image means the team can investigate what happened on the system in detail, without risking accidental changes to the original, which could destroy evidence. The fourth phase is Eradication. Think of this as finding and removing every ember after you have contained the fire. It is not enough to stop the flames. You have to make sure there is no smouldering wood anywhere that could reignite hours later. Eradication means finding every single piece of the attacker's presence in your systems and removing it completely. This is harder than it sounds. Modern malware is designed to hide. It can disguise itself as a legitimate system file. It can install small hidden programs called backdoors, which are secret entry points that allow the attacker to return to the system even after the initial breach has been discovered and supposedly cleaned up. Some malware spreads itself to dozens of other systems before it is detected. Eradicating the threat requires deep forensic analysis, meaning a detailed technical investigation of every affected system. Once the malware is removed, the team must address how the attacker got in in the first place. This entry point is called the attack vector. The most common attack vectors include unpatched software vulnerabilities (meaning gaps in software code that criminals can exploit, which the software manufacturer may have already released a fix for but the organisation has not yet applied), weak or stolen passwords, and employees being tricked into clicking malicious links in emails, a technique called phishing. Whatever the entry point was, it must be closed before the system is restored to operation. In the case of our financial firm, the team discovered that the attacker had entered through a known vulnerability in the web application software running on the server. A web application is a program that runs through a web browser. The software manufacturer had actually released a security patch, which is an update that fixes the vulnerability, two months earlier. But the firm had not yet applied it. After removing the malware, the team applied the patch. They also decided the server itself was too compromised to trust. Even if they thought they had removed everything, what if they missed something? So they wiped the server completely and rebuilt it from scratch using what is called a gold image, a clean, trusted, pre-configured version of the system that the team maintains specifically for situations like this. The fifth phase is Recovery. Eradication removes the threat. Recovery is about carefully, cautiously, returning everything to normal working order. The key word here is carefully. It would be tempting, after all the stress of an incident, to restore systems as quickly as possible and return to normal business operations. But speed here is dangerous. If any trace of the threat survived eradication, rushing the recovery could spread it again. The organisation could end up back at the beginning. Recovery typically begins with restoring data from clean backups. A backup is a copy of data saved at a specific point in time, before the attack occurred. The team needs to be certain the backup was made before the attack happened and that the backup itself is clean. They restore the data to the rebuilt system and then test everything carefully. Does the system work correctly? Does the data look intact? Are there any signs of remaining malicious activity? Crucially, recovered systems are not immediately returned to full operation. They are kept in a monitored, isolated network segment, meaning a separate, controlled part of the network, for a period of heightened observation. The security team watches these systems very closely for any signs of unusual activity. Only when they are confident the systems are clean are they returned to the main production network, the network that the whole organisation uses for its daily work. Communication is also an important part of recovery. Employees, customers, and sometimes regulators need to know what has happened and what is being done about it. Many countries have laws that require organisations to notify customers within a certain period if their personal data has been exposed in a breach. Being transparent and clear in communication, without causing unnecessary panic, is a skill that the communications members of the CSIRT are specifically trained for. The sixth and final phase is Post-Incident Analysis, sometimes called the post-mortem. This is the phase that separates organisations that keep getting hit by the same types of attacks from those that genuinely improve. It is the moment after the fire when you sit down and ask not just "how do we repair the damage?" but "how did this fire start, and how do we make sure it never happens again?" The centrepiece of this phase is a lessons-learned meeting. This is a formal gathering of the entire CSIRT and key stakeholders. The goal is to review every aspect of the incident and the response. What happened first? When did we detect it? How long did it take us to contain it? What mistakes did we make? What did we do well? There is one cultural principle that is absolutely essential for this meeting to be productive. It must be blameless. The word blameless here means the meeting must focus entirely on improving processes and systems, not on punishing or shaming individual people. If an analyst knows they will be criticised or humiliated for a mistake they made during the incident, they will hide that mistake or minimize it. Important information that the team needs in order to improve will be lost. But if people feel safe to be honest, saying "I made this mistake because the process was unclear" or "I missed this alert because our SIEM was poorly configured," then the team can actually fix the underlying problems. The meeting produces a final incident report, a comprehensive document recording the full timeline of the incident, the financial and operational damage it caused, everything that worked well, everything that did not, and a set of specific recommendations for improvement. In the case of the financial firm, the post-mortem meeting revealed something uncomfortable but vital. The root cause of the entire incident was a failure in the firm's patch management process. Patch management means the regular, systematic process of applying security updates to software. The critical vulnerability that the attacker had exploited had been known for two months. A patch had been available. The firm simply had not applied it in time. Their process required critical patches to be applied within thirty days, but this one had slipped through. As a direct result of the post-mortem, the firm changed its policy. Critical vulnerabilities must now be patched within seventy-two hours. They also invested in a new automated tool that constantly scans their systems for known vulnerabilities and reports them immediately to the security team, so nothing can be missed. This is the most important lesson of the entire incident response lifecycle. The final phase feeds back into the first. Every incident, no matter how damaging it was, contains information that makes you better prepared for the next one. The cycle never ends, because the threats never end. But each time you go around the cycle, you arrive at Preparation a little wiser, a little better equipped, and a little harder to attack. There is one more thing worth discussing, and it concerns the nature of the model itself. The six phases are presented here as a neat sequence, one following logically after another. In the real world, incidents rarely cooperate with neat sequences. A team might be deep in the Eradication phase, removing malware from several servers, when an analyst suddenly discovers a seventh server that was also compromised. Now the team must go back to Identification to understand what happened on that server, then back to Containment to isolate it, then return to Eradication. Real incidents are dynamic, messy, and frequently surprising. Experienced security teams treat the six phases not as a strict sequence of steps but as a set of tools they can use in whatever order the situation demands. The value of the framework is not its rigidity but its completeness. By understanding all six phases deeply, a team can improvise intelligently, always knowing what needs to be accomplished, even when the path to accomplishing it takes unexpected turns. To bring everything together, let us briefly revisit the key ideas covered in this lesson. Incident response planning is based on the understanding that security incidents are inevitable, and that preparation before an incident determines how effectively and quickly an organisation can recover from one. The NIST six-phase framework provides a complete structure for handling incidents. Preparation builds the team, the tools, the plan, and the knowledge of what normal looks like before anything goes wrong. Identification is the work of detecting events, correlating information, and deciding with confidence whether a real incident has occurred. Containment stops the attack from spreading, using both immediate actions and longer-term measures to protect the organisation while the response continues. Eradication removes every trace of the threat and closes the entry point the attacker used. Recovery carefully restores systems to normal operation, with close monitoring to confirm the threat is truly gone. And Post-Incident Analysis is the reflective phase where the organisation honestly reviews what happened, learns from it, and makes specific improvements to prevent or better handle the next incident. Throughout the entire process, careful documentation is essential, teamwork across technical and non-technical roles is necessary, and a culture of honest, blameless learning is what transforms a damaging event into genuine progress. The organisations that handle cyber incidents best are not necessarily those with the most money or the most powerful technology. They are the ones that treat preparation as a permanent and serious commitment, and learning as a process that never stops.