Every organization plans for incidents. Very few are ready for the moment when an incident becomes an INCIDENT. 

That shift has very little to do with technology. It’s about impact, pressure and visibility. What begins as a technical issue can quickly expand into a full business crisis, affecting operations, finances, legal exposure and customer trust all at once. When that moment hits, your role changes immediately. You are no longer the person focused on fixing systems. You are now responsible for orchestrating the response. 

In my previous blog, Here comes the boom, we looked at the detect phase, the window where visibility and speed decide how far an incident spreads. This post picks up on the other side of that moment, when the incident is confirmed and the response begins. For MSPs, that might be your own business or a client’s. Either way, this is what leading incident response looks like when everyone is looking to you. 

Controlling the chaos 

In the early stages of an INCIDENT, the environment becomes unpredictable. Teams are under pressure, information is incomplete, emotions are high and decisions carry significant consequences. Your first responsibility is not speed but control. 

People will look to you for direction, and how you respond will shape the outcome. If you move too quickly without clarity, you risk making decisions that worsen the situation. If you allow stress and urgency to drive behavior, mistakes compound rapidly. In these moments, discipline matters more than urgency. 

Leading effectively means creating stability in an unstable environment. It means slowing conversations down, forcing clarity where there is confusion and keeping everyone aligned on what actually matters. This is where leadership outweighs technical skill. 

Bringing the right people together 

One of the most common mistakes organizations make is keeping the response contained within technical teams for too long. Once an incident escalates, it is no longer just an IT issue. 

At that point, the situation requires broader awareness and input: 

  • Legal counsel needs to be involved early to help navigate contractual as well as regulatory obligations and risk.  
  • Insurance providers may have specific requirements, such as forensic team engagement, that influence the response.  
  • Finance leaders need visibility into potential impact.  
  • Executive stakeholders must understand the situation well enough to make informed decisions. 

Delaying these conversations only increases risk. Early alignment ensures that decisions are deliberate and informed rather than reactive and fragmented. 

Creating a shared understanding 

Before any major recovery efforts begin, the organization needs a clear view of what is happening. Without this, different teams will operate on different assumptions, which leads to confusion and misalignment. 

The most effective way to establish clarity is by building a timeline. This should not be overly technical or complex. It needs to be something everyone involved can understand and trust. 

It begins with reconstructing what is known: 

  • When did the issue start? 
  • When was it discovered?  
  • What systems are affected? 
  • What actions have already been taken?  

From there, the focus shifts toward what comes next, including how recovery will unfold and which systems must be prioritized based on business needs. 

A well-maintained timeline becomes the foundation for decision-making. It provides context, reduces uncertainty as well as anxiety and keeps stakeholders aligned as new information emerges. 

The risk of moving too fast 

There is a natural instinct during an incident to restore systems as quickly as possible. Progress feels reassuring, and returning to normal operations becomes the immediate goal. 

However, moving too quickly can create new problems.  

  • Restoring systems without fully understanding the source of the compromise can lead to a bigger incident.  
  • Bringing services back online before addressing the original access point allows the attacker to regain control.  
  • In some cases, rushed recovery efforts can even destroy valuable evidence that would have helped explain what happened. 

True recovery requires patience and discipline. Before systems are brought back, there needs to be confidence that the threat has been contained and that the environment is safe. Without that assurance, recovery efforts risk resetting the incident rather than resolving it. 

The role of communication 

As the incident unfolds, communication becomes just as important as technical response. Inconsistent or unclear messaging can create confusion internally and erode trust externally. 

People across the organization will want updates, and how those updates are delivered matters.  

  • Information should be based on confirmed facts rather than assumptions. It should be consistent across teams so that everyone is working from the same understanding.  
  • Communications should also go out at scheduled intervals. Even an update that says “we have nothing new to report” means a lot to stakeholders and customers.  
  • Legal guidance should shape what is shared externally to ensure that regulatory and contractual obligations are met. 

Handled well, communication becomes a stabilizing force. Handled poorly, it can amplify the impact of the incident far beyond the technical issue itself and add to indirect costs such as reputational damage. 

Preparing before the incident 

What happens during an INCIDENT is largely determined by what was done before it. 

Organizations that respond effectively tend to have already invested in structure and preparation. That usually means: 

  • Plans that have been tested, not just documented 
  • Access to critical contact information even when systems are unavailable 
  • Detection capabilities that match their risk tolerance 
  • Backups that have been validated under realistic conditions 

Just as important, they understand their own business priorities. They know which systems matter most and in what order they need to be restored. 

In contrast, organizations that struggle are often forced to build this structure in real time, when decisions need to be made quickly and with incomplete information. 

Learning after the fact 

The INCIDENT does not truly end when systems come back online. That moment simply marks the transition from response to learning. 

A meaningful root cause analysis requires honesty and objectivity. The goal is not to assign blame but to understand what happened and why. It involves examining both successes and failures, identifying gaps in assumptions and determining what changes are necessary going forward. 

If the organization does not take the time to learn, the same weaknesses remain in place. Over time, that almost guarantees the incident will be repeated. 

Where to begin when everything feels uncertain 

In the middle of an INCIDENT, the volume of decisions and the pressure to act can feel overwhelming. The most effective approach is to return to a simple sequence. 

  1. Stabilize the situation and bring a sense of control to the environment.  
  2. Make sure the right stakeholders are involved and aligned.  
  3. Establish a clear understanding of what has happened by building a trusted timeline.  
  4. Only then, move containment and recovery move forward in a structured and deliberate way.  
  5. Once everything is stable, shift attention to learning and improving for the future. 

Throughout the process, communication must remain consistent and grounded in facts. 

When the worst day comes 

When an incident becomes an INCIDENT, success is not determined by tools or technology alone. It’s defined by how people respond under pressure. 

The organizations that navigate these moments well are the ones that remain disciplined, make thoughtful decisions, communicate clearly and commit to improving afterward. 

Incidents will happen. That part is unavoidable. 

How you respond with leadership and clarity is what defines the outcome. 

Learn from MSPs who have lived through it 

The best time to hear how other MSPs handled their worst day is before yours. The CyberMSP Community is a vendor-agnostic peer network where MSPs share how they’ve responded to real incidents, what they’d do differently and how they prepare their teams and clients. 

Join the CyberMSP Community. 

Written by Roddy Bergeron Technical Fellow, Cybersecurity @ Sherweb

Roddy Bergeron's career has taken various paths including government auditing, nonprofit work, public/private partnerships with the State of Louisiana, helping build an MSP by building their managed service, managed security, vCISO and compliance programs, and now as the Cybersecurity Technical Fellow with Sherweb. Roddy has obtained many certifications over the years including his MCSE, CCNA:Security, CEH, CCSP, CISSP and CSAP. Our MSP community is extremely important to Roddy and he loves giving back to the community that has helped him out so much over the years. Roddy hopes to continue to help other MSPs succeed and raise the cybersecurity tide for our industry.