• United States




What is incident response? And 6 steps for building a robust IR plan

Sep 20, 20186 mins
CybercrimeData and Information SecurityData Breach

While a lot of energy is put it into avoiding security breaches, it’s not always possible. A solid incident response plan can restrict damage, reduce recovery time and limit the associated costs.

12 incident response life preserver survival disaster recovery
Credit: Getty Images

Most InfoSec professionals are firmly focused on prevention. We build systems and adopt tools to help safeguard against phishing attacks and ransomware and all the other myriad threats that businesses face on a daily basis. But what we often end up with is a mish-mash of different technologies that have not been integrated or configured properly.

The potential cost of a data breach drives rapid adoption of new software, but the frenzied firefighting approach prevents us from stepping back and taking in the big picture. Before we can fully leverage the systems at our disposal, we must accept that incidents will occur and build a clear incident response plan that can be relied upon to guide us out of danger.

Incident response definition

Incident response is how an organization responds to a data breach or cyberattack. The aim is to limit potential damage and ensure a swift resumption of normal operations.

While the global average cost of a data breach is $3.86 million and it takes 69 days on average to contain a data breach, according to the Ponemon Institute, companies that were able to respond quickly and contain a breach in less than 30 days saved more than $1 million. Clearly, a proper incident response plan makes a lot of business sense. Exercises throughout the year help train your muscle memory to work through the breach and response.

How to create an incident response plan

An incident response plan can provide a solid foundation for your future security efforts. Here’s how to get started.

1. Assign clear responsibilities

Start with who should oversee the development of the incident response plan itself. Whether it’s the CIO or someone else, they’re going to need to inform all the relevant stakeholders, gather input, and assign roles. Central to this is the drafting of a security incident response team (SIRT) that will be responsible for detection, classification, notification, analysis, containment, eradication, documentation, and post incident activity.

As the incident response plan is developed you may also need the participation of senior management, attorneys, human resources, regulatory bodies, law enforcement, cyber consultants, and maybe a PR firm. There are many moving parts to coordinate if you want to ensure that incidents are dealt with swiftly and efficiently.

2. Define your risk tolerance

There’s no one size fits all answer here. You must work out what is critical data, what key functionality your company requires to do business, and prioritize your efforts to focus them in the right places. False positives and alerts that are perceived as unimportant can lead to alert fatigue and that’s when things start getting ignored and slip through the cracks.

It’s important to be pragmatic here and identify, with the help of stakeholders, where the greatest risks for your business lie. Map out your critical functions and operations in full.

3. Classify events

With roles and risks defined, you can move on to incident classification. When an incident develops, you need to be able to classify it, so that you know precisely what action to take.

A high-risk incident could result in critical systems becoming unusable or the loss of control over confidential or restricted information. A medium risk might denote the installation of malwarethat could lead to compromise in the near future. A low risk might be a prerequisite to a medium risk, such as someone failing to adhere to policy and clicking a phishing link in an email.

Classifying risks allows you to prioritize them, but each incident should also be fully documented, so you have a basis for investigation and audit should it be required in the future.

4. Set explicit instructions

With a system in place to uncover and classify incidents, you can set clear procedures that enumerate in detail what every person involved in an incident should do. This starts with the rules on reporting but includes everything from fixed time scales for investigation to the steps needed to remediate the problem. Having clear procedures in place removes room for doubt or bad decision making.

Your procedures should spell out what needs to happen when a suspected incident is uncovered. After it’s reported to the right people, the SIRT can investigate and analyze the potential scope, including which accounts, devices, and systems have been compromised. Before it can be effectively contained, you must know how far it has spread. During this phase, it’s vital to avoid deleting potential evidence that might reveal the root cause of the incident and help you prevent a reoccurrence.

View the explicit instructions that you draft as part of your procedures as living documents. They are simply your best guess right now at how to uncover and contain an incident.

5. Prioritize eradication and recovery

As part of working out your risk tolerance, you’ve identified critical systems. These critical systems that enable your business to run should be fully backed up, so you can get them up and running again swiftly. For the rest of your business functions, you need to perform a kind of triage to work out the right order for eradication and recovery.

It’s also very important to isolatethe infected business units and make sure that stakeholders are kept in the loop on realistic recovery time. When it comes to restoring normal operations, bear in mind that you must know what a normal state looks like. If you haven’t documented that beforehand, then you may struggle at this stage.

6. Learn from every incident

The incident response plan is not written in stone and every incident is a learning opportunity. Once it has been dealt with, confirm the root cause, analyze, document, measure, and retest.Assess the incident response procedure used and how it was carried out. This process enables you to make recommendations for better future response and prevention of a reoccurrence.

If you use incident analysis to find flaws or deficiencies in your detection, notification procedure, containment, eradication, or any other part of the process, then you can use that information to strengthen your incident response plan. It’s a system for continuous improvement that will significantly boost your security over time.

Ultimately, security incidents are inevitable and beyond your control to an extent, but how you react to them is entirely up to you.


Michelle Drolet is a seasoned security expert with 26 years of experience providing organizations with IT security technology services. Prior to founding Towerwall (formerly Conqwest) in 1993, she founded CDG Technologies, growing the IT consulting business from two to 17 employees in its first year. She then sold it to a public company and remained on board. Discouraged by the direction the parent company was taking, she decided to buy back her company. She re-launched the Framingham-based company as Towerwall. Her clients include Biogen Idec, Middlesex Savings Bank, PerkinElmer, Raytheon, Smith & Wesson, Covenant Healthcare and many mid-size organizations.

A community activist, she has received citations from State Senators Karen Spilka and David Magnani for her community service. Twice she has received a Cyber Citizenship award for community support and participation. She's also involved with the School-to-Career program, an intern and externship program, the Women’s Independent Network, Young Women and Minorities in Science and Technology, and Athena, a girl’s mentorship program.

Michelle is the founder of the Information Security Summit at Mass Bay Community College. Her numerous articles have appeared in Network World, Cloud Computing, Worcester Business Journal, SC Magazine, InfoSecurity,, Web Security Journal and others.

The opinions expressed in this blog are those of Michelle Drolet and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author