Incident Response: The IR Plan, Phases, CSIRT and Tabletop Exercises

Incident response starts with a definition problem: not everything unusual is an emergency. An event is any observable occurrence in a system or network. Events happen constantly and most are completely normal: a user logs in, a file is saved, a firewall blocks a probe from the internet, a server reboots for patching. Events are the raw material of monitoring, and the vast majority need no response at all.

An incident is an event, or a set of related events, that actually or potentially jeopardizes the confidentiality, integrity, or availability of information or systems, or that violates security policy. In plain terms, an incident is an event with harm attached, whether the harm has already happened or is credibly threatened.

The distinction matters because it is the trigger for the whole IR process. Declaring an incident activates the response team, starts formal documentation, and may start legal and regulatory clocks for notification. Declaring too eagerly wastes the team's time on noise; declaring too slowly lets real damage spread. A clear, written definition of what counts as an incident, set out in the IR plan, is what makes that call consistent instead of a judgment made differently by every analyst.

The Incident Response Plan is the document that tells the organization how it will respond to incidents, written and approved before any incident occurs. Its central purpose is to replace improvisation with preparation: in the middle of a ransomware outbreak at 2 a.m. is the worst possible moment to start deciding who is in charge, who may shut down a server, and who talks to customers.

A useful IRP typically defines:

• Definitions and criteria: what counts as an event versus an incident, and severity levels that determine how urgently each incident is handled.
• Roles and responsibilities: who leads the response, who performs technical analysis, who has authority to take systems offline, and who communicates internally and externally.
• Contact and escalation paths: current call lists for the response team, management, legal counsel, and any external parties such as law enforcement or forensic specialists.
• Procedures by phase: the actions to take during detection, containment, eradication, recovery, and post-incident review, often supplemented by playbooks for specific incident types like phishing or ransomware.
• Communication and reporting rules: how updates flow to leadership, when regulators or affected individuals must be notified, and who is authorized to speak publicly.

The plan must be a living document. It is reviewed on a schedule, updated when systems, people, or laws change, and revised after every real incident and exercise to capture what was learned. An IRP that sits untouched in a folder for three years, full of departed employees' phone numbers, offers little more protection than having no plan at all.

The CC exam uses the widely adopted NIST model, which organizes incident response into four phases. The order is tested, so learn it exactly:

1. Preparation
2. Detection and Analysis
3. Containment, Eradication and Recovery
4. Post-Incident Activity

Preparation is everything done before an incident: writing and maintaining the IRP, forming and training the response team, deploying monitoring and logging so incidents can be seen, and running exercises. Preventive hardening of systems is also commonly associated with this phase, because fewer incidents is the best outcome of all.

Detection and Analysis is recognizing that an incident may be occurring and confirming it. Alerts from monitoring tools, user reports, and anomalies are investigated to answer: is this a real incident, what type is it, which systems and data are affected, and how severe is it? The output is a declared, prioritized incident with an initial scope, all of it documented from the first moment.

Containment, Eradication and Recovery is the hands-on fix, and its internal order matters. Containment first limits the damage, for example by isolating infected machines from the network or disabling compromised accounts, so the incident stops spreading while evidence is preserved. Eradication then removes the cause: deleting malware, closing the exploited vulnerability, and eliminating the attacker's access. Recovery finally restores normal operations, rebuilding or restoring systems from clean backups and monitoring them closely for signs the attacker returns.

Post-Incident Activity happens after operations are restored: a lessons-learned review of what happened, how well the response worked, and what must change, feeding improvements back into Preparation. The phases form a loop, not a straight line.

You may also encounter a six-step model popularized by SANS, remembered by the mnemonic PICERL:

1. Preparation
2. Identification
3. Containment
4. Eradication
5. Recovery
6. Lessons Learned

Look closely and you will see it is the same process sliced differently, not a competing philosophy. SANS Identification corresponds to NIST Detection and Analysis. SANS breaks the middle of the response into three separate steps, Containment, Eradication, and Recovery, where NIST groups them into one combined phase, and SANS Lessons Learned corresponds to NIST Post-Incident Activity. The underlying sequence of work is identical: get ready, notice and confirm the incident, stop the bleeding, remove the cause, restore service, then learn from it.

Two practical points follow. First, whichever model an organization adopts, containment always comes before eradication, and eradication before recovery. Reversing that order fails in predictable ways: cleaning malware off one machine while the attacker still roams the network (eradication before containment) just invites reinfection, and restoring systems before the attacker's access is removed (recovery before eradication) puts clean systems back into a compromised environment.

Second, for the exam, do not invent phases or blend the models into something new. If a question presents four phases, think NIST: Preparation; Detection and Analysis; Containment, Eradication and Recovery; Post-Incident Activity. If it presents six steps, think PICERL. Either way, questions about what comes after what are testing the same fixed order, and the answer choices that break it, such as recovering before eradicating, are wrong by design.

Incident response is a team activity, and the team is broader than the security department. The group is commonly called a Computer Security Incident Response Team, or CSIRT (you may also see CIRT or CERT). Some organizations staff a permanent team; many convene a designated cross-functional team when an incident is declared. Either way, membership and authority are defined in advance by the IRP, not negotiated during a crisis.

Typical roles include:

• Incident response manager or team lead: coordinates the response, assigns tasks, tracks status, and is the single point of decision so efforts do not conflict.
• Security analysts and technical specialists: investigate the incident, analyze logs and malware, perform containment and eradication, and restore systems, often including network, server, and application administrators.
• Management and executive sponsor: provide authority for disruptive decisions, such as taking a revenue-generating system offline, and accept residual risk on behalf of the business.
• Legal counsel: advises on regulatory notification duties, liability, evidence handling, and interaction with law enforcement.
• Communications or public relations: manages messaging to employees, customers, media, and regulators, so the organization speaks accurately and with one voice.
• Human resources: engaged when an insider is involved or employee action is required.

Smaller organizations may supplement the team with external parties, such as forensic consultants or an incident response retainer service, and the plan should say when and how to bring them in. The exam point is recognition: the CSIRT is the predefined, cross-functional team that executes the IR plan, and effective response requires legal, communications, and management involvement, not only technical staff.

An incident is not only an operational problem; it may become a legal one. The organization might pursue an attacker in court, face a regulatory investigation, discipline an insider, or file an insurance claim. In each case, what the response team collected during the incident, logs, disk images, memory captures, emails, becomes evidence, and evidence is only useful if its integrity can be demonstrated.

This is where the organization's data-handling policy supports incident response. Data-handling rules that already govern how information is classified, labeled, stored, retained, and destroyed extend naturally into IR: they tell responders which data is sensitive, how long logs are kept (so the evidence still exists when the incident is discovered), who may access collected material, and how it must be protected. During a response, preserving evidence is an explicit goal alongside restoring service, which is one reason containment techniques that keep a copy of the compromised state, such as isolating a machine rather than immediately wiping it, are preferred when legal action is possible.

The key concept the exam expects you to recognize is chain of custody: the documented, unbroken record of who collected each piece of evidence, when and how it was collected, where it has been stored, and every person who has handled it since. If the chain is broken, an opposing party can argue the evidence was altered, and it may be ruled inadmissible.

At CC level you are not expected to perform forensics. You are expected to know that evidence must be preserved and its handling documented from the moment an incident is suspected, and that the lead responder ensures collection follows the plan rather than ad-hoc curiosity.

An untested plan is a set of assumptions. Testing turns those assumptions into verified capability, and it is a formal part of the Preparation phase. Exercises range from lightweight to fully realistic, and organizations typically use a mix.

The most common and most examinable form is the tabletop exercise: a structured, discussion-based walk-through of a scripted incident scenario. The response team gathers in a room (or a call), a facilitator presents the scenario in stages, and participants talk through what they would do at each step using the actual plan. Nothing is done to production systems; the exercise is conversation, which makes it cheap, safe, and easy to run regularly. Its value is in exposing gaps: unclear authority, missing contacts, unrealistic procedures, and steps nobody owns.

Consider a concrete scenario. The facilitator announces: it is Friday at 16:45, and the help desk reports that files on the finance share are being renamed with a strange extension and a ransom note has appeared. The team works the script: the analyst explains how they would confirm ransomware and identify affected systems (Detection and Analysis); the lead decides to isolate the finance server and disable the suspected account, and the group discovers that nobody present has authority to take the server offline after hours (a containment gap); legal is asked when customers must be notified and cannot answer from the plan (a documentation gap). Both gaps go into the follow-up report, and the plan is corrected, at a total cost of two hours of discussion.

Beyond tabletops, organizations run more intensive tests, such as simulations and full-scale exercises that involve doing real actions in controlled conditions. Whatever the format, testing must be regular, because teams, systems, and threats all change, and each exercise should end with documented findings that feed back into an updated plan.