IR Phases and Roles
Key Takeaways
- Incident response uses a repeatable lifecycle so teams can prepare, detect, contain, eradicate, recover, and improve.
- Preparation includes playbooks, contact lists, logging, tooling, access, training, and evidence procedures.
- Roles should be clear before an incident, including incident commander, technical leads, communications, legal, HR, and business owners.
- Triage separates events from incidents by evaluating scope, impact, confidence, and urgency.
- A timeline helps responders coordinate actions and preserve what happened.
IR Phases and Roles
Incident response is the organized process for handling events that may affect confidentiality, integrity, or availability. The goal is not just to remove malware or close an alert. The goal is to limit harm, preserve evidence, restore trusted operations, communicate correctly, and improve the environment after the incident.
Security+ uses the incident response lifecycle as a practical framework. Different organizations may name the phases slightly differently, but the core work is consistent: prepare, detect and analyze, contain, eradicate, recover, and conduct post-incident activity.
Incident Response Lifecycle
| Phase | Purpose | Example actions |
|---|---|---|
| Preparation | Make response possible before an incident occurs | Create playbooks, train staff, verify contacts, deploy logging, define severity levels |
| Detection and analysis | Determine what happened and whether it is an incident | Review alerts, validate indicators, scope affected users and systems, open an incident record |
| Containment | Limit spread and reduce active harm | Isolate hosts, disable accounts, block indicators, segment affected systems |
| Eradication | Remove the cause of compromise | Remove malware, close exploited vulnerability, rotate exposed secrets, remove persistence |
| Recovery | Restore trusted service | Rebuild systems, monitor closely, validate business function, return services in phases |
| Lessons learned | Improve future response | Review timeline, document gaps, update controls, measure response performance |
Event, Alert, and Incident
An event is any observable activity, such as a login, file write, or firewall connection. An alert is a notification that something may require attention. An incident is a confirmed or strongly suspected violation of policy or security that requires a coordinated response.
Example:
08:12 alert: EDR reports encoded PowerShell on LAP-118
08:18 event review: Word spawned PowerShell after opening invoice.docm
08:26 additional evidence: DNS query to newly registered domain
08:33 incident declared: suspected phishing payload with command and control traffic
The declaration matters. Once the team treats the activity as an incident, it should use an incident record, assign roles, preserve evidence, and track decisions.
Common Roles
| Role | Responsibility |
|---|---|
| Incident commander | Coordinates response, owns priorities, tracks decisions |
| Security analyst | Reviews alerts, gathers evidence, builds timeline |
| Forensic analyst | Preserves and analyzes evidence when investigation depth is needed |
| System owner | Explains business function and approves operational changes |
| Network or endpoint engineer | Implements containment and recovery actions |
| Communications lead | Coordinates internal and external messaging |
| Legal or privacy counsel | Advises on evidence, privilege, notification, and regulatory issues |
| Executive sponsor | Makes high-impact business risk decisions |
Scenario Timeline
A school district receives several reports that staff cannot open shared lesson files. The help desk sees filenames ending in an unfamiliar extension. Security opens an incident record.
| Time | Action | Owner | Notes |
|---|---|---|---|
| 09:05 | Help desk reports file access issue | Help desk lead | Multiple users affected |
| 09:11 | EDR alert found on FS-04 | Security analyst | Suspicious process renamed files |
| 09:16 | Incident declared | Incident commander | Severity high due to shared file server |
| 09:22 | SMB access limited to affected share | Network engineer | Containment while preserving host state |
| 09:34 | Service account disabled | IAM engineer | Account used by suspicious process |
| 10:20 | Snapshot and volatile data captured | Forensic analyst | Evidence preserved before rebuild decisions |
Common Traps
- Starting eradication before preserving key evidence.
- Having no incident commander, causing multiple teams to take conflicting actions.
- Treating every alert as an incident without triage.
- Waiting for perfect certainty while active damage continues.
- Letting business owners make technical evidence decisions without security input.
- Letting security teams isolate critical systems without consulting operational owners when safety or availability is affected.
Exam Focus
For SY0-701, watch for words such as playbook, escalation, containment, eradication, recovery, lessons learned, and incident commander. The best answer usually follows the incident phase implied by the scenario. If the scenario says the attacker is still active, containment is often the priority. If systems are clean and business service is being returned, recovery and validation become the focus.
PBQ style: Place these incident response phases in the most appropriate order.
Arrange the items in the correct order
During a high-severity incident, who should coordinate priorities, decisions, and cross-team response actions?
Which preparation items make incident response more effective? Select three.
Select all that apply