Don’t panic! Stay focused on the execution of incident response for best results

| By:
Bryan Lowe; Sr GRC Consultant

When responding to an incident, it is essential to manage and address every situation in a manner that limits damage to the environment and reduces overall recovery time and costs to the organization. In other words, don’t panic! 

 As a general practice, many MSPs already have an IT incident response plan to handle disruption to their services or the business operations of their end clients. In contrast, many SMB managed service providers are ill-equipped to craft and implement an incident response plan. 

It is a common misconception that to effectively defend against the latest cyberthreats, an organization needs to staff a massive team of security analysts and incident responders equipped with a myriad of tools and utilities to properly detect, triage, contain, eradicate, and recover from a cybersecurity incident. While staffing and tooling are essential, having a well-defined response plan in place with the appropriate people responding with the right tools and required training to succeed remains crucial.  

What are the responsibilities of an incident response team?  

The general goal of an incident response team is to manage and coordinate resources and activities during a cybersecurity incident to minimize the overall impact and restore business operations as soon as possible. To achieve this, an incident response team manages and orchestrates several critical tasks through defined business processes before, during, and after an incident.  

With that goal in mind, creating an incident response plan does not have to be a long, drawn-out, daunting process. Start with simple security policies and standards that feed into a response plan. Then, take a systematic approach for expanding deeper into areas as needed to better prepare for, detect, contain, and recover from a wide range of incidents, such as: 

  • Account credential compromise 
  • Data breach of sensitive / protected data 
  • Observed lateral movement across networks and hosts 
  • Phishing / pretexting 
  • Ransomware / encryption extortion 
  • Remote access breach 

Data, if compromised, could place the business at risk in the event of data loss or theft. From an investigation and analysis perspective, an incident response team must triage and document an incident’s scope, priority, and impact. This determination originates from a pre-existing inventory of critical business hosts/servers/networks/applications/services and the transmission and storage of sensitive data. Through the process, an incident response team will orient observable events to make logical connections, collect data, and establish the proper context of the incident. Doing so allows the team to select the best response tactics to contain and minimize any damage and provide options for the best possible path towards recovery.  

How does an incident response team “triage” an incident?  

As a standard practice during the initial triage process, hold discussions surrounding the notification and involvement of a cyber insurance provider. It is best to review and discuss:  

  • Insurance requirements with the impacted client’s provider before proceeding. Some cyber insurance policies may be voided when changes are made without providing advanced notice or taking unauthorized actions.
  • Insurance stipulations with all stakeholders and incident responders before proceeding, as such stipulations will dictate how and if the response team can proceed with further isolation, containment, and recovery activities.  
  • The business continuity or disaster recovery plan may require specific requirements and action items from certain policies, the client, the MSP, or third-party partner organizations.  

Do not underestimate the value of checklists for consistently executing incident response actions and procedures. Checklists as tools can guide an experienced incident responder to work from documented procedures surrounding the forensic collection of logs and artifacts from critical systems from an operating system (OS) perspective (Microsoft Windows or Linux variant) or service functionality (web server, mail server, database server, domain server, DNS, etc.). When roles involve working under high stress and with complex issues, incident response experts rely on checklists to: 

  • First, protect against errors of ignorance (mistakes made because one does not know enough) 
  • Second, to protect against errors of ineptitude (mistakes made because one does not make appropriate use of what they know).  

Necessary steps can be skipped or forgotten without a simple, concisely written guide to follow.  

Why does an incident response team need to collect data?  

During an incident, the data collection and analysis will support business leaders and key stakeholders in making informed business decisions. Security analysis is comparable to detective work involving chasing leads, arriving at dead ends, and disproving assumptions to distill the verifiable facts surrounding the root cause and tactics used during the incident. Capturing and documenting artifacts, evidence, and actions taken throughout the incident response process allows for the opportunity to provide objective reports and updates to stakeholders across the organization so that decision-makers can respond and act appropriately no matter the scope of the incident.  

Why is documenting the incident response communication process important?  

A concrete and documented communications plan with an emergency contact checklist is essential for incident response standard operating procedures. Never underestimate the time-saving value of documenting stakeholder contact information and knowing whom to call, when to call, and what to say when communicating details and making requests during an incident.  

Stakeholders likely include business owners, senior management, business partners, technology vendors, customers, and legal counsel. With the involvement of many diverse responsibilities, roles, and individual personalities, the addition of business politics, resistance, negotiation, and ignorance may blend into the overall response activities. Open communication promotes trust while strengthening visibility throughout the organization and across stakeholders. During a crisis, it is vital that all stakeholders feel they can communicate directly with senior leadership and receive important situational updates.  

What does an incident response team do after an incident?  

The incident response team should conduct a full review of actions with a timeline and a summary report of the incident to determine any additional post-incident analysis of lessons learned from the response. Within two weeks, after an incident is fully isolated, remediated, and recovered, the MSP incident response team can hold an after-action meeting with the client and stakeholders to discuss findings and any items learned from the incident. Some questions to be considered and answered during this phase are:   

  • When was the cyber incident first detected?  
  • Who detected the cyber incident?  
  • Who reported the cyber incident?  
  • Who was the cyber incident reported to?  
  • How was the cyber incident contained?  
  • What activities throughout the incident did the response team perform well?  
  • What areas have been identified for the Incident Response Team to improve?  
  • What changes or security improvements can be made across the impacted organization to prevent similar cyber threats?  
  • What employee training or security awareness items should be addressed?  

Note that when you make changes to the security policy, technology, or business operations, follow up with appropriate updates to the incident response plan, procedures, and checklist.  

Holding a full debrief meeting with the client and necessary stakeholders will allow the MSP to help the client defend against similar attacks. Work with them to create a roadmap for implementing a security plan respectful to the client’s budget.   


With a combination of proactive security management and monitoring of system environments, an incident response plan and supporting procedures can easily be incorporated into an overall business. For an MSP, having an incident response plan developed and rehearsed in advance of an incident is vital to limiting damage and disruption to customer business operations. It is good practice to periodically conduct reviews and perform tabletop scenarios of your incident response plans and response activities to recognize and resolve any shortcomings before an incident happens.  

And remember, Don’t panic! If you stay focused on your preparation and execution of responding to cyberthreats and incidents, you’re more likely to come out of an incident with a best-case-scenario result. 

For more information about ConnectWise Incident Response Services or how ConnectWise can assist your MSP with service offerings, please review the following: