See Cynet’s Autonomous
Breach Protection in Action

Prefer a one-on-one demo? Click here

By clicking next I consent to the use of my personal data by Cynet in accordance with Cynet's Privacy Policy and by its partners

Incident Response

The Cynet 360 platform is the world’s fastest IR tool and includes automated attack detection and remediation

Learn More

NIST Incident Response Plan: Building Your Own IR Process Based on NIST Guidelines

Incident response is a structured process organizations use to identify and deal with cybersecurity incidents. Response includes several stages, including preparation for incidents, detection and analysis of a security incident, containment, eradication, and full recovery, and post-incident analysis and learning.

We’ll present the National Institute of Standards and Technology (NIST) framework for incident response, and show how to build your incident response plan according to NIST principles, with templates and real life examples you can follow to get started.

In this article:

What is the NIST Incident Response Framework?

The National Institute of Standards and Technology (NIST) is an agency operated by the United States’ Department of Commerce which provides standards and recommendations for many technology sectors.

Within NIST, the Information Technology Laboratory (ITL) is responsible for developing standards and measurement methods for IT, including information security. ITL developed an influential model for incident response (IR), the Computer Security Incident Handling Guide (Special Publication 800-61).

The NIST incident response process is a cyclical activity featuring ongoing learning and advancements to discover how to best protect the organization. It includes four main stages: preparation, detection/analysis, containment/eradication, and recovery.

What is an Incident Response Plan?

Incident response is an organizational process that enables timely, effective response to cyberattacks. The incident response process includes identifying an attack, understanding its severity and prioritizing it, investigating and mitigating the attack, restoring operations, and taking action to ensure it won’t recur.

An incident response plan (IRP) is a set of documented procedures detailing the steps that should be taken in each phase of incident response. It should include guidelines for roles and responsibilities, communication plans, and standardized response protocols.

7 Reasons You Need an Incident Response Plan

A strong incident response process can dramatically reduce the damage caused to an organization when disaster strikes. An incident response plan helps codify and distribute the incident response plan across the organization.

Here are the main reasons you must have a strong incident response plan in place:

  1. Prepares you for emergency—security incidents happen without warning, so it’s essential to prepare a process ahead of time
  2. Repeatable process—without an incident response plan, teams cannot respond in a repeatable manner or prioritize their time
  3. Coordination—in large organizations, it can be hard to keep everyone in the loop during a crisis. An incident response process can help achieve this
  4. Exposes gaps—in mid-sized organizations with limited staff or limited technical maturity, an incident response plan exposes obvious gaps in the security process or tooling which can be addressed before a crisis occurs
  5. Preserves critical knowledge—an incident response plan ensures critical knowledge and best practices for dealing with a crisis are not forgotten over time and lessons learned are incrementally added
  6. Practice makes perfect—an incident response plan creates a clear, repeatable process that is followed in every incident, improving coordination and effectiveness of response over time
  7. Documentation and accountability—an incident response plan with clear documentation reduces an organization’s liability—it allows you to demonstrate to compliance auditors or authorities what was done to prevent the breach

Key Roles in an Incident Response Team

To execute an incident response plan, you need an incident response team. In a large organization the roles may be carried out by full-time employees or entire teams; in smaller organizations, they can be filled by employees with other full-time roles, who also participate in the incident response process.

The following are essential roles within the team:

  • Incident response managers—have at least two members of staff responsible for approving the incident response plan and coordinating activity when an incident occurs.
  • Security analysts—review alerts, identify possible incidents and perform an initial investigation to understand the scope of an attack.
  • Threat researchers—responsible for providing contextual information around a threat, using information from the web, threat intelligence feeds, data from security tools, etc.
  • Other stakeholders—these can include senior management or board members, HR, PR, and senior security staff such as the Chief Information Security Office (CISO)
  • Third parties—such as lawyers, outsourced security services, or law enforcement agencies.

NIST Recommendations for Organizing A Computer Security Incident Response Team (CSIRT)

The NIST Computer Security Incident Handling Guide provides in-depth guidelines on how to build an incident response capability within an organization. It covers several models for incident response teams, how to select the best model, and best practices for operating the team.

Incident Response Team Models

NIST offers three models for incident response teams:

  • Central—centralized body that handles incident response for the entire organization.
  • Distributed—multiple incident response teams, with each one responsible for a physical location (e.g. branch office), a department or a part of the IT infrastructure
  • Coordinated—a central incident response team that works together with distributed incident response teams, without having authority over them. The central team serves as a knowledge center and offers assistance with complex, critical, or organization-wide incidents.

Within each of these models, staff can be employees, partially outsourced, or fully outsourced. Employees can also be full- or part-time.

Selecting a Team Model

NIST provides several considerations for selecting an incident response model:

  • Does incident response need to be available 24/7? Do incident responders need to be on-site or is phone contact sufficient? Real-time availability and on-site presence is best because it allows immediate response to an incident, which can prevent damage.
  • Should staff be part-time or full-time? Part-time employees can be used to make up a virtual incident response team, like a volunteer emergency response unit. When an incident occurs, the IT help desk can be the first point of contact. They can perform an initial investigation, rapidly call on incident response team members, and whomever is available can respond to the incident.
  • Should staff be security experts? What level of expertise is needed? Incident response requires broad knowledge of IT systems, communication protocols, attack techniques, and also the organization’s environment, systems and procedures. Outsourced teams typically have stronger security expertise, but employees have a better understanding of the IT environment, normal vs. malicious behavior, and of which systems are critical, etc.
  • How much will the incident response team cost? Because incident responders need special expertise, and are often required to be on-site 24/7, they can represent a major investment. Managed Security Service Providers (MSSP) can also be costly, and there is an additional cost of security tooling, physical facilities and secure communication methods.

How to Organize Incident Response

The NIST Incident Response Guide provides several guidelines for organizing and operating an incident response unit.

Establish a formal incident response capability

Even if your organization is small, take incident response seriously and establish a formal incident response body. If it is not possible to establish a full-time incident response team, create a virtual team with part-time staff, and give this team full authority and responsibility. This will dramatically improve your capability to respond when a cyberattack strikes.

Create an incident response policy

This is a precursor to the incident response plan which lays out the organizational framework for incident response. It specifies what is considered a security incident, who is responsible for incident response, roles and responsibilities, documentation and reporting requirements.

Define an incident response plan

According to NIST methodology, an incident response plan is not merely a list of steps to perform when an incident happens. It is a roadmap for the organization’s incident response program, including short- and long-term goals, metrics for measuring success, training and job requirements for incident response roles.

Develop incident response procedures

These are the detailed steps incident response teams will use to respond to an incident. They should be based on the incident response policy and plan and should address all four phases of the incident response lifecycle: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity.

The NIST Incident Response Life Cycle

NIST defines a four-step process for incident response, illustrated in the diagram below. The NIST process emphasizes that incident response is not a linear activity that starts when an incident is detected and ends with eradication and recovery. Rather, incident response is a cyclical activity, where there is continuing learning and improvement to discover how to better defend the organization.

Source: NIST

After every incident there is a substantial effort to document and investigate what happened during the incident, to feed back to earlier stages and to enable better preparation, detection and analysis for future incidents.

There is also a feedback loop from the containment and eradication step to detection and analysis—many parts of an attack are not fully understood at the detection stage and are only revealed when incident responders “enter the scene”. These lessons can help the team detect and analyze attacks more fully the next time around.

The Four Steps of NIST Incident Response

1. Preparation

To prepare for incidents, compile a list of IT assets such as networks, servers and endpoints, identifying their importance and which ones are critical or hold sensitive data. Set up monitoring so you have a baseline of normal activity. Determine which types of security events should be investigated, and create detailed response steps for common types of incidents.

Cynet 360 provides all the core capabilities required for sound incident preparation, including a centralized visibility interface showing all endpoint configurations, process execution, installed software, network traffic and user activity.

2. Detection and Analysis

Detection involves collecting data from IT systems, security tools, publicly available information and people inside and outside the organization, and identifying precursors (signs that an incident may happen in the future) and indicators (data showing that an attack has happened or is happening now).

Analysis involves identifying a baseline or normal activity for the affected systems, correlating related events and seeing if and how they deviate from normal behavior.

An integrated security platform like Cynet 360 can do this for you, automatically identifying behavioral baselines, detecting anomalies that represent suspicious behavior, and collecting all relevant data across networks, endpoints and users to help you investigate it.

Learn more about how Cynet 360 provides detection capabilities against a wide range of attack vectors with its natively integrated EDR, user behavior rules, network detection rules and deception modules.

3. Containment, Eradication, and Recovery

The goal of containment is to stop the attack before it overwhelms resources or causes damage. Your containment strategy will depend on the level of damage the incident can cause, the need to keep critical services available to employees and customers, and the duration of the solution—a temporary solution for a few hours, days or weeks, or a permanent solution.

As part of containment, it is important to identify the attacking host and validate its IP address. This allows you to block communication from the attacker and also identify the threat actor to understand their mode of operation, search for and block other communication channels they may be using.

Cynet 360 can help you take remote manual action to contain security incidents, including stopping malicious processes, deleting files, resetting passwords and restarting affected devices. It can also perform automatic containment actions such as stopping rapid encryption of files or automatically isolating endpoints infected by malware from the network.

Cynet response orchestration capabilities provide the means to terminate attackers’ presence and activity from all parts of the environment: infected hosts, malicious files, compromised user accounts and attacker-controlled traffic. Learn more about Cynet 360’s incident containment capabilities.

In the eradication and recovery stage, after the incident has been successfully contained, you should act to remove all elements of the incident from the environment. This might include identifying all affected hosts, removing malware, and closing or resetting passwords for breached user accounts.

Finally, once the threat is eradicated, restore systems and recover normal operations as quickly as possible, taking steps to ensure the same assets are not attacked again.

4. Post-Incident Activity

A central part of the NIST incident response methodology is learning from previous incidents to improve the process.

You should ask, investigate and document the answers to the following questions:

  • What happened, and at what times?
  • How well did the incident response team deal with the incident? Were processes followed, and were they sufficient?
  • What information was needed sooner?
  • Were any wrong actions taken that caused damage or inhibited recovery?
  • What could staff do differently next time if the same incident occurred?
  • Could staff have shared information better with other organizations or other departments?
  • Have we learned ways to prevent similar incidents in the future?
  • Have we discovered new precursors or indicators of similar incidents to watch for in the future?
  • What additional tools or resources are needed to help prevent or mitigate similar incidents?

Use your findings to improve the process, adjust your incident response policy, plan, and procedures, and feed the new data into the preparation stage of your incident response process.

Building Your Own Incident Response Process: Incident Response Plan Templates

One more thing that can save you time as you prepare an incident response plan is to use ready-made templates shared by other organizations. You can adapt these templates to your specific needs.

The following templates can help you get a head start on your incident response plan:

  • Cynet Incident Response Plan Template – includes team responsibilities, testing, process overview, and checklist. Download .DOC file
  • IltaNet Incident Response Plan – includes team responsibilities, incident notifications, types of incidents and classification procedure, and definition of breach. Download .ASHX file
  • Thycotic Incident Response Template – includes roles, responsibility and contacts, threat classification, incident response phases and actions in each phase. Get .DOC file
  • Sysnet Security Incident Response Plan Template – includes roles and responsibilities, external contacts, incident response steps, and types of incidents. Get .DOC file*
  • California Government Department of Technology Incident Response Plan – includes 17-step incident response procedure, with more detailed plans for specific incident types. Download .DOC file
  • I-Sight Incident Response Template – includes incident definitions and examples, roles and responsibilities, incident response stages and procedures. Get .DOC file*

(*) Website requires registration

Learn more in our detailed guide to incident response plan templates

Real Life Incident Response Examples

When building an incident response plan, it is useful to see examples of real plans created by other organizations which have been fine-tuned over time based on their experience. See the following examples of incident response plans by leading organizations:

OrganizationExample Plan IncludesLink to Example
U.S. Department of Homeland SecurityRoles and responsibilities, core incident response capabilities, coordinating structureshttps://us-cert.cisa.gov/sites/default/files/ncirp/National_Cyber_Incident_Response_Plan.pdf
Carnegie Mellon UniversityDefinitions of incidents, roles and responsibilities, incident response phases, insider threat guidelineshttps://www.cmu.edu/iso/governance/procedures/docs/incidentresponseplan1.0.pdf
University at BuffaloIncident response contact information, incident classification and impact, reporting and notificationshttp://www.buffalo.edu/ubit/policies/guidance-documents/incident-response-plan.html
Write State UniversityIncident response steps, security tools, checklist upon detection of intrusionhttps://www.wright.edu/information-technology/policies/incident-response-plan
University of Oklahoma Health Sciences CenterPCI DSS incident response plan including roles and responsibilities, incident response phases, detailed workflow diagramhttps://it.ouhsc.edu/policies/documents/infosecurity/PCI%20DSS%20Security%20Incident%20Response%20Plan%20Final.pdf

Best Practices for Building Your Incident Response Plan

Create a simple, well-defined process

An incident response plan, even if it is very well thought out, must be simple and crystal clear to be effective. Keep details, procedures and explanations to a minimum to ensure that staff can very easily follow the plan in the urgency and confusion of a real security incident.

Create a communication strategy

Clarify who needs to be informed of a security breach, which communication channels should be used and what level of detail should be provided. There should be clear guidelines on how to inform operations, senior management, affected parties inside and outside the organization, law enforcement, and the press. This is a commonly overlooked part of the incident response process.

Use an incident response plan template

Don’t reinvent the wheel. Always start your incident response plan from a template created by others in the industry and adapt it to your specific needs. For example, you can start from this template provided by TechTarget which includes incident scope, planning scenarios, logical sequence of events for incident response, team roles, notification and escalation procedures.

Put your incident response plan to the test

Conduct realistic drills and exercises to see how the incident response plan is carried out in practice, and be ready to adapt the plan according to lessons learned. Test your tools to ensure they are able to detect an attack as early as possible in the kill chain, and ensure the team can identify a threat and contain it before sensitive data leaves your network.

Use a centralized approach

Organizations should not be logging into multiple tools and correlating information between them during the urgency of an attack. Processes and tooling should support a centralized incident response process where an analyst can view all the information about an incident in one place.

Put incident response technology in place

Incident response tools/technology provides you with the means to eradicate discovered malicious presence and activity from your environment as well as optimize response workflows by automating repetitive tasks. They can:

  • Provide a complete picture of an attack operation, correlating data from endpoints, user behavior and network communications
  • Enable remote manual response by security analysts, such as blocking users, killing processes, restarting hosts, deleting files or changing password.
  • Enable automated response, for example automated quarantine of an endpoint when malware is discovered, or automatically stopping a malicious process that encrypts or deletes large numbers of files.

Cynet’s 24/7 Incident Response Team

Cynet has an outsourced incident response team available to anyone including small, medium and large organizations. The incident response team provides professional security staff who are equipped to carry out fast, effective incident response activities.

Cynet can deploy the Cynet security platform in just minutes across hundreds to thousands of endpoints. They can scan, identify, analyze and attend to threats before any harm is done. The Cynet incident response team can assist with:

  • 24/7 incident response—such as identification, containment, eradication and recovery
  • Deep forensic investigations—collecting data to determine the scope of an attack and who is accountable
  • Threat hunting—analyze security data to proactively identify advanced threats
  • Malware analysis—examining malware in a sandbox to see its components and how to remediate it

Contact Cynet for immediate help

For emergency assistance from Cynet’s security experts, call them now at US 1-(347)-474-0048, International +44-203-290-9051, or complete the form below.

What is Incident Response?

Incident response is a structured process organizations use to identify and deal with cybersecurity incidents. Response includes several stages, including preparation for incidents, detection and analysis of a security incident, containment, eradication, and full recovery, and post-incident analysis and learning.

What is NIST?

The National Institute of Standards and Technology is an agency operated by the USA Department of Commerce, that provides standards and recommendations for many technology sectors.

Within NIST, the Information Technology Laboratory (ITL) is responsible for developing standards and measurement methods for IT, including information security. ITL developed an influential model for incident response, the Computer Security Incident Handling Guide (Special Publication 800-61). In this article we’ll cover the basics of the NIST incident response recommendations and how you can leverage them for your organization.

NIST Recommendations for Organizing A Computer Security Incident Response Team (CSIRT)

The NIST Computer Security Incident Handling Guide provides in-depth guidelines on how to build an incident response capability within an organization. It covers several models for incident response teams, how to select the best model, and best practices for operating the team.

Incident Response Team Models

NIST offers three models for incident response teams:

  • Central—centralized body that handles incident response for the entire organization.
  • Distributed—multiple incident response teams, with each one responsible for a physical location (e.g. branch office), a department or a part of the IT infrastructure
  • Coordinated—a central incident response team that works together with distributed incident response teams, without having authority over them. The central team serves as a knowledge center and offer assistance with complex, critical, or organization-wide incidents.

Within each of these models, staff can be employees, partially outsourced, or fully outsourced. Employees can also be full- or part-time.

Selecting a Team Model

NIST provides several considerations for selecting an incident response model:

  • Does incident response need to be available 24/7? Do incident responders need to be on-site or is phone contact sufficient? Real-time availability and on-site presence is best because it allows immediate response to an incident, which can prevent damage.
  • Should staff be part time or full time? Part-time employees can be used to make up a virtual incident response team, like a volunteer emergency response unit. When an incident occurs, the IT help desk can be the first point of contact, they can perform an initial investigation, rapidly call on incident response team members, and whomever is available can respond to the incident.
  • Should staff be security experts? What level of expertise i needed? Incident response requires broad knowledge of IT systems, communication protocols, attack techniques, and also the organization’s environment, systems and procedures. Outsourced teams typically have stronger security expertise, but employees have a better understanding of the IT environment, normal vs. malicious behavior, and of which systems are critical, etc.
  • How much will the incident response team cost? Because incident responders need special expertise, and are often required to be on-site 24/7, they can represent a major investment. Managed Security Service Providers (MSSP) can also be costly, and there is an additional cost of security tooling, physical facilities and secure communication methods.

How to Organize Incident Response

The NIST Incident Response Guide provides several guidelines for organizing and operating an incident response unit.

Establish a formal incident response capability
Even if your organization is small, take incident response seriously and establish a formal incident response body. Even if it is a virtual incident response team with part-time staff, defining this team and giving it authority and responsibility will dramatically improve your capability to respond when a cyberattack strikes.

Create an incident response policy
This is a precursor to the incident response plan, which lays out the organizational framework for incident response. It specifies what is considered a security incident, who is responsible for incident response, roles and responsibilities, documentation and reporting requirements.

Define an incident response plan
According to NIST methodology, an incident response plan is not merely a list of steps to perform when an incident happens. It is a roadmap for the organization’s incident response program, including short- and long-term goals, metrics for measuring success, training and job requirements for incident response roles.

Develop incident response procedures
These are the detailed steps incident response teams will use to respond to an incident. They should be based on the incident response policy and plan and should address all four phases of the incident response lifecycle: preparation, detection & analysis, containment, eradication and recovery, and post-incident activity.

The NIST Incident Response Cycle

NIST defines a four-step process for incident response, illustrated in the diagram below. The NIST process emphasizes that incident response is not a linear activity, starting when an incident is detected and ending with eradication and recovery. Rather, incident response is a cyclical activity, where there is continuing learning and improvement to discover how to better defend the organization.

incident response process

Source: NIST

After every incident there is a substantial effort to document and investigate what happened during the incident, to feed back to earlier stages and to enable better preparation, detection and analysis for future incidents.

There is also a feedback loop from the containment and eradication step to detection and analysis—many parts of an attack are not fully understood at the detection stage and are only revealed when incident responders “enter the scene”. These lessons can help the team detect and analyze attacks more fully the next time around.

The Four Steps of NIST Incident Response

1. Preparation

To prepare for incidents, compile a list of IT assets such as networks, servers and endpoints, identifying their importance and which ones are critical or hold sensitive data. Set up monitoring so you have a baseline of normal activity. Determine which types of security events should be investigated, and create detailed response steps for common types of incidents.

Cynet 360 provides all the core capabilities that are required for sound incident preparation, including a centralized visibility interface showing all endpoint configurations, process execution, installed software, network traffic and user activity.

2. Detection and Analysis

Detection involves collecting data from IT systems, security tools, publicly available information and people inside and outside the organization, and identifying precursors (signs that an incident may happen in the future) and indicators (data showing that an attack has happened or is happening now).

Analysis involves identifying a baseline or normal activity for the affected systems, correlating related events and seeing if and how they deviate from normal behavior.

An integrated security platform like Cynet 360 can do this for you, automatically identifying behavioral baselines, detecting anomalies that represent suspicious behavior, and collecting all relevant data across networks, endpoints and users to help you investigate it.

Learn more about how Cynet 360 provides detection capabilities against a wide range of attack vectors with its natively integrated EDR, UBA, Network Analytics and Deception modules.

3. Containment, Eradication, and Recovery

The goal of containment is to stop the attack before it overwhelms resources or causes damage. Your containment strategy will depend on the level of damage the incident can cause, the need to keep critical services available to employees and customers, and the duration of the solution—a temporary solution for a few hours, days or weeks, or a permanent solution.

As part of containment, it is important to identify the attacking host and validate its IP address. This allows you to block communication from the attacker and also identify the threat actor, to understand their mode of operation, search for and block other communication channels they may be using.

Cynet 360 can help you take remote manual action to contain security incidents, including stopping malicious processes, deleting files, resetting passwords and restarting affected devices. It can also perform automatic containment actions such as stopping rapid encryption of files or automatically isolating endpoints infected by malware from the network.

Cynet response orchestration capabilities provide the means to terminate attackers’ presence and activity from all parts of the environment: infected hosts, malicious files, compromised user accounts and attacker-controlled traffic. Learn more about Cynet 360’s incident containment capabilities.

In the eradication and recovery stage, after the incident has been successfully contained, you should act to remove all elements of the incident from the environment. This might include identifying all affected hosts, removing malware, and closing or resetting passwords for breached user accounts.

Finally, once the threat is eradicated, restore systems and recover normal operations as quickly as possible, taking steps to ensure the same assets are not attacked again.

4. Post-Incident Activity

A central part of the NIST incident response methodology is learning from previous incidents to improve the process.

You should ask, investigate and document the answers to the following questions:

  • What happened, and at what times?
  • How well did the incident response team deal with the incident? Were processes followed, and were they sufficient?
  • What information was needed sooner?
  • Were any wrong actions taken that caused damage or inhibited recovery?
  • What could staff do different next time if the same incident occurred?
  • Could staff have shared information better with other organizations or other departments?
  • Have we learned ways to prevent similar incidents in the future?
  • Have we discovered new precursors or indicators of similar incidents to watch for in the future?
  • What additional tools or resources are needed to help prevent or mitigate similar incidents?

Use your findings to improve the process, adjust your incident response policy, plan, and procedures, and feed the new data into the preparation stage of your incident response process.

Cynet’s 24/7 Incident Response Team

Cynet has an outsourced incident response team that anyone can use, including small, medium and large organizations. The incident response team provides professional security staff who are equipped to carry out fast, effective incident response activities.

Cynet can deploy the Cynet security platform in just minutes across hundreds to thousands of endpoints. They can scan, identify, analyze and attend to threats before any harm is done. The Cynet incident response team can assist with:

  • 24/7 incident response—such as identification, containment, eradication and recovery
  • Deep forensic investigations—collecting data to determine the scope of an attack and who is accountable
  • Threat hunting—analyze security data to proactively identify advanced threats
  • Malware analysis—examining malware in a sandbox to see its components and how to remediate it

Contact Cynet for immediate help
For emergency assistance from Cynet’s security experts, call them now at US 1-(347)-474-0048, International +44-203-290-9051, or complete the form below.