Key Takeaway: A vulnerability scan tells you what doors might be unlocked. A penetration test tells you which ones an attacker can actually walk through. They are not the same thing, they do not cost the same, and they do not answer the same question. MSPs that sell vulnerability scans as penetration tests are doing their clients a disservice and themselves a liability.

Penetration testing has moved from a large-enterprise concern to an SMB requirement. Cyber insurance carriers ask about it. Compliance frameworks require it. Clients who have been through a breach ask why it was not done. The MSP that understands what penetration testing is, what it is not, and how to position it as a service is ahead of the market.

The MSP that conflates penetration testing with vulnerability scanning is behind it.

Penetration Testing vs. Vulnerability Scanning

A vulnerability scan is automated. A tool scans systems for known vulnerabilities: unpatched software, misconfigured services, weak encryption, default credentials. It produces a report of findings ranked by severity. It takes hours to run and costs relatively little. It tells you what vulnerabilities exist. It does not tell you whether those vulnerabilities are actually exploitable in your specific environment, or what an attacker could do if they exploited them.

A penetration test is performed by a human. A skilled security professional attempts to exploit vulnerabilities in your environment using the same techniques an attacker would use. They chain vulnerabilities together. They use social engineering. They escalate privileges. They move laterally through the network. They demonstrate what an attacker could actually accomplish, not just what vulnerabilities theoretically exist.

The vulnerability scan that finds a critical CVE on a server is useful. The penetration test that demonstrates an attacker can exploit that CVE, pivot to the domain controller, and exfiltrate the entire Active Directory database is a different level of finding entirely. The first tells you to patch. The second tells you what happens if you do not.

According to Verizon’s 2025 Data Breach Investigations Report, 68 percent of breaches involved a human element: phishing, stolen credentials, or social engineering. Vulnerability scans do not test for these. Penetration tests do.

Types of Penetration Tests

External network penetration test. Tests internet-facing systems: firewalls, VPNs, web applications, email servers, remote access portals. The tester starts from outside the network with no internal access, simulating an external attacker. This is the most common starting point for SMB clients.

Internal network penetration test. Tests what an attacker can do once inside the network, simulating a compromised endpoint, a malicious insider, or an attacker who has already breached the perimeter. Internal tests typically reveal more critical findings than external tests because most SMB networks have minimal internal segmentation.

Web application penetration test. Tests a specific web application for vulnerabilities: SQL injection, cross-site scripting, authentication bypass, insecure direct object references, and other OWASP Top 10 vulnerabilities. Relevant for clients with customer-facing web applications or portals.

Social engineering test. Tests the human element: phishing simulations, pretexting calls, physical access attempts. Reveals whether employees will click malicious links, provide credentials over the phone, or allow unauthorized physical access. Often the most uncomfortable findings for clients because the failures are personal.

Wireless penetration test. Tests wireless network security: encryption strength, network segmentation, rogue access point detection, and whether the wireless network can be used to access internal systems. Relevant for clients with guest WiFi or wireless-heavy environments.

Black Box, Gray Box, and White Box Testing

Black box testing gives the tester no information about the target environment. They start with only the client’s domain name or IP range, simulating an external attacker with no inside knowledge. This is the most realistic simulation of an external attack but may miss vulnerabilities that require internal knowledge to find.

Gray box testing gives the tester some information: network diagrams, user credentials, or application documentation. This simulates an attacker who has done reconnaissance or has compromised a low-privilege account. Gray box testing is more efficient than black box and typically surfaces more findings in the same time budget.

White box testing gives the tester full information: source code, architecture documentation, all credentials. This is the most thorough approach and is used when the goal is to find every possible vulnerability rather than simulate a realistic attack scenario. White box testing is more common for web application assessments than network penetration tests.

For most SMB clients, gray box external and internal testing provides the best balance of realism and thoroughness within a reasonable budget.

What a Penetration Test Report Should Include

An executive summary that explains the overall risk posture in business terms, not technical jargon. The client’s leadership needs to understand what was found and what it means for the business without reading 80 pages of technical findings.

A findings list with each vulnerability ranked by severity (critical, high, medium, low, informational), a description of the vulnerability, evidence of exploitation (screenshots, command output), the business impact if exploited, and a specific remediation recommendation.

An attack narrative for significant findings that describes the chain of steps the tester used to achieve a significant outcome. “We started with an unauthenticated scan of the external perimeter, identified an unpatched VPN appliance, exploited CVE-XXXX to gain initial access, used that access to harvest credentials from memory, and used those credentials to authenticate to the domain controller with administrative privileges.” This narrative is what makes penetration test findings real to clients.

A remediation roadmap that prioritizes findings by risk and provides a realistic timeline for addressing them. Critical findings should be addressed immediately. High findings within 30 days. Medium findings within 90 days. The roadmap gives the client a path forward, not just a list of problems.

The MSP’s Role in Penetration Testing

Most MSPs should not perform penetration tests themselves. Penetration testing requires specialized skills, certifications (OSCP, CEH, GPEN), and tools that are outside the scope of standard MSP operations. Attempting to perform penetration tests without the appropriate expertise produces incomplete findings and creates liability if something goes wrong during testing.

The MSP’s role is to:

Recommend penetration testing as part of the annual security review. Clients who have never had a penetration test do not know they need one. The MSP that raises the conversation is delivering advisory value.

Facilitate the engagement with a qualified penetration testing firm. Provide the tester with the network documentation and access they need. Coordinate the testing window to minimize disruption. Be available during testing to respond if something unexpected happens.

Manage the remediation. The penetration test report is a prioritized remediation list. The MSP that takes ownership of remediating the findings, tracks progress, and verifies that vulnerabilities are actually fixed is delivering the full value of the engagement. The penetration test that produces a report that sits in a drawer is a waste of money.

Conduct a retest. After critical and high findings are remediated, a retest confirms that the vulnerabilities are actually fixed. Some firms include a retest in the original engagement price. Others charge separately. Either way, the retest is important. Remediation that does not actually fix the vulnerability is worse than no remediation because it creates false confidence.

Frequency and Compliance Requirements

PCI DSS requires penetration testing at least annually and after any significant infrastructure change. HIPAA does not explicitly require penetration testing but the risk analysis requirement effectively mandates it for environments with significant ePHI exposure. SOC 2 Type II audits typically include penetration testing as evidence of security controls. Cyber insurance carriers increasingly ask whether penetration testing has been performed and when.

For clients without specific compliance requirements, annual penetration testing is a reasonable baseline. After a significant infrastructure change (new firewall, new VPN, major application deployment), a targeted test of the changed components is appropriate even if the annual test is not due.

Frequently Asked Questions

How much does a penetration test cost?
External network penetration tests for SMB environments typically range from $3,000 to $8,000. Internal tests add $2,000 to $5,000. Web application tests range from $5,000 to $15,000 depending on application complexity. Social engineering engagements vary widely. The price reflects the time required, the scope of the engagement, and the expertise of the testers. Quotes significantly below these ranges should be scrutinized carefully.

How do I find a qualified penetration testing firm?
Look for firms with certified testers (OSCP, GPEN, CEH), a clear methodology, and references from similar-sized clients. Ask to see a sample report before engaging. The report quality tells you a great deal about the firm’s thoroughness and communication skills. Avoid firms that cannot provide a sample report or whose sample reports consist primarily of automated scan output.

Can I use a vulnerability scanner instead of a penetration test?
For routine vulnerability management, yes. For compliance requirements that specify penetration testing, no. For understanding what an attacker can actually do in your environment, no. Vulnerability scanning and penetration testing serve different purposes and should both be part of a mature security program.

What should I tell clients to expect during a penetration test?
Testing may generate unusual network traffic and trigger security alerts. The MSP and client should be notified before testing begins so that legitimate testing activity is not mistaken for an actual attack. Testing should be scheduled during a window that minimizes disruption. The tester should have an emergency contact number in case something unexpected happens during testing.

What is the difference between a penetration test and a red team exercise?
A penetration test has a defined scope and time limit. The goal is to find and document vulnerabilities. A red team exercise is broader, longer, and more realistic. The red team attempts to achieve a specific objective (access the CFO’s email, exfiltrate customer data) using any means available, including physical access and social engineering, without a defined scope boundary. Red team exercises are appropriate for larger organizations with mature security programs. Most SMB clients should start with penetration testing.

Sources

• Verizon 2025 Data Breach Investigations Report
• OWASP Top Ten Web Application Security Risks
• PCI DSS Penetration Testing Guidance
• SANS Penetration Testing Resources

Related Reading: NOC vs SOC | Cyber Insurance Requirements 2026 | PCI DSS for MSPs | MSP Incident Response Plan | MSP Cybersecurity Hub