Incident Response Process. This is the playbook that cybersecurity teams follow when something bad happens — a hacker breaks in, a virus spreads, or a data leak is discovered. For the 200-201 exam, you need to know the five phases of the NIST-based lifecycle and why each matters for stopping an attack fast.
Jump to a section
A simple way to picture Incident Response Process
Have you ever wondered what happens in the first five minutes after a 999 call about a house fire?
The fire service doesn't just grab a hose and start spraying. They have a plan. First, they must detect and confirm the fire is real — a smoke alarm went off, a neighbour called. Then they mobilise: the truck rolls, the crew suits up. On arrival, they don’t charge in blind. They assess: which room is burning, are people trapped, is the gas turned off? They contain the fire by closing doors and isolating the source. They eradicate the flames. Finally, they conduct a hot wash — they analyse what went wrong, what worked, and how to prevent the next fire.
This method is exactly how cybersecurity teams handle a breach. They cannot panic. They follow a standardised incident response process: detect, assess, contain, eradicate, and learn. The plan stops them from making the fire worse — and that’s what the 200-201 exam expects you to understand.
The incident response process is a structured, step-by-step approach that organisations use to handle security incidents. An “incident” is any event that violates a security policy or puts data at risk — like a ransomware infection, a stolen password, or a denial-of-service attack. Without a process, teams would react randomly, miss crucial evidence, and potentially make the situation worse.
The most widely adopted framework comes from NIST (the National Institute of Standards and Technology). It breaks down into four major phases, though many sources, including Cisco, add a fifth: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity (lessons learned).
Let’s walk through each phase in plain language.
Preparation is the setup before any incident happens. You create a security policy, form an incident response team (CSIRT — Computer Security Incident Response Team), buy tools (like firewalls and antivirus software), and practise drills. The 200-201 exam tests whether you know that preparation makes every other phase faster and more effective.
Detection and Analysis is where you discover something is wrong. This could come from an alert on a security tool — for example, a SIEM (Security Information and Event Management) system flags unusual login attempts from a foreign country. The analyst must validate the alert as a true positive (real threat) or a false positive (benign activity). Analysis involves gathering evidence — logs, network traffic, system files — to understand what happened. For the exam, remember the difference between an “event” (any observable occurrence) and an “incident” (an event that negatively affects security).
Containment, Eradication, and Recovery are often grouped, but each has a distinct goal. Containment stops the threat from spreading — for instance, disconnecting a compromised server from the network. Eradication removes the cause — deleting malicious files, patching the vulnerability, resetting stolen passwords. Recovery brings the system back to normal operation — restoring from clean backups, monitoring for re-infection. The exam likes to test which action belongs in which phase: containment is about limiting damage, not fixing it.
Post-Incident Activity (Lessons Learned) is the final phase. The team writes a report explaining the timeline, what worked, what didn’t, and how to prevent a repeat. This phase feeds back into preparation — the whole cycle improves over time.
Why does this process exist? Before standardised incident response, teams often panicked, deleted evidence, and never found the root cause. The process ensures consistency, legal defensibility, and continuous improvement. For the exam, you must also understand that the process is not always linear — you might go back to containment if you discover new evidence during eradication.
Key terms to know for 200-201:
Event: Any observable occurrence in a system or network (e.g., a user logging in).
Incident: A violation of security policy that requires action (e.g., a malware infection).
Alert: A notification from a tool that something may be an incident.
True positive: An alert that correctly identifies a real threat.
False positive: An alert that fires when nothing is wrong.
True negative: No alert when nothing is wrong.
False negative: No alert when a threat is present (the most dangerous scenario).
The 200-201 exam also expects you to know the NIST SP 800-61 revision 2 as the reference document. You don’t need to memorise its page numbers, but you must recognise it as the standard for incident handling.
Preparation
Before any incident, the team creates policies, forms the CSIRT, buys tools (SIEM, firewalls), trains staff, and runs drills. This phase determines how fast and effectively the rest of the process works.
Detection and Analysis
The team identifies potential incidents through alerts, user reports, or logs. They validate whether it’s a true positive or false positive, then analyse the scope and impact. This is where events become incidents.
Containment
The goal is to stop the incident from spreading or causing more damage. Short-term containment might involve disconnecting a network cable. Long-term containment applies temporary fixes like firewall rules until eradication is complete.
Eradication
The team removes the root cause of the incident: deleting malware, patching vulnerabilities, resetting compromised passwords, or rebuilding systems from clean sources. This phase ensures the threat is fully gone.
Recovery
Systems are restored to normal operation from clean backups. The team monitors for any signs of reinfection. Once confident, they bring systems fully back into production.
Post-Incident Activity (Lessons Learned)
The team documents the timeline, root cause, actions taken, and recommendations. This report is shared with management and used to update the incident response plan, completing the cycle back to preparation.
Imagine you work in the IT department of a medium-sized online retailer. One Tuesday morning, the SIEM console lights up with a critical alert: “Multiple failed logins from IP address 45.33.22.11 to the finance database server.” Here’s exactly what happens next.
Step 1 — Detection: The security analyst (you) sees the alert. You check the alert details: the source IP is from a country the company doesn’t do business with. The log shows 50 failed attempts in 10 minutes, then one successful login from the same IP. You declare this a potential incident and open a ticket in a system like ServiceNow or Jira.
Step 2 — Analysis: You pull the server’s authentication logs and network traffic records. You see that after the successful login, a data export tool copied 500 customer records to an external site. You confirm this is a data breach. You escalate to the incident commander (often a senior manager). The team classifies the incident as high severity because it involves customer PII (personal identifiable information).
Step 3 — Containment: The commander orders you to isolate the finance server from the network. You log into the network switch and shut down the port the server is connected to. You also change the password for the compromised account immediately. This stops the attacker from stealing more data.
Step 4 — Eradication: The team finds that the attacker exploited an unpatched vulnerability in the server’s web application. You apply the vendor’s security patch and run a full antivirus scan to remove any backdoors. You also review all other servers for the same vulnerability.
Step 5 — Recovery: You restore the finance server from a clean backup taken two days before the incident. You monitor its network traffic for 24 hours to ensure no attacker activity returns. Once verified, you reconnect it to the production network.
Step 6 — Lessons Learned: The team meets the next week. You document the timeline, the root cause (missing patch), and recommendations: automate patch management and enforce multi-factor authentication (MFA) on all database servers. The report is shared with management. The process then updates the incident response plan for next time.
Tools used in real-world response:
SIEM (e.g., Splunk, ArcSight, QRadar): collects logs and generates alerts.
EDR (Endpoint Detection and Response, e.g., CrowdStrike, SentinelOne): detects malware on computers and servers.
Forensic tools (e.g., FTK, EnCase): capture disk images for legal evidence.
Ticketing systems (e.g., ServiceNow, Jira, RTIR): track the incident lifecycle.
A key point for the exam: containment must be done before eradication. If you try to remove malware without first stopping it from spreading, you’ll just get reinfected.
The 200-201 exam tests your knowledge of the incident response lifecycle in multiple ways. Expect around 8–12 questions on this topic. They fall into three main categories: phase identification, sequence ordering, and definition matching.
Question Type 1 — Phase Identification: The exam gives you a scenario and asks which phase of incident response it describes. For example, “An analyst disconnects a compromised host from the network. Which phase is this?” The answer is “containment.” The trap: they might throw in phrases like “eradication” or “recovery” as distractors. Remember: containment stops the spread, eradication removes the cause, recovery brings back normal operations.
Question Type 2 — Sequence Ordering: You’ll be asked to put the phases in the correct order. The classic trap is to put “eradication” before “containment.” Always remember: contain first, then eradicate. Another trap: they might list “detection” after “preparation” but before “response” — that’s correct.
Question Type 3 — Definition Matching: You must know the difference between an event and an incident. The exam will ask: “Which of the following is an incident?” and the correct answer is the one that involves a security policy violation. A regular user login is an event; a login from a known malicious IP is an incident.
Key concepts they love to test:
Preparation: They ask which activities are part of preparation (e.g., creating playbooks, training staff). They might try to trap you with “installing a firewall” — that’s preparation.
Detection and Analysis: They test the difference between a true positive and a false positive. A common question: “An alert fires for malware, but analysis shows it was a safe update. What is this?” Answer: false positive.
Containment: They test short-term vs long-term containment. Short-term is immediate (disconnect the cable). Long-term is more permanent (apply a temporary firewall rule).
Recovery: They ask about restoring from backup and monitoring for reinfection.
Post-Incident: They ask what a “lessons learned” report includes (timeline, root cause, recommendations).
Trap patterns to watch for:
The exam might describe an action that sounds like containment but is actually eradication (e.g., “deleting malware” is eradication, not containment).
They may use the term “incident” when they mean “event” — read carefully.
They might include a phase like “identification” which is not standard in the NIST model (NIST uses “detection and analysis”).
Memory aid: “P.D.C.E.R.” — Preparation, Detection, Containment, Eradication, Recovery. Then add “Post-Incident.”
Standard to know: NIST SP 800-61 Revision 2. The exam will reference it. Remember that NIST also includes a “Coordination” activity that runs throughout all phases (sharing info with other teams or external organisations).
Finally, the exam expects you to know that the incident response lifecycle is cyclic, not linear — lessons learned feed back into preparation. This is one of their favourite higher-level questions.
The NIST incident response lifecycle consists of five phases: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident (Lessons Learned).
Containment must always happen before eradication to prevent the threat from spreading while you remove it.
An event is any observable occurrence; an incident is an event that violates a security policy and requires action.
The incident response process is iterative, not strictly linear — you may loop back to earlier phases as new evidence appears.
False positives (alerts that fire when nothing is wrong) waste time, but false negatives (no alert when a real threat is present) are far more dangerous.
NIST SP 800-61 Revision 2 is the standard reference document for incident handling — memorise its role, not its page numbers.
Lessons learned from post-incident activity feed directly into improving preparation for future incidents, creating a continuous improvement loop.
The CSIRT (Computer Security Incident Response Team) is the group responsible for executing the incident response process.
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., user login, file save)
Does not necessarily involve a security policy violation
Does not require a formal response
Incident
An event that violates a security policy (e.g., malware infection, data breach)
Always involves a security policy violation
Requires a formal incident response process
Containment
Stops the incident from spreading (e.g., disconnect host from network)
Performed first in the response order
Focuses on limiting damage, not removing cause
Eradication
Removes the root cause of the incident (e.g., delete malware, patch vulnerability)
Performed after containment
Focuses on completely eliminating the threat
True Positive
Alert correctly identifies a real threat
Requires immediate action
Example: alert that real ransomware is executing
False Positive
Alert fires when no real threat exists
Wastes analyst time and can lead to alert fatigue
Example: alert that a legitimate software update is malicious
Recovery
Restores systems to normal operation
Includes monitoring for reinfection
Involves restoring from clean backups
Lessons Learned
Documents the incident timeline and root cause
Produces a report with recommendations for improvement
Feeds back into the Preparation phase
Mistake
Containment and eradication are the same thing — both mean stopping the attack.
Correct
Containment stops the attack from spreading (like quarantining a patient). Eradication removes the root cause (like curing the disease). You must contain before you eradicate.
In everyday language, “contain” and “remove” feel similar. Beginners merge them because they happen in quick succession.
Mistake
An event and an incident are interchangeable terms.
Correct
An event is any observable occurrence (e.g., a user typing a password). An incident is an event that violates security policy and requires action. All incidents are events, but not all events are incidents.
English speakers use “event” and “incident” as synonyms. The technical distinction is subtle but tested directly.
Mistake
The incident response process is always linear — you finish one phase, then move to the next.
Correct
The process is often iterative. For example, during eradication you might discover new evidence and need to go back to containment or detection. NIST explicitly allows moving between phases.
Beginners learn best from linear lists (step 1, step 2...). Real incidents are messy, and exam questions exploit this by presenting a scenario where you loop back.
Mistake
Preparation only happens once at the beginning of an incident response career.
Correct
Preparation is continuous. You update playbooks, train new staff, and improve tools after every lessons-learned session. It’s the first phase but also a recurring activity throughout the lifecycle.
The word “preparation” sounds like a one-time setup. People don’t realise it’s a feedback loop.
Mistake
Recovery means the incident is completely over and you can stop monitoring.
Correct
Recovery includes monitoring the restored systems for a period to ensure no residual threat remains. Monitoring is part of recovery, not a separate activity.
In ordinary life, “recovery” implies the crisis is done. In cybersecurity, it means you’ve returned to normal operations but are still watching carefully.
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 system — like a user logging in or a file being saved. An incident is an event that violates a security policy, such as a malware infection or a data breach. All incidents are events, but not all events are incidents.
The standard order is: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity (Lessons Learned). Containment always comes before Eradication.
A true positive is an alert that correctly detects a real threat (e.g., malware). A false positive is an alert that fires when no threat exists (e.g., a security tool flags a normal software update as malicious).
The lessons learned phase documents what happened, why it happened, what worked well, and what needs improvement. The report is used to update the incident response plan and prevent future incidents.
No. Containment must come first to stop the threat from spreading. If you try to eradicate without containing, you might delete malware from one system while it continues infecting others on the network.
CSIRT stands for Computer Security Incident Response Team. This is the group of people (analysts, managers, forensic experts) responsible for detecting, analysing, containing, eradicating, and recovering from security incidents.
Yes. The same process works for malware, phishing, ransomware, data breaches, denial-of-service attacks, and insider threats. The specific actions change, but the phases remain the same.
You've finished Incident Response Process. Continue through the 200-201 study guide to build a complete picture of the exam.
Done with this chapter?