What to Ask Your MSP About Penetration Testing

If an IT provider looks after your network, you trust it with a lot. It can reach your devices, your accounts and your data. So it is fair to ask one plain question: has your provider been tested the way a criminal would test it? Penetration testing for MSPs is how a provider finds that out, and you are entitled to ask about it.

This guide is written for the customer. It explains why your provider is a target, what a proper test covers, which questions to put to your MSP and how to tell whether the answers are solid.

Why does penetration testing for MSPs matter to you?

Your provider holds trusted access to your systems. Because of that, penetration testing for MSPs is a fair thing to ask about. It probably holds the same kind of access for many other firms too. The joint advisory from the UK, US, Australian, Canadian and New Zealand agencies says a compromised provider can act as an entry point into multiple customer networks, with knock-on effects. The same advisory expects state-backed groups to lean on these trust relationships more, not less.

The Kaseya attack in July 2021 shows what this means for a customer. Criminals used a flaw in the Kaseya VSA remote management product to push ransomware to MSPs and then on to their customers. CISA and the FBI began responding on 2 July. Kaseya shut down its cloud servers the same day and told on-premises users to switch their servers off.

The customers of those providers had done nothing wrong. They were still the ones locked out. Your own security can be excellent and your risk can still depend on someone else’s tooling.

What does penetration testing for MSPs mean from a customer’s seat?

The NCSC describes a penetration test as “a method for gaining assurance in the security of an IT system”. Skilled testers try to break in using the same techniques a real attacker would use. They then report what worked.

When your provider has this done on its own setup, you gain assurance that the systems used to run your network have been challenged. That is different from a promise on a sales page. It is evidence that someone outside the company tried to get in and reported honestly on the result.

For a provider, the useful targets sit where its access meets yours. Ask whether the test covered these areas:

• Remote management and monitoring tools. The RMM platform, the PSA and any remote access gateway.
• Identity and access. Admin accounts, MFA coverage, conditional access rules and how service accounts are stored and rotated.
• Internet-facing systems. Customer portals, VPNs, mail, and any web application the provider hosts or builds.
• Cloud tenants. The provider’s own Microsoft 365 or Azure setup, plus any delegated admin links into client tenants.
• Segregation between clients. Can a technician account, or an attacker using one, see data from a customer it should never touch?
• People and process. Help desk password resets and phishing resistance, where a social engineering test fits.

The sixth point matters to you directly. If a caller can talk the help desk into resetting a password, your data is at risk whatever else is in place.

What should you ask your MSP?

You do not need to be technical to ask good questions. Start with these, and note whether the answers are specific or vague.

1. Has an independent firm tested your own systems? A test by an outside team carries more weight than a self-check.
2. When was the last test? The NCSC points out that a test only shows the state of the system on the day, and that tests are often a once-a-year event. A report from several years ago tells you little.
3. Did the test cover the tools that touch my network? That means the RMM platform, remote access and delegated admin links.
4. Was lateral movement tested? The key question is whether one technician login could reach other clients, including you.
5. What happened to the findings? A good provider fixed them and had a retest to confirm it.

How can you check that your provider has really been tested?

So ask to see proof, in a form that suits both sides. You do not need the full technical report, which may hold sensitive detail about other clients. A summary letter or a short written confirmation can do the job.

Look for these signs:

• The name of the firm that did the work, and ideally the qualified people who did it. The NCSC notes that results depend heavily on the testers’ skill.
• The date of the test and the systems it covered.
• Ranked findings, with evidence for each one and fix advice.
• Confirmation that a retest showed the holes were closed.

Be wary of answers that name only a tool or a scan. A scan lists known weaknesses. A test shows which of them an attacker can chain together. A scan might flag an old VPN appliance and a reused admin password as two medium findings. A tester may show that together they give full control of the RMM server. That chain is what matters to you.

Which controls should penetration testing for MSPs confirm?

The joint advisory lists a dozen actions for providers. A test is a good way to check whether they were really done. Several matter most to a customer:

• Multi-factor authentication on remote access and on every MSP account that touches a customer environment.
• Least privilege, with tiered admin accounts and time-limited rights where possible.
• Separate internal networks, with critical systems isolated.
• Old accounts and infrastructure disabled, including MSP accounts once a contract ends.
• Known exploited vulnerabilities patched first, with tested, offline backups.
• Contracts that state who owns each security responsibility.

Our guide to what multi-factor authentication stops and what still gets through explains why attackers often go around MFA rather than through it. It helps you judge an answer such as “yes, we use MFA”.

How does penetration testing for MSPs work, so you can judge the report?

Penetration testing for MSPs starts with a scoping call. The provider and the testers agree which systems are in, which are out, and what the testers may try. Agreeing the boundaries up front saves money, and our piece on why a weak scope of work costs you later covers how to do it.

Then the team works from the outside in, because that is how most attackers start. They look at what an attacker can see from the internet and try to get a foothold. After that, they see how far one stolen account can travel.

Some tests are run as an assumed breach. The testers start with a normal technician account, as if phishing had already worked. This skips the guesswork and goes straight to the damage a single stolen login could do. If your provider ran one, that is a good sign.

Above all, the test should never put customers at risk. Safe handling and stop rules should be agreed before work begins, so ask how your data was protected during the test.

Does your MSP’s security affect your own supplier checks?

It can. Buyers now ask suppliers about security in tenders and questionnaires. The NCSC says a good supply chain approach helps organisations win contracts by showing they can be trusted. Your provider is part of your supply chain, and your own customers may ask about it.

A recent test report from your provider, along with a record of fixing what it found, gives you something concrete to point to. It sits well alongside Cyber Essentials, which the NCSC names as a baseline assurance for suppliers.

Frequently asked questions

Is a penetration test mandatory for my MSP in the UK?

No law names it for every MSP. But clients, insurers and some frameworks ask for evidence of testing, so many providers treat it as a requirement in practice.

Is a vulnerability scan enough for MSPs?

A scan is a useful routine check, but penetration testing for MSPs goes further. A scan cannot think like an attacker, so an independent test also gives you a report you can trust.

Will testing disrupt my service?

It should not. A careful firm agrees safe methods, test windows and stop conditions before starting.

Can I ask my MSP to test my own systems too?

Many MSPs offer it as a service. Each client needs its own written permission and scope.

What if the test finds something serious?

The provider should fix it, retest and keep the evidence. If your data may have been exposed, check your contract for notification duties.

Next step

If you run an MSP, or want to push your provider on this, Aardwolf Security can scope a penetration test around your RMM, identity and client access. You can get in touch for a straightforward conversation about what makes sense.