Cybersecurity Ventures expects cybercrime costs to grow about 15% globally between 2021 and 2025. At this rate, the company estimates that by the end of this time period, these costs will reach as much as $10.5 trillion.

So as you can see, when it comes to running a business, protection against cybercrime is essential. Investing in a cybersecurity incident response plan will help you better organize your information technology (IT) programs and save you revenue in the long term. As the cliche saying goes, “Prevention is the best medicine.” As it turns out, a robust cybersecurity incident response plan might be the best “medicine” for breach prevention that an organization can have.

Taking into account the results of a risk assessment will help you learn how to prevent security breaches. And even if you cannot prevent all mishaps, utilizing your incident response plan can help you quickly detect issues, help to minimize any losses, reduce remaining vulnerabilities, and restore your IT services.

Implementing cybersecurity incident response plans and making sure to continually monitor for attacks are both key for defending your sensitive data… and it’s no secret that your confidential information has great value among hackers. Names, credit card numbers, social security numbers, and more (if left undefended) can result in identity theft or fraud.

Take for example Marriott Hotels. A breach of their Starwood guest reservation database resulted in the exposure of up to 500 million people in 2018. Although discovered in 2018, Marriott says the breach actually began in 2014. You don’t want to be that company that has to make up for years of stolen data.

So, what exactly is a cybersecurity incident response plan? I don’t want to spoil that quite yet. But, in this blog, I’ll define what an incident response plan is and provide you with 66 interview questions for your incident response.

What is an Incident Response Plan?

A cyber incident response plan is a document that helps companies understand what they should do if a security incident occurs. If you’re an organization that has cyber-related assets, you should be paying attention. As I alluded to earlier, having a well-written incident response plan can save you from huge losses!

Your incident response plan should cover these overarching procedures…

Protect
Monitor
Analyze
Detect & Respond

After a detected breach occurs, the focus of your team should be on response and recovery. This step includes preventing further damage, restoring infrastructure integrity, reclaiming assets, and reevaluating the effectiveness of your incident response plan. Asking the appropriate questions after a security breach can help you get to the root of any vulnerabilities in your system and/or policies that need updating.

Incident Response Plan Questions

No two incident response plans are going to be the same, but the basic goal is simple: fast detection and an even faster response. Questions following a security incident may vary across companies due to different elements such as network configurations, precedence, and processes.

NIST’s Computer Security Incident Handling Guide offers companies a solid foundation to build their individualized incident response plan.

The guide contains six phases, let’s take a look:

Preparation
Identification
Containment
Eradication
Recovery
Lessons Learned

Let’s take a deeper dive into some must-have incident response questions to ask during the post-incident analysis, categorized under each of these phases.

Step 1: Preparation

Starting off with a trick question: What are the questions one should ask that have to do with the Preparation phase of the incident report? There really aren’t any. At least, nothing that isn’t better suited to ask under the other phases.

The Preparation phase is mainly good for ensuring that systems, networks, and applications are secure on a day-to-day basis. This part of the program is better thought of as how to prepare to handle incidents/ prevent incidents before they happen.

The rest of the phases are more suited to when an incident actually happens.

But, don’t worry. This section isn’t only about me being facetious.

Here are a few interview questions you could ask yourself and your incident response team during the preparation stage:

How do we prioritize the protection of assets in case of a security incident?
What steps do we take to ensure that we train all of our employees on incident response protocols?
How do you establish communication channels with external entities before an incident occurs?

External entities include law enforcement, incident response teams, and other stakeholders.

What tools do you use for ongoing monitoring of your systems for potential security incidents?
How often do you update your incident response plan to ensure it remains current and effective?
How do you test your incident response plan to ensure its effectiveness?
What is your approach to managing and maintaining incident response documentation and records?
What is your policy for managing incident response-related information, such as sensitive data or evidence?
How do you ensure that your incident response team is available and prepared to respond to a security incident at any time?
How do you handle incidents that cross geographical boundaries, such as incidents affecting remote workers or subsidiaries?

As you can likely tell from the questions posed, the preparation phase is ongoing. That statement isn’t a new, groundbreaking discovery. You likely already know that achieving a workplace that’s 100% “secure” isn’t attainable. It’s about constant improvement.

The point I’m trying to make is that NIST’s Computer Security Incident Handling Guide is less of a step-by-step process and more of a cycle. Also, the preparation stage exists within each of the next steps. I alluded to that earlier in this section, but from now on you’ll see a section with interview questions labeled “Preparation” and “Post Incident”.

Step 2: Identification

Identification means that the incident team is now analyzing and validating the severity of an incident reported. Once verified that there is a security breach of some kind, the team must conduct an initial analysis to determine the incident’s scope.

This scope includes involved networks, systems, or applications. As well as who or what’s responsible for the incident and how it’s occurring. During this phase of your response plan, your security team needs to investigate all details related to the incident. Here are some questions to include in your identification response checklist:

Identification - Preparation

What are some indicators of a potential security incident, and how do we identify them?
How do we assess the severity and scope of a security incident once it’s identified?
How do we ensure to report all incidents to the appropriate authorities and what steps do we take during that reporting process?
How do we determine what caused a security incident once it’s identified?
How do we ensure that we’ve identified all affected systems, applications, and data?
How do we identify who’s responsible for a security incident?
How do we communicate the details of a security incident to stakeholders?
Do we use any tools that help us identify security incidents?
How do we determine whether an incident is a false positive or an actual security threat?
What are some common mistakes that other organizations made during the identification phase?

Identification - Post Incident

Who reported/discovered the security incident?
When was the security incident discovered/reported?
Where was the security incident located/discovered?
How does this incident impact our business operations?
In regards to our network and applications, what is the full extent of this incident?

Step 3: Contamination

Contamination planning is essential to control an infection’s spread. For example, you want to isolate affected systems before having malware spread to crucial systems or databases.

The Contamination phase often comes down to making important decisions quickly such as shutting down a system, disconnecting from a network, etc.

Of course, these difficult decisions are easier with predetermined strategies and procedures in place.

Here are some questions to assist in stopping any threat(s) from creating additional damage:

Contamination - Preparation

How do we isolate and contain a security incident?
How do we prioritize the containment of affected systems and applications during an incident?
How do we ensure that what we contain doesn’t interfere with the collection of evidence?
How do we ensure that we’ve successfully contained the incident before moving on to the eradication phase?
How do we determine the extent of the damage caused once we’ve contained a security incident?
How do we ensure that the containment measures we implement don’t negatively impact our operations?
How do we document the steps taken during the containment phase for future reference and analysis?

Contamination - Post Incident

Is it possible to isolate the incident?

If we can isolate it, what steps will you take to do so?
If we cannot, document why and continue to work with the owner(s) to resolve the issue.

Are non-affected systems isolated from affected systems?
Did you create backups to protect crucial data?
Are there copies of the infected machines made for forensic analysis?
Have we removed malware (along with other threats) from the infected system?

Step 4: Eradication

Once you contain the incident, you may need to eliminate remaining components such as malware, or even identify and mitigate any vulnerabilities used. During the Eradication phase, you should identify all affected hosts in the organization. This way, you can remediate them.

Check out the following questions that can help you apply more permanent fixes to your infected system:

Eradication - Preparation

How do we remove the source of a security incident?
What steps do we take to thoroughly cleanse and restore affected systems before putting them back online?
How do we ensure that there aren’t any backdoors or other methods of re-entry?
How do you ensure that the eradication measures we implement don’t interfere with the collection of evidence?
What are the verification steps we have in place that ensure that the threat has been fully eliminated?
Do we use any tools to help us eradicate security incidents?
How do we ensure that the eradication measures we implement don’t negatively impact our operations?
How do we document the steps taken during the eradication phase for future reference and analysis?

Eradication - Post Incident

Have we applied new patches to infected systems?
Do we need to reconfigure any systems or applications?
Have we reviewed all possible entry points/closed them up?
Do we need any additional defenses to eradicate the threat(s)?
Have we eradicated all malicious activity from the affected systems?

Step 5: Recovery

The Recovery phase is all about restoring your systems to normal operation. You also should confirm these systems are functioning properly and remediate any vulnerabilities to prevent future incidents. This phase may look like restoring systems from backups, rebuilding systems, changing passwords, and more.

Make sure to also review your inventory list as the status and location of items can change.

Here are some baseline questions to incorporate during the Recovery phase:

Recovery - Preparation

How do we prioritize the systems and applications that need recovery?
How do we test restored systems and applications to ensure that they’re functioning properly again?
How do we ensure that the recovery measures we implement don’t introduce new vulnerabilities or risks?
How do we handle requests for access to recovered systems and data, such as from employees or customers?
How do we document the steps taken during the recovery phase for future reference and analysis?

Recovery - Post Incident

Where will recovery and backups pull from?
How will we deploy the affected systems back into production?
When will we deploy the affected systems back into production?
What testing/verifications do we need to do on the infected systems?
Is there documentation on the recovery completion steps/inventory check?

Step 6: Lessons Learned

The Lessons Learned phase helps your team to evolve in how they handle pending security threats. A Lessons Learned meeting is essential to reflect on not only the incident at large but also possible new threats, improved technology, how well the current intervention worked, and how to improve response time.

A report should cover all phases of your incident report process, remediated threats, as well as what needs to take place in the future to prevent similar infections. Consider these questions at your next Lessons Learned meeting to better tackle your post-incident analysis:

Have we recorded the necessary documentation throughout each incident report phase?
Did the response team receive clear authority to segment affected parts of the network to prevent the spread of malware?
Were critical systems and restricted data well-insulated from the attack?
Did the organization fully or partially recover lost items? If the answer is ‘partially recovered’, was it due to untested and/or corrupted backups?
What are some areas of improvement in the incident response process?

Conclusion

In order to efficiently respond to a security threat, make sure to use the most effective resources throughout the incident response cycle. Especially when it comes to the Lessons Learned phase, so you can better prepare for/protect against future attacks. Working with proactive controls will help your team develop better incident response planning, testing, and training.

But if you are aware of your obligations in making a data breach notification you can mitigate this stress and hopefully avoid the heavy fines that come with non-compliance.