ไทย
English
The most important factors after a cyberattack are how quickly an organization can respond, how effectively it can control the damage, and whether it can safely restore its services. Incident Response is the process of responding to cybersecurity incidents through effective cybersecurity risk management. Two widely referenced approaches used around the world are the NIST Incident Response Methodology and the SANS Incident Response Framework.
The earlier NIST SP 800-61 Rev.2 describes the incident handling lifecycle through four main phases: Preparation, Detection & Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. The latest NIST SP 800-61 Rev.3 updates this approach to align with the NIST Cybersecurity Framework 2.0 and places greater emphasis on integrating Incident Response into the organization’s overall risk management process.
Meanwhile, SANS provides a practical and easy-to-understand approach through six steps, commonly known as PICERL: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned.
Table of Contents
Summary of the 6 Incident Response Steps
| Step | Phase | Main Objective | Example Activities |
| 1 | Preparation | Prepare before an incident occurs | Create playbooks, define teams, prepare tools |
| 2 | Identification | Detect and confirm the incident | Analyze alerts, review logs, assess severity |
| 3 | Containment | Limit the impact | Isolate devices, block IPs, disable accounts |
| 4 | Eradication | Remove the threat | Remove malware, patch vulnerabilities, remove backdoors |
| 5 | Recovery | Restore systems safely | Restore backups, rebuild servers, monitor systems |
| 6 | Lessons Learned | Review and improve | Create reports, update playbooks, add detection rules |
The 6 Incident Response steps are based on the SANS PICERL Model and can be mapped to the NIST Incident Response Lifecycle to provide a systematic approach for handling cybersecurity incidents.
1. Preparation: Preparing Before an Incident Occurs
The first step of Incident Response is preparation before an actual incident takes place. Organizations should have an incident response plan, operational procedures, communication channels, and clearly defined roles and responsibilities for each team.
Examples of what should be prepared include an Incident Response Plan, playbooks, escalation matrix, contact list, evidence handling procedures, as well as tools such as SIEM, EDR, firewalls, WAF, backup systems, ticketing systems, and threat intelligence platforms.
Strong preparation helps SOC/CSOC teams, IT teams, management, and other stakeholders make decisions quickly, reduce confusion, and minimize business impact when responding to real incidents.
2. Identification: Detecting, Analyzing, and Confirming the Incident
After an alert or abnormal activity is detected, the responsible team must investigate whether the event is truly a security incident. This step includes analyzing logs, endpoint alerts, firewall events, authentication events, network traffic, and threat intelligence data.
Examples of events that should be investigated include unusual logins, malware detection, suspicious PowerShell execution, data exfiltration, ransomware behavior, privilege escalation, or connections to malicious IP addresses or domains.
The objective of this step is to confirm the incident, assess its severity, identify affected assets, and open an incident ticket to formally begin the response process.
3. Containment: Limiting Damage and Stopping the Spread
Once the incident is confirmed, the next priority is to limit its impact and prevent it from spreading to other systems. Examples include isolating infected machines from the network, blocking malicious IP addresses or domains, disabling compromised accounts, resetting passwords, or temporarily adjusting firewall and EDR policies.
At this stage, evidence preservation is critical. Responding too quickly without collecting necessary information may make it difficult to analyze the root cause later.
Effective containment should include both short-term containment to stop immediate damage and long-term containment to prevent the threat from returning while permanent remediation is being prepared.
4. Eradication: Removing the Threat and Root Cause
After the situation is under control, the team must completely remove the threat from the environment. This may include malware, backdoors, persistence mechanisms, unauthorized accounts, malicious scripts, scheduled tasks, or vulnerabilities exploited during the attack.
This step often includes patching vulnerabilities, hardening systems, removing malicious files, cleaning registries, reconfiguring security controls, and performing additional threat hunting to ensure that the attacker is no longer present in the environment.
The key principle of eradication is not simply to “remove what is visible,” but to understand how the attacker gained access and properly close that entry point.
5. Recovery: Restoring Systems Safely
Once the organization is confident that the threat has been removed, systems can be brought back into operation. This may include restoring from clean backups, rebuilding servers, re-enabling accounts, bringing services back online, or validating business applications.
Recovery should not be treated as simply turning systems back on. Organizations must verify system integrity, ensure that services are operating normally, and confirm that there are no signs of reinfection or attacker re-entry.
In many cases, organizations should establish a period of heightened monitoring after recovery to closely watch for abnormal activities.
6. Lessons Learned: Reviewing and Improving
After the incident is resolved, organizations should conduct a post-incident review to summarize what happened, how it was detected, whether the response was fast enough, what areas need improvement, and what additional controls should be implemented to prevent recurrence.
Key outputs from this step may include an incident timeline, root cause analysis, business impact assessment, response gaps, improvement actions, updated playbooks, new detection rules, revised escalation processes, and a final incident report.
The Lessons Learned phase ensures that Incident Response is not only about solving immediate problems, but also about helping the organization become stronger after every incident.
Differences Between SANS and NIST
| SANS 6 Steps | NIST Incident Response Lifecycle | Meaning |
| Preparation | Preparation | Prepare people, processes, tools, and response plans |
| Identification | Detection & Analysis | Detect, analyze, and confirm the incident |
| Containment | Containment, Eradication & Recovery | Limit damage and stop the spread |
| Eradication | Containment, Eradication & Recovery | Remove the root cause of the threat |
| Recovery | Containment, Eradication & Recovery | Safely restore systems to operation |
| Lessons Learned | Post-Incident Activity | Review lessons learned and improve processes |
Cyber threats can affect any organization. The key challenge is to detect incidents quickly, respond correctly, reduce business impact, and restore systems safely.
Applying the SANS PICERL Model together with the NIST Incident Response Lifecycle helps organizations establish a systematic, clear, and continuously improving approach to cyber incident response.
How BMSP Can Support Your Organization Across These 6 Steps
BMSP helps organizations strengthen their Incident Response readiness through cybersecurity experts and CSOC services that provide continuous security monitoring and support.
| Area of Support | How BMSP Helps |
| Incident Response Readiness | Develop IR plans, playbooks, escalation processes, and incident response workflows |
| 24/7 CSOC Monitoring | Monitor alerts, detect abnormal behavior, and notify critical incidents |
| Threat Detection & Analysis | Analyze logs, IOCs, malware behavior, and attack patterns |
| Containment & Response Support | Support triage, containment, and coordination with IT teams |
| Post-Incident Review | Prepare incident reports, root cause analysis, and improvement recommendations |
| Continuous Improvement | Improve detection rules, security controls, and playbooks to prepare for future incidents |
References
- SANS Institute. Incident Response Framework / PICERL Model.
- National Institute of Standards and Technology (NIST). Computer Security Incident Handling Guide, SP 800-61 Rev.2.
