Incident Response Fundamentals
Run the incident lifecycle from preparation through lessons learned, preserving evidence and communicating clearly.
- Certification
- CompTIA Security+
- Recommended study time
- 6h 35m
- Status
- Not started
Recommended study time
About 6h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 9 sittings.
- Read the lesson22 min
About 2,867 words at a careful technical reading pace.
- Second pass with notes13 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice3h 20m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 40m
4 short review sessions spread over the following weeks.
Learning objectives
- Apply the incident response lifecycle phases in the correct order.
- Preserve volatile and persistent evidence with defensible handling.
- Communicate status, impact, and decisions to technical and business audiences.
Start here
About 8 minutes of reading, in 10 short parts.
No matter how good an organisation's defences are, some incidents will happen, and how well an organisation responds often matters more than the fact an incident occurred at all. Incident response is the structured, practised process of detecting, containing, and recovering from a security event without making things worse through panic or poor decisions.
Where you meet it: A security analyst discovers ransomware on a file server at 2am and follows a pre-agreed incident response plan rather than improvising, isolating the affected system within minutes instead of hours.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Think of incident response like a fire drill. The value of a fire drill is not the drill itself, but that when a real fire happens, people already know exactly what to do, where to go, and who is in charge, instead of making decisions under panic for the first time. A good incident response plan does the same thing for a security breach: it turns a chaotic, high-stress event into a series of pre-agreed, practised steps.
Just as you would not let a small kitchen fire spread to the whole building before trying to put it out, containment in incident response means stopping an attack from spreading further, even before you fully understand it, because delay usually makes the damage worse. Only after the immediate danger is contained do responders investigate exactly what happened and begin properly repairing the damage.
Key ideas
If you remember nothing else from this topic, remember these.
- Incident response follows a defined lifecycle: preparation, detection and analysis, containment, eradication, recovery, and lessons learned, and skipping a phase tends to cause the incident to recur or worsen.
- Containment strategies must balance stopping the damage against preserving evidence, since powering off a compromised system can destroy volatile memory evidence needed for analysis.
- Chain of custody documentation is essential for any evidence collected during an incident, since a broken chain can make evidence unusable in later legal or disciplinary action.
- Order of volatility guides evidence collection, prioritizing the most fragile data, such as CPU registers and memory, before less volatile data like disk contents and backups.
- A well-run lessons-learned review after an incident should produce concrete changes to controls, playbooks, or training, not just a summary of what happened.
- Communication plans defined ahead of time, including who is notified internally and when regulators or affected individuals must be told, prevent costly delays during an actual incident.
Responding to a detected server compromise
A worked example, step by step.
A security monitoring alert flags unusual outbound traffic from an internal server at 2 a.m., later confirmed to be data exfiltration from a compromised account.
- 01Preparation reviewConfirm the incident response plan and on-call escalation contacts are current before proceeding, since this groundwork was already in place.
- 02Detection and analysisCorrelate the alert with authentication logs, confirming a service account logged in from an unusual location shortly before the outbound traffic began.
- 03Determine scopeCheck whether other systems used the same service account credentials, identifying two additional servers with matching suspicious authentication events.
- 04Contain without destroying evidenceIsolate the affected servers at the network level rather than powering them off, preserving volatile memory for later forensic analysis.
- 05Collect evidence in order of volatilityCapture running memory and active network connections first, then disk images, documenting each step with a chain of custody form.
- 06Eradicate the causeDisable the compromised service account, rotate its credentials, and remove any identified malicious tools or scheduled tasks left on the affected servers.
- 07Recover systemsRestore affected servers from known-clean backups, re-enable them on the network gradually, and monitor closely for recurring suspicious activity.
- 08Conduct lessons learnedHold a post-incident review identifying that the compromised service account had excessive privileges, and implement least-privilege changes and enhanced monitoring as concrete follow-up actions.
Outcome: The incident was handled through the full lifecycle, with evidence properly preserved in order of volatility and chain of custody maintained, and the lessons-learned review produced specific access control improvements rather than just a summary report.
Incident response lifecycle and evidence handling
Worth keeping at hand while you work.
- Preparation
- Having plans, tools, and contacts ready before an incident occurs
- Detection and analysis
- Identifying and confirming that an incident has actually occurred
- Containment
- Limiting the spread or impact of the incident
- Eradication
- Removing the root cause, such as malware or a compromised account
- Recovery
- Restoring systems to normal operation safely
- Lessons learned
- Reviewing the incident to improve future prevention and response
- Order of volatility
- CPU registers and cache, then RAM, then temporary files, then disk, then remote logs, then archived backups
- Chain of custody
- Documented record of who handled evidence and when, preserving its integrity
- Legal hold
- A directive to preserve relevant data due to anticipated litigation
- IOC (Indicator of Compromise)
- Observable artifact suggesting a system has been breached
- Playbook
- Predefined step-by-step response procedure for a specific incident type
- Communication plan
- Defines who is notified internally and externally, and when, during an incident
Common misunderstandings
What most beginners get wrong here.
The fastest way to contain a compromised system is to power it off immediately.
Powering off a system destroys volatile evidence in memory; network isolation is often preferred so the system stays running for forensic capture while being cut off from causing further harm.
Incident response ends once the immediate threat is removed.
The lifecycle continues through recovery and lessons learned, and skipping the lessons-learned phase means the same root cause is likely to cause a repeat incident.
Chain of custody only matters for law enforcement investigations.
Chain of custody matters for any incident where evidence might later support internal disciplinary action, insurance claims, or regulatory reporting, not only criminal cases.
Order of volatility means collecting the easiest evidence first.
Order of volatility means collecting the most fragile, quickest-to-disappear evidence first, such as memory contents, before more stable evidence like disk images or backups.
A lessons-learned meeting is complete once everyone agrees on what happened.
A useful lessons-learned review must produce specific, assigned follow-up actions and control changes, not just a shared narrative of events.
Exam traps
How the question writers try to catch you out.
- Security+ tests the exact order of the incident response lifecycle phases and expects containment to come before eradication and recovery.
- Expect scenario questions where powering off a compromised system is the wrong answer because it destroys volatile memory evidence.
- Order of volatility questions test the specific sequence from CPU registers and memory down to archived backups.
- Chain of custody questions often describe an evidence-handling gap and expect you to identify that the evidence's integrity or admissibility is now in question.
- Distractor answers sometimes label containment actions as eradication or vice versa, so read carefully whether the action stops spread (containment) or removes the root cause (eradication).
Check yourself
Answer in your head first, then reveal. This is not scored.
Why is network isolation often preferred over powering off a compromised system?
What is the correct order of volatility for evidence collection, from most to least fragile?
What is the difference between containment and eradication?
Why does chain of custody documentation matter during an incident?
What should come out of a proper lessons-learned review?
What is a playbook in the context of incident response?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
The lifecycle is preparation, detection and analysis, containment, eradication, recovery, and post-incident review. Containment may be short-term (isolate a host) or long-term (block a technique). Evidence handling follows order of volatility, with documented chain of custody. Communication includes technical updates, business impact statements, and regulatory notification where required.
Why It Matters
The first hour determines scope. Rebooting, reimaging, or 'cleaning' a host destroys memory evidence and hides lateral movement, turning a bounded incident into an unknown one with regulatory consequences.
How It Works
- Detection sources such as EDR, SIEM, and user reports trigger triage and scoping.
- Containment isolates affected identities and hosts while evidence is collected.
- Recovery restores from trusted sources and monitors for reinfection before closure.
Where You See It
- Security operations, ransomware response, business email compromise, and regulatory breach reporting.
Key Terms
- Order of volatility
- Collecting the most perishable evidence first, such as memory.
- Containment
- Limiting spread and impact without destroying evidence.
- IOC
- Indicator of compromise, an observable artefact of attacker activity.
- Chain of custody
- Documented handling of evidence from collection onward.
- Post-incident review
- Structured analysis producing improvements, not blame.
Examples
- Isolating a host at the switch or EDR preserves it while stopping outbound command and control.
- Preserving memory before shutdown can reveal credentials and processes absent from disk.
Common Problems
- Unclear roles
- Evidence destroyed by early remediation
- Scope declared too early
- No communication plan
- Restoring from compromised backups
How It Fails
- Reimaging the first infected host hides the initial access vector entirely.
- Restoring backups without eradication reintroduces the attacker's persistence.
- Silence during an incident invites speculation and poor business decisions.
How to Troubleshoot
- Establish a timeline from authoritative logs before drawing conclusions.
- Confirm identity compromise as well as host compromise.
- Validate eradication by hunting for the same indicators fleet-wide before recovery.
Practical Knowledge
- Keep offline copies of contact lists and playbooks; they are useless on an encrypted file share.
- Record decisions with timestamps as the incident proceeds, not afterwards from memory.
Exam Coverage
- Incident response phases
- Evidence handling and forensics basics
- Communication and reporting duties
Interview Questions
- Why is memory collected before disk imaging?
- What would make you delay recovery even when the business is pressing?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Write a one-page playbook for a phished credential incident.
- 02List who must be contacted in your organisation during a suspected breach.