6 Incident Response

Purpose and structure

Incident response coordinates the recognition, management, and recovery of a cybersecurity incident while limiting harm to people, systems, information, and operations. It is not solely the responsibility of a security team: technology staff, business leaders, legal and privacy specialists, communications staff, and service providers may all contribute.

Current NIST guidance integrates incident response into broader cybersecurity risk management and emphasizes continuous improvement. The operational stages below remain a useful way to organize the work, but they are connected rather than a rigid one-way checklist. New evidence can send responders back to earlier activities.

Prepare before an incident

Preparation takes place before an incident. It helps teams respond faster and avoid improvising under pressure. Organizations should establish what counts as an incident, who can declare one, and how suspected incidents should be reported.

Preparation also requires clear roles, decision-making authority, escalation paths, and backup contacts. Maintain procedures for likely scenarios such as compromised accounts, malware, data exposure, and service outages. Identify important systems, data, identities, and suppliers, along with their dependencies.

Ensure useful logs and alerts are available, protected, and retained. Prepare secure communication channels and procedures for handling evidence. Test the response plan through exercises and ensure recovery resources, such as verified backups, are available.

Safeguards that reduce the likelihood or impact of incidents are also part of preparation. Plans should account for relevant legal, regulatory, contractual, and privacy obligations. Consult appropriate specialists rather than assuming a single reporting rule applies to every incident.

Triage and analyze

Triage is the initial assessment of a report or alert. Responders determine whether the information is credible, whether it meets the organization’s incident criteria, how serious it may be, and what action is needed first. An alert does not automatically confirm an incident: it may be a false positive, a benign event, or evidence of a real compromise.

A practical assessment asks:

1. What happened, and when? Record the report, alert, affected accounts or assets, and known timeline.

2. What may be affected? Identify potentially involved systems, users, data, business services, and connected environments.

3. How severe and urgent is it? Consider operational disruption, sensitive data, spread, attacker access, and safety or mission impact.

4. What evidence can clarify scope? Review relevant security alerts, endpoint and identity records, network activity, cloud logs, and user reports.

5. Who must be involved or notified? Escalate according to the response plan and applicable obligations.

Maintain a clear incident record containing observations, decisions, actions, timestamps, responsible people, and the basis for important conclusions. Preserve relevant evidence and restrict access to it. Triage is iterative: new evidence may change the incident’s scope or priority, so analysis may resume during later stages.

Contain the incident

Containment limits damage and prevents an incident from spreading while responders investigate. Possible actions include isolating an affected device from the network, disabling or restricting a compromised account, blocking malicious network traffic, or temporarily taking a vulnerable service offline.

Choose actions with their operational impact in mind. Disconnecting a critical server, for example, may stop an attacker’s activity but also interrupt an essential service. Record what was changed and why. Where possible, preserve evidence before taking actions that could destroy it, but do not delay urgent steps needed to protect people or limit serious harm. Containment may be temporary and adjusted as responders learn more.

Eradicate the compromise

Eradication removes the attacker’s access and the underlying causes or artifacts of the compromise. Depending on the incident, actions may include removing malicious software, closing an exploited weakness, disabling unauthorized access mechanisms, rotating exposed credentials or keys, and correcting unsafe configurations.

Do not assume that deleting a visible malicious file resolves the incident. Investigate how the attacker entered, what access they obtained, and whether other systems or accounts were affected. Otherwise, an overlooked account, vulnerability, or persistence mechanism may allow the attacker to regain access.

Recover and monitor

Recovery restores affected systems and services to reliable operation. Restore from known-good sources, verify that weaknesses have been addressed, and test that systems function as expected before returning them to normal use. Bring services back in a controlled order based on business priorities, then monitor for renewed malicious activity or unexpected behavior.

Recovery involves more than turning systems back on. Confirm that access controls, configurations, data integrity, and monitoring are appropriate, and communicate service status to affected stakeholders. If monitoring finds new evidence of compromise, return to analysis, containment, or eradication as needed.

Learn and improve

An after-action review identifies what happened, what worked, what caused delays or confusion, and what should change. Findings should lead to assigned, trackable improvements. Examples include better alert coverage, clearer escalation instructions, improved backup testing, or faster access to incident-response contacts.

Do not wait until every recovery task is complete to share useful lessons. Improvement is continuous: learning from preparation, detection, response, and recovery can strengthen organizational practices throughout an incident and afterward.

Example: suspected ransomware

In a suspected ransomware incident, an endpoint alert reports unusual file changes. Responders first check whether the alert is credible, identify the device and user, and assess whether shared systems or other endpoints show similar activity.

If the threat appears active, responders isolate affected devices and restrict suspected compromised accounts while recording their actions and preserving relevant evidence. They investigate the entry point and scope, remove malicious access, and fix the exploited weakness. They then restore affected systems from verified clean backups, monitor for renewed activity after services return, and document improvements to detection, response, and recovery procedures.

This sequence is illustrative, not rigid. New evidence can send responders back to triage or containment at any point.