The incident response process, and the preparation that decides the outcome

Objective 4.8 in this course covers incident response — CompTIA's scope note for it implements processes, training, testing, root cause analysis, threat hunting and digital forensics. This lesson takes the process and the preparation; root cause analysis, hunting and forensics are the next lesson.

Why this matters

The incident response lifecycle is one of the few things on this exam you can rely on being asked about by name and in order. Learn the phases, learn what belongs in each, and learn the two transitions people get wrong — and you have a block of marks that does not depend on judgement at all.

The judgement questions are about sequence: given a scenario mid-incident, what do you do next. Those are answerable from the phase order, and the commonest wrong answer is doing something from a later phase too early.

The lesson

Preparation, detection, analysis, containment, eradication, recovery, lessons learned

CompTIA's seven phases. Know them in order.

1. Preparation — everything done before an incident: the plan, the team, the tooling, the logging, the contacts, the exercises, the backups. This phase is where the outcome is actually decided, which is why it gets its own sections below.
2. Detection — noticing that something has happened. From the monitoring in 4.4, from a user report, from a third party, or from the attacker themselves.
3. Analysis — determining what it is, how far it goes, and how serious. Scoping happens here: which accounts, which hosts, what data, since when.
4. Containment — stopping it getting worse. Isolating hosts, disabling accounts, blocking destinations, taking a service offline.
5. Eradication — removing the cause. Deleting the malware, closing the vulnerability, removing the attacker's persistence and accounts.
6. Recovery — restoring normal operation, verifying the systems are clean, and monitoring closely for a return.
7. Lessons learned — the post-incident review that turns the incident into changed controls.

Two transitions to be exact about.

Containment comes before eradication. Stop the bleeding first. An exam scenario where an attack is in progress and the options include "patch the vulnerability" and "isolate the affected host" wants isolation — patching does not remove an attacker who is already inside.

Analysis comes before containment, and this is the one that is genuinely contested. Acting the instant you detect something feels right and is often wrong against a patient adversary: you evict one foothold, they use the second one you never found, and now they know you are hunting. That is the espionage case from Domain 2. The resolution the exam expects: scope enough to contain completely, and for a fast destructive incident such as ransomware spreading, contain immediately because the damage is accruing by the minute. Motivation and speed of damage decide how much analysis precedes containment.

Containment is often split into short-term (immediate, crude — pull the network cable) and long-term (a sustainable posture while you work — segment, monitor, rebuild in parallel).

Training, tabletop exercises and simulations, and what each is for

Preparation is a set of activities, not a document, and CompTIA names them.

Training is making sure people can do their part. Three audiences with different needs: the response team, who need the technical procedures; the wider IT staff, who need to know what to do and — crucially — what not to do; and everyone else, who need to know how to report something.

The "what not to do" is worth emphasising because it is where well-meaning staff destroy the investigation. Rebooting the compromised machine, deleting the suspicious file, logging in to "have a look", or telling the attacker you have noticed. First responder guidance is: do not power off, do not log in, do not delete — report it and preserve it.

Tabletop exercises walk through a scenario in a room. They find the decision gaps: who declares an incident, who can authorise taking the payment system offline, who talks to the regulator, what happens if the incident starts at 2am on a bank holiday, and who is authorised if the head of security is the person whose account is compromised.

Simulations are more realistic — phishing simulations that measure real behaviour, or technical exercises where the team responds to injected events on real tooling.

The exercise cadence is part of preparation: run them regularly, and run them with the people who would actually be on shift rather than only the people who wrote the plan.

The communication plan, and the stakeholder who must not hear it from the news

The communication plan is the part of preparation most likely to fail in practice, and it is examinable.

What it must specify:

• Who is informed, in what order, and by whom. Executives, legal, the data protection officer, PR, affected customers, partners, insurers, law enforcement, regulators.
• Deadlines. Breach notification obligations are measured in hours and days, not weeks — an organisation that spends three days deciding whether to notify has often already missed the window. Domain 5 covers the obligations.
• An out-of-band channel. If the corporate email and chat are compromised, or down, the response team needs a way to talk that the attacker is not reading. A pre-agreed alternative with the contact list held offline is the control, and a contact list that lives only on the file server you cannot reach is the failure.
• A single spokesperson, so the organisation says one thing.
• What is said internally, because staff will talk regardless and an absence of information is filled with speculation.

The heading's point: the stakeholder who learns about your incident from a journalist, a customer, or the attacker's leak site will respond far worse than one you told early. That is true of regulators, large customers and your own board, and it is a reason the communication plan is a security control rather than a public relations nicety.

Legal hold, chain of custody and preservation, in outline

The legal dimension starts during the incident, not afterwards.

• Legal hold — once litigation or regulatory action is reasonably anticipated, relevant data must be preserved and routine deletion suspended. This includes logs that would otherwise age out, mailboxes of departing staff, and the very backups your recovery is about to overwrite. Issuing the hold early is the control; realising afterwards that the evidence aged out is the failure.
• Chain of custody — the unbroken record of who held each piece of evidence, when, and what they did with it. Covered properly next lesson.
• Preservation — capturing evidence before it changes. Memory is gone at power-off; logs roll; cloud resources are deleted; attackers clear traces. The practical instruction during recovery is to image before you rebuild, because the pressure to restore service destroys the evidence that would tell you what happened.

Note the tension this creates and that the exam will test: recovery wants the system back now, investigation wants it untouched. The resolution is to take a forensic image and a memory capture first — minutes of work — and then rebuild from clean media onto new infrastructure.

Also in preparation: knowing when to involve law enforcement and having the relationship before you need it, and knowing what your cyber insurance requires — many policies mandate using their approved responders and notifying within a set period, and calling your own firm first can void the cover.

Why containment before eradication is not optional

To close the lesson, the sequence question stated plainly, because it is the single most reliable source of marks in this objective.

Containment limits the damage that is still accruing. Eradication removes the cause. Recovery restores service. Doing them out of order produces specific, predictable failures:

• Eradicate before containing, and the attacker — still present — simply re-establishes. You have alerted them and achieved nothing.
• Recover before eradicating, and you restore a system that is still compromised, or restore from a backup that contains the attacker's access. The incident restarts, and the second round is worse because your backups are now suspect.
• Contain before you have scoped, against a patient adversary, and you contain one of five footholds.
• Skip lessons learned, and the same incident happens again — which is why the phase exists and why its output must be a changed control, not a document. A lessons-learned review that produces no ticket and no configuration change did not happen.

A final preparation item that belongs with this: the response plan must be available when the systems are down. A plan stored only on the intranet, or on the file server the ransomware encrypted, is a plan you do not have. Offline copies, printed contact lists, and credentials for the break-glass account in a safe are the unglamorous controls that decide how the first hour goes.

What to take into the exam

• Preparation, detection, analysis, containment, eradication, recovery, lessons learned — in that order.
• Containment before eradication, always. Isolating beats patching while an attack is live.
• How much analysis precedes containment depends on speed of damage: ransomware now, espionage scope first.
• First responders: do not power off, do not log in, do not delete.
• The communication plan needs an out-of-band channel and an offline contact list, because the compromised systems may be the ones you would have used.
• Image before you rebuild, and issue the legal hold before the logs age out.