top of page
Search

Your MSP Has Access to Your Business—What Should You Ask Before a Ransomware Incident?

  • Aug 10
  • 4 min read


Our review of the 30 days ending 27 July put IT services and MSPs at the top of that sector view, with eight reported victims.

That number is a signal, not a verdict on managed service providers. Public ransomware claims are incomplete and can be delayed or unverified. Nor does the finding mean that an SMB should avoid using an MSP. A good MSP can provide skills, monitoring and resilience that a smaller business could not reasonably maintain alone.

It does, however, raise an important customer question: if a trusted provider account or support tool were compromised, what would stop that becoming your outage tomorrow?

This is the practical follow-up to Part 1: not whether to trust an MSP, but what evidence to ask for before an incident tests that trust.


Why the risk is different

An MSP needs privileged access to support its customers. Depending on the contract, that may include remote monitoring and management (RMM), backup systems, cloud administration, endpoint-security tools, VPNs, support accounts and technical documentation.

Those tools make support efficient. They can also create a one-to-many risk if they are compromised or misused. The UK government says MSPs’ widespread access to customer networks makes them an increasingly attractive target and can create a one-to-many impact; it also reports an increase in attacks using MSPs as an attack vector.

The immediate concern is the management plane: the people, accounts and tools used to administer the business’s systems. A ransomware incident may begin with a phishing email or a vulnerable remote service at the provider—not necessarily with a mistake by an employee in the customer business.


Seven questions to ask your MSP

These questions are not a technical audit. They are a way for a business owner or operations lead to get clear, useful answers.

  1. Which provider tools and accounts can access our environment?Ask for a current list covering RMM, remote support, backups, cloud administration and any subcontractor access.

  2. Are those accounts named and protected with MFA?Support staff should use individual accounts, not shared credentials. Multi-factor authentication should cover all remote and privileged access, including backup and cloud-management tools.

  3. What limits the effect of one compromised account?Ask how administrator access is restricted, whether client environments are separated, and what prevents a remote-management tool from pushing a harmful change widely without checks.

  4. Can we recover if normal administrator access is no longer trusted?Backups need protection from the same identity compromise that might affect the live environment. Ask where copies are held, who can change or delete them, and for evidence of a recent restoration test.

  5. What would happen in the first hour of a suspected MSP compromise?Agree who contacts whom, how access would be safely restricted, what records would be preserved and when specialist incident-response support or the insurer would be involved.

  6. How and when would you notify us?Make the route, contacts and out-of-hours expectations explicit. The contract should cover an incident at the MSP or in its tools, not just an incident discovered in your own network.

  7. What is our responsibility?A good service agreement makes responsibilities visible: which patches, backups, approvals, accounts and reports belong to the MSP, and which need action from the customer.


Ask for evidence, not reassurance


Fide, sed vide (“trust, but verify”)


“We take security seriously” is a welcome answer, but it is not enough on its own. The UK National Cyber Security Centre recommends clear roles, incident-reporting arrangements, access protections and tested backups when working with an MSP.

For a proportionate review, ask for these four things:

Evidence to request

What it should clarify

An access map

The management tools, accounts and third parties that can reach your systems.

A recovery summary

Where backups are kept, how they are protected, and the result of the most recent restoration test.

An incident contact sheet

Named contacts, 24/7 routes and the first-hour escalation path.

A responsibility matrix

Who is accountable for patching, access review, monitoring, backup checks, notifications and decision-making.

None of this requires the customer to run the MSP’s systems. It makes the shared boundary visible while there is time to improve it.


A short request to send this week

If you need a simple way to begin the conversation, adapt this message:

Hello [MSP contact],Following our ransomware-resilience review, please send us a current summary of the tools and accounts your team and subcontractors use to access our environment; how MFA and privileged access are controlled; our backup and restoration arrangements; and the incident-notification process if your systems or management tools are affected.Please also confirm the named out-of-hours contact and share our current responsibility matrix for security, patching, backups and incident response.

The goal is not to create paperwork for its own sake. It is to ensure that an urgent conversation can become action: access can be understood, recovery can be proved and the right people can be reached.


Trust works better when you can verify it

Managed services remain a sensible way for SMBs to obtain expertise and resilience. But the more access a provider has, the more important it is to make that access visible, controlled and recoverable.

Part 1 identified MSPs as the most prominent sector in our recent RansomGrok SMB snapshot. Part 2 is the response: turn that signal into a focused conversation with your provider before an attacker turns a trusted connection into a wider business interruption.

This article is general information and should be applied alongside your organisation’s systems, contracts, risk assessment and incident-response arrangements.


Sources

 
 
 

Comments

bottom of page