Your MSP Is Not Your Penetration Test

Most businesses do not fail on cybersecurity because nobody cares. They fail because everyone assumes someone else has already checked it properly.

For many companies, that someone else is the MSP.

A managed service provider may be essential to your business. They may support your users, manage devices, maintain licensing, deploy patches, configure backups, monitor alerts, and keep the lights on.

That does not make them your penetration test.

The MSP usually maintains the environment. A penetration test challenges the environment.

 

Support is not validation

A good MSP is a valuable partner. This field note is not an attack on MSPs. HMH works alongside MSPs regularly, and the best engagements happen when the client, MSP, and testing team understand their roles clearly.

The issue begins when leadership assumes that managed IT support equals tested security. It does not.

There is a major difference between keeping systems operational and testing whether those systems can be bypassed, exploited, escalated, or misused under realistic conditions.

• Keeping systems operational
• Responding to tickets
• Installing tools
• Applying patches
• Managing backups
• Configuring firewalls

Those are important support functions. They are not adversarial validation.

What leadership often assumes

Leadership teams often hear familiar phrases: we have MFA, we have backups, the firewall is managed, endpoints are protected, the MSP monitors that, or the last scan was clean.

Those statements may all be true. They still do not prove the environment has been properly tested.

MFA can be enabled but not enforced everywhere. Backups can exist but fail during recovery. A firewall can be managed and still misconfigured. Endpoint protection can be deployed but not properly monitored.

The real question is not whether the company owns security tools. The better question is whether anyone has independently tested whether those controls actually hold under pressure.

What a penetration test actually does

A properly scoped penetration test looks at the environment from an attacker’s perspective. Depending on the scope, it may assess:

• Internet-facing systems
• Remote access portals
• Cloud services
• Web applications
• Email exposure
• User authentication
• Internal network segmentation
• Active Directory weaknesses
• Credential reuse
• Privilege escalation
• Lateral movement paths
• Exposed services
• Misconfigured systems
• Business-critical attack paths

The value is not just finding vulnerabilities. The value is understanding what those vulnerabilities mean in your actual business environment.

A single issue may look minor in isolation. But if it can be combined with weak access control, exposed credentials, poor segmentation, or excessive permissions, the impact can change very quickly.

Vulnerability scanning is useful, but it is not enough

Vulnerability scanning has a place. It can help identify known issues, missing patches, exposed services, and common misconfigurations. HMH uses scanning where appropriate.

But a scan is not a penetration test.

A scan may tell you a door has a weak lock. A penetration test checks whether someone can open it, move through the building, reach the office, access the filing cabinet, and leave with something valuable.

 

A scan asks what appears to be vulnerable. A penetration test asks what can actually be done with that weakness.

Why this matters to the CFO and COO

This is not just an IT issue. It is a leadership issue.

For a CFO, COO, owner, or board member, the concern is practical. Can the business evidence reasonable steps? Can it support cyber insurance conversations? Can it respond to client security questions? Can it prioritize remediation spend properly?

If there is a breach, nobody is going to ask whether everyone felt good about the MSP. They will ask what leadership did to validate the environment.

Confidence is not evidence.

 

What good MSP cooperation looks like

A penetration test should not become a blame exercise. The best MSPs welcome independent testing because it gives everyone a clearer picture of what needs to be improved.

• Confirming the approved scope
• Providing asset lists where appropriate
• Identifying critical systems
• Confirming testing windows
• Sharing escalation contacts
• Confirming known maintenance periods
• Supporting remediation
• Assisting with retesting

A mature MSP understands that independent testing can strengthen their position. It gives them evidence to support budget requests, improve controls, and resolve issues before an attacker finds them first.

Common issues HMH sees in MSP-managed environments

The issues are rarely exotic. They are usually basic, practical, and dangerous.

• Legacy systems still reachable
• Old user accounts left active
• MFA not enforced consistently
• Weak or reused passwords
• Excessive administrator permissions
• Poor network segmentation
• Exposed remote access services
• Misconfigured cloud storage
• Incomplete logging
• Backup recovery assumptions
• Patch gaps on overlooked systems
• Vendors with more access than they need
• No clear asset ownership

Most of this is not caused by laziness. It is caused by drift. Businesses grow. People leave. Systems get added. Vendors change. Cloud tools are adopted quickly. Exceptions become permanent. Nobody owns the whole picture.

Leadership questions to ask this week

1. When was our last independent penetration test?
2. Did it include external and internal testing?
3. Was it performed by someone independent of our MSP?
4. Did the report include proof of exploitation or only scan results?
5. Were findings ranked by business impact?
6. Were the issues retested after remediation?
7. Do we know which systems are exposed to the internet?
8. Do we know where MFA is not enforced?
9. Do we know who has administrative access?
10. Do we know whether backups have been tested for recovery?
11. Do we know what happens if one user account is compromised?
12. Do we know what risk we are accepting?

If those questions cannot be answered clearly, there is likely a gap between perceived security and actual security.

When to bring in external help

You should consider an independent penetration test if you have not tested in the last 12 months, are preparing for cyber insurance renewal, have changed MSPs, have acquired another business, moved systems into the cloud, use remote access tools, handle sensitive data, or need to prove security posture to clients or insurers.

The test does not need to be dramatic. It needs to be properly scoped, professionally conducted, clearly reported, and followed by remediation.

The HMH view

Your MSP may be doing a good job. That is not the point.

The point is that support and validation are different disciplines. A business should not rely only on the person maintaining the environment to confirm that the environment can withstand attack.

At HMH Consulting, we assess cyber environments with the same mindset we apply across physical security, investigations, and protective operations: remove assumptions, identify real exposure, and give leadership a practical route forward.

Related public references

These references are included for context and editorial grounding. HMH recommendations should be scoped to each client environment.

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• CISA: Penetration Testing Services
• CISA: Vulnerability Scanning, Analysis, and Reporting