How to create an incident response plan: A guide for MSPs

When it comes to responding to a cyber incident, every second counts. Developing a comprehensive incident response plan before an incident occurs ensures that you’ll be prepared to take control of the situation, respond appropriately and take swift action to limit the impact of the attack.

In this blog post, we’ll explore the top five things you need to think about when developing an incident response plan.

Step 1: Understand the client

There’s no one-size-fits-all answer when it comes to cybersecurity. There are dozens of ingredients that go into creating a tailor-made security strategy for your clients – security preferences, data priorities, budget, IT infrastructure, compliance requirements, and so on – and it’s a similar story when it comes to building an incident response plan.

During this preparation phase, take the time to plot out the client’s IT environment and identify the most important assets. Think of it as a risk assessment. Which systems, services, and applications are most critical to restore in the event of an incident? Which data repositories are most important, both to the client and to a potential attacker? What is the accepted level or risk given technological and/or budgetary constraints?

Be objective in your assessment and encourage your client to be honest and forthcoming about potential vulnerabilities that may exist. Getting a better understanding of your client’s IT systems and their mission-critical assets is crucial for making the most effective use of your response resources.

Step 2: Build your team

After carrying out a risk assessment of the client, it’s time to define your team – that is, the group of people who will be responsible for responding to an incident and executing the response plan. While some MSPs may be able to field a response team using only in-house resources, most MSPs will probably need to enlist the services of external specialists to fill in the gaps.

Being able to coordinate response personnel is critical. As an MSP, your responsibilities during an incident may primarily revolve around organizing the response rather than executing the response yourself. You’ll also act as the liaison between your client and the specialists who comprise your response team, managing the technical aspects of the response and clearly communicating progress and response options to the client.

Step 3: Define response procedures

Once you’ve assembled your team, you’ll need to define your response procedures. These are the step-by-step actions that need to be taken in the event of an incident to remediate the problem and restore your client’s systems to normal operation. You’ll also need to define timeframes, including response and resolution times.

Given that organizations may generate hundreds or even thousands of security alerts each day, MSPs should aim to automate incident response tasks wherever possible (automated response tools and procedures should also be detailed in the incident response plan).

However, while automated tools can help alleviate repetitive tasks to a certain extent, manual, human intervention will be necessary at times to investigate alerts and analyze computer-generated data. As such, an incident response plan must specify which members of the response team will be notified, when in the response chain they’ll be contacted and the communication channels that will be used with stakeholders.

Response procedures should always be tailored to the needs of the individual client, but may include the following steps:

• Notify the appropriate members of your response team and the client’s stakeholders.
• Assess the situation.
• Collect as much information as possible.
• Determine the extent of the incident.
• Isolate and evaluate the affected systems.
• Create backs up of the affected systems.
• Preserve logs and details of the breach for further analysis.
• Remediate the incident.
• Restore the affected systems and monitor for stability.
• Address the vulnerability that allowed the incident to occur.
• Assist the client with the technical aspects of public statements or data breach notifications, which may be legally required.

Step 4: Remember to protect yourself

It’s important to remember that an incident response plan shouldn’t be limited to helping your clients – it should also include the steps you need to take to protect your own business. Depending on the nature of the incident, there may be scope for legal liability and/or the potential for reputational harm, particularly because the businesses that an MSP is responsible for protecting are often many times larger than the MSP itself. As such, your incident response plan must include items such as:

• The contact details of your insurance provider.
• The contact details of your legal team.
• The contact details of law enforcement.
• How to communicate with your clients (e.g. who to contact, the preferred method of contact, timeframes, etc.).

Step 5: Test, test, test

Writing an incident response plan is one thing – executing the plan in the heat of the moment is a whole different ball game.

So, after developing your incident response plan, it’s time to put it to the test. Choose a cyber event – selectively or at random – and follow your processes exactly as they’re laid out in the response plan. Tabletop exercises such as this are useful for getting a better understanding of your team’s ability to remediate an incident under pressure and can reveal potential flaws in the response chain Aim to test, review and update your incident plan on a regular basis, and at least annually.

Comprehensive post-mortems should be conducted after responding to live threats to identify areas of improvement. Any insights gathered during the incident and the post-mortem should be applied to the incident response plan.

Step 6: Keep the plan up to date

The threat landscape is always shifting and your clients’ needs are continuously evolving. With this in mind, it’s important to note that an incident response plan should not be treated as a static document and should be frequently updated to reflect recent changes that may affect your response processes.

For instance, you may need to update the contact information listed in the response plan if a stakeholder leaves the company, or amend your processes if you incorporate a new forensic tool into your response procedures.

Outdated or incorrect information can greatly hinder your ability to effectively respond to and contain threats, so review your response plans on an ongoing basis to minimize the risk of discrepancies.

Conclusion

When it comes to cybersecurity, it’s always good practice to prepare for the worst. While every effort should be made to keep a client’s system secure, the reality is that absolute security is impossible. When a breach occurs, a thorough incident response plan is crucial for ensuring that you and your clients are well-equipped to deal with the situation, neutralize the threat and get the affected systems back up and running as quickly as possible.