Incident-response questions often make several answers sound useful. The deciding clue is usually when the action belongs.
For Security+ study, use this working sequence:
Preparation → Detection → Analysis → Containment → Eradication → Recovery → Lessons learned
Fast rule: Do not remove the cause before you understand and contain the incident. Do not return systems to normal before the threat has been removed and recovery has been validated.
Real incidents can loop between activities, and current NIST guidance integrates incident response across broader cybersecurity risk management. The sequence above remains useful for Security+ questions that ask which response action belongs first or next.
1. The sequence at a glance
| Phase | Main question | Typical work |
|---|---|---|
| Preparation | Are we ready to respond? | Plans, roles, contacts, tools, logging, backups, exercises, communications. |
| Detection | Did something suspicious happen? | Alerts, reports, anomalies, indicators, monitoring. |
| Analysis | What happened and how serious is it? | Validate the event, determine scope, affected assets, cause, severity, and evidence needs. |
| Containment | How do we stop the incident from spreading or causing more harm? | Isolation, blocking, account restriction, segmentation, temporary controls. |
| Eradication | How do we remove the cause or foothold? | Remove malicious artifacts, close exploited weaknesses, reset compromised credentials, rebuild when needed. |
| Recovery | How do we safely restore normal operation? | Restore, validate, reconnect, monitor, confirm business function. |
| Lessons learned | What should change before the next incident? | Review timeline, root causes, controls, communications, procedures, and follow-up actions. |
2. Preparation
Preparation happens before the incident. It creates the conditions that make the later phases possible.
Common preparation activities include:
- defining response roles and escalation paths
- maintaining contact lists and communication methods
- establishing logging, monitoring, evidence handling, and retention
- preparing response tools and clean systems
- confirming backups and recovery procedures
- documenting playbooks and decision authority
- running exercises and tabletop scenarios
If a question asks what an organization should establish before an incident occurs, think preparation.
Preparation is not the same as prevention. Preventive controls may reduce the chance of an incident, but preparation assumes an incident can still happen and makes the organization ready to respond.
3. Detection and analysis
Detection
Detection is the recognition that an event may require investigation. The first signal might come from:
- a security information and event management (SIEM) alert
- endpoint detection
- user report
- network anomaly
- cloud alert
- threat intelligence match
- unusual authentication activity
An alert is not automatically a confirmed incident.
Analysis
Analysis determines what the evidence means.
Typical questions include:
- Is the event real?
- Which systems and accounts are affected?
- When did it begin?
- What indicators are present?
- What is the likely attack path?
- Is sensitive data involved?
- What is the potential business impact?
- What evidence must be preserved?
This distinction matters on FIRST questions. If the team has only an unexplained alert, validating and scoping the event may be more appropriate than immediately rebuilding a server.
Evidence clue: When an action could destroy useful evidence or hide the scope of the incident, collect and preserve what is reasonably needed before making an irreversible change, unless immediate safety or harm reduction requires faster action.
4. Containment
Containment limits additional damage while the team works toward a durable fix.
Examples include:
- isolate an infected endpoint
- block a malicious destination
- disable or restrict a compromised account
- segment an affected network
- remove a public route to a vulnerable service
- apply a temporary firewall rule
- revoke an exposed session or token
Containment can be short-term or longer-term. The goal is to control the incident without unnecessarily destroying evidence or disrupting unaffected systems.
Containment is not eradication. Isolating a host may stop communication while malicious files, compromised credentials, or the exploited weakness still exist.
5. Eradication
Eradication removes the cause, foothold, or persistent access that allowed the incident to continue.
Actions can include:
- remove malicious software or persistence
- patch or reconfigure the exploited weakness
- reset compromised credentials
- remove unauthorized accounts or keys
- rebuild a system from a trusted image
- eliminate attacker-controlled scheduled tasks or services
Eradication follows enough analysis and containment to understand what must be removed.
If only the visible symptom is removed, the incident may return. A compromised account password can be reset, for example, while an unrevoked token or malicious persistence mechanism still allows access.
6. Recovery
Recovery returns systems and business processes to an acceptable operating state.
Typical work includes:
- restore systems or data from trusted sources
- verify patches and configuration changes
- validate required business functions
- reconnect isolated systems in a controlled way
- increase monitoring for recurrence
- confirm that affected users can work safely
Recovery is not simply “turn it back on.”
A restored system should be checked before normal exposure returns. Otherwise, the organization may restore the same weakness or reconnect an incompletely cleaned system.
7. Lessons learned
Lessons learned occurs after immediate response and recovery work is under control.
The review should ask:
- What happened?
- Which detection worked or failed?
- Were roles and communications clear?
- Which controls reduced impact?
- Where did response slow down?
- What root cause or process weakness remains?
- Which playbooks, training, controls, or recovery plans need updates?
Lessons learned should produce follow-up work, not merely a meeting.
A useful outcome might be a new detection rule, tighter identity control, revised escalation procedure, better logging, improved backup validation, or a tracked remediation item.
8. FIRST and NEXT questions
When Security+ asks for the FIRST, NEXT, BEST, or MOST appropriate action, use the scenario state rather than memorizing one universal action.
Ask what has already happened
If the scenario says the incident is confirmed and scoped, you do not need to choose “analyze” again unless new evidence creates uncertainty.
If the threat is already isolated and the question asks what comes next, eradication may be appropriate.
If eradication is complete, recovery becomes the likely next phase.
Protect life, safety, and critical operations
A textbook sequence does not require an organization to allow immediate severe harm while collecting perfect evidence. Safety and urgent harm reduction can override the neat sequence.
Preserve evidence when it matters
If two answers both reduce harm, prefer the one that also preserves necessary evidence when the scenario signals legal, forensic, or investigative requirements.
Choose the action that advances the current phase
Do not jump from detection to lessons learned. Do not restore a system before removing the threat. Do not treat a temporary isolation step as a complete fix.
9. Common exam traps
Trap: containment equals eradication
Disconnecting a host can contain the incident while leaving the malicious software or exploited weakness untouched.
Trap: rebuilding immediately after the first alert
A rebuild might erase useful evidence and fail to reveal whether other systems are affected. Confirm and scope the incident first when the situation permits.
Trap: recovery means removing malware
Removing the threat belongs to eradication. Recovery is the controlled return to normal operation after the threat has been addressed.
Trap: lessons learned is optional
Post-incident review is where the organization converts one response into better preparation for the next incident.
Trap: treating the phases as perfectly linear
Real response work can loop. New evidence discovered during containment can send the team back to analysis. Use the phase model to determine purpose and ordering, not to pretend incidents never change.
10. Rapid review grid
| Question clue | Think |
|---|---|
| Plans, tools, contacts, exercises before an incident | Preparation |
| Alert or suspicious activity first noticed | Detection |
| Validate, scope, determine impact, preserve evidence | Analysis |
| Stop spread or further harm | Containment |
| Remove malicious presence or exploited weakness | Eradication |
| Restore, validate, reconnect, monitor | Recovery |
| Review response and improve controls or procedures | Lessons learned |