5 cybersecurity considerations to mitigate risk post-merger

| By:
Matt Topper

Consolidation is very common for MSPs. Every day, we talk to partners who are involved in a transaction—whether merging or part of an acquisition. While exciting, these changes can introduce significant risks. Beyond tactical technology issues, a merger or acquisition means that processes are changing, and, in some cases, it’s not yet clear who makes the decisions. 

I’ve personally been involved in multiple mergers and had many conversations with other organizations that have been through them, giving me plenty of insight into the most important factors you’ll want to consider. In this blog, we’ll discuss five key considerations when it comes to managing risk and information security during a transaction. 

Shared authority 

One of the most significant risks during a transitional time is that the authority for decision-making becomes unclear. There are many large, systemic changes happening at once, so even small decisions, such as allowing or not allowing an access request, could potentially introduce risk.  

Larger changes can introduce even more risk, such as deciding what version of a tool or system will continue to be used. Best practice recommends determining who “owns” the functional areas and systems as quickly as possible, and publicly documenting this within the organization. This gives everyone the ability to know who has authority over what, providing stability in a time that can often be chaotic.  

Access creep 

Access creep, also known as privilege creep, is when accounts start accumulating unnecessary permissions and violating least-privilege principles. This happens frequently during transitional times, as migrating to new systems or bringing on new tools takes work—a lot of work. And in some cases, it takes so much work that more people need to get involved. Those types of migrations often require elevated privileges to move data or configurations, but access creep can occur if those elevated privileges aren’t removed afterwards. 

Similarly, when migrations are happening and a client is on the other end of the phone, it’s very tempting to make policy exceptions to satisfy the client need. Of course, it’s great to accommodate your customers, but it’s important that those exceptions follow your organization’s normal procedures and that it includes removing that access once the critical issue is resolved. 

Both scenarios are examples of access creep. To avoid this, be careful about granting access to employees who wouldn’t otherwise have it when performing migrations—make sure that it’s absolutely required to complete a task, and be sure to remove it afterwards. It’s also important to perform a thorough evaluation of privileges for new systems. Often, requests will arise that start with “I used to be able to do…,” which can be a sign of previously excessive permissions. 


No, not Thanksgiving leftovers—we’re talking about technical and operational leftovers. When performing mergers, the focus is typically on core systems like PSA, RMM, and cybersecurity tools. But most organizations have many systems used for service delivery, some by only a small number of clients. 

As roles are reassigned within the new organization, it’s equally important to consider that certain access for certain roles may no longer be appropriate. All systems require regular access reviews, but in practice they can be even more important for obscure systems, where improperly assigned access might not be discovered for some time. Don’t forget to change primary contacts and assign asset owners to these more obscure systems, even if they are less frequently used.  

Internal IT 

Not everything is client-facing. When merging, internal systems need to be migrated, too. That might include an internal Microsoft 365 tenant, servers, security tools, or SaaS applications. These migrations present an opportunity but also risk. 

To mitigate said risk, review configuration standards to determine if they are still applicable. New compliance obligations, insurance requirements, or changing technology can change these requirements. And If you don’t have configuration baselines, take the time to develop them—especially security standards. 

Once you decide on your internal security standards, the next step is to implement them. Ruthlessly.  This is the time to implement CIS Benchmarks, move applications to SSO, or require the use of corporate devices. If neither organization has that type of secure environment, a fresh start or greenfield migration may make more sense. 

Greenfield or migrate 

Deciding how to handle the transition of software and systems is a crucial consideration during or following a merger. You can choose to take a greenfield approach, which means starting from scratch and completely reengineering your processes and workflows, or you can choose to migrate, combining your software and processes with the other company. For all systems when merging, your choices are broken down into three possibilities: 

  1. Pick an existing instance and migrate everything to it. 
  1. Start completely fresh using the same platform. 
  1. Start completely fresh using a different platform. 

There’s no definitive answer, but here are some considerations to help decide: 

  • With most mergers, there will be a variety of states that the systems are in. One might have a well-tuned PSA configuration, while the other has its cybersecurity tools running like a well-oiled machine. Take the time to identify where each organization is strongest. 
  • When there is not an obvious choice or a desire to make significant changes, consider migrating to a fresh instance. This is not a decision to take lightly, as it’s a significant effort to start fresh, but the opportunity to start over is empowering and can lead to better long-term results. 
  • When migrating to an existing system during a merger, be very careful about understanding what’s already there—and not just from an access perspective. Review existing procedures, scripts, automation, etc., to see if anything references old standards or other systems. 
  • When merging, be careful not to underestimate the effort required for a migration. It may seem like a greenfield build is always significantly more work, but heavily modifying an existing installation may require even more effort. 

Talk with our experts about migration 

There are many aspects to consider when migrating systems during a merger or acquisition. In this blog, we’ve covered some of the most important ones, but of course, there are always factors to consider that are unique to each situation.  

For a more in-depth conversation about prioritizing security during mergers and acquisitions with people who have gone through these changes firsthand, please reach out to our team.