External Penetration Testing for MSPs

• Manual Testing for Deeper Insights: A tester drives the engagement by hand, finding chained and business logic flaws that automated tooling reports as clean.
• Comprehensive Threat Assessment: Every external-facing asset inside the agreed scope is enumerated and tested, not just the ones your client remembered to tell you about.
• Actionable Reporting with Remediation Guidance: Findings are ranked by real exploitability, with reproduction steps and a fix your client's engineers can follow.
• Black Box Assessment: We start with no credentials and no internal foothold, the same position a real attacker starts from.
• Channel Only Delivery: We never sell to your client and never appear in front of them unless you invite us. The report carries your logo.

What an external penetration test actually covers

An external penetration test is an authorized, manual attack against everything your client exposes to the public internet. The tester works from outside the perimeter with no credentials, no VPN and no agent installed, and tries to reach something that matters: a shell on a host, a valid session, a management console, or data that should never have been reachable.

In a typical engagement the tested surface includes public IP ranges and the live hosts inside them, perimeter devices such as firewalls, routers and VPN concentrators, remote access services including RDP, SSH and Citrix, mail and DNS infrastructure, any web application or API published on those addresses, and the login portals that sit in front of them. Cloud tenants are in play wherever they publish a public endpoint your client controls.

The work is not a port sweep. Enumeration is the first hour, not the deliverable. The value sits in what the tester does after the surface is mapped: testing authentication for weak and reused credentials, probing exposed services for known and misconfigured behavior, hunting for forgotten hosts and staging environments, testing the public web layer against the OWASP Top 10, and then chaining low severity issues into one path that actually gets somewhere. A single expired certificate is noise. An expired certificate on a forgotten subdomain running an unpatched admin panel is an incident waiting to be written up.

Scope boundaries: what is in and what is deliberately out

Scope is the part MSPs get burned on, so we set it in writing before anything is touched. In scope is whatever your client owns or has written authority to test, listed as IP addresses, CIDR ranges and fully qualified domain names on the authorization form.

Out of scope by default: anything hosted by a third party that has not given written consent, denial of service and volumetric testing, physical intrusion, and social engineering against staff. Those are separate engagements with separate rules, and a social engineering test is scoped on its own terms. Internal systems reachable only from behind the perimeter are also outside an external test by definition. If your client wants lateral movement, Active Directory abuse and privilege escalation covered, that is an internal engagement and it is scoped separately.

Shared hosting and cloud provider terms matter. Where a target sits on infrastructure your client does not own, we confirm the provider permits testing before the window opens. We would rather lose a host from the scope than have a partner explaining an unauthorized test to a hosting provider.

How an external network penetration test is run

Delivery follows a documented methodology drawn from NIST SP 800-115 and the Penetration Testing Execution Standard, with OWASP Top 10 coverage on any web layer in the scope. The phases are consistent across every partner engagement:

1. Scoping and authorization. Targets are fixed in writing, the testing window is agreed, and your client signs the authorization. Emergency contacts are set on both sides.
2. Reconnaissance. Passive discovery of domains, subdomains, certificate transparency records, exposed credentials in public breach data, and anything the organization has published without meaning to.
3. Enumeration and service mapping. Live host discovery across the agreed ranges, service and version fingerprinting, and identification of the technologies behind each listener.
4. Vulnerability analysis. Automated tooling runs here, and its output is triaged by a human. False positives are removed before anything reaches your report.
5. Manual exploitation. Confirmed issues are exploited under controlled conditions to prove impact rather than assert it. Chaining happens in this phase.
6. Post exploitation and impact. Where access is achieved, the tester establishes what it reaches and what it is worth, without disrupting production.
7. Reporting and debrief. Findings are written up, risk ranked and handed to you. We will join a debrief call with your client under your brand if you want us there.
8. Remediation retest. Fixed findings are retested so the closing report shows the issue resolved rather than merely reported.

For a longer walkthrough of the tester's workflow, read our guide to how an external network penetration test is scoped and run.

External infrastructure penetration testing

Buyers ask for an external infrastructure penetration test when the concern is the plumbing rather than the application: the firewall rule that was opened for a project in 2019 and never closed, the VPN appliance two firmware versions behind, the jump host with password authentication still enabled, the DNS record still pointing at a decommissioned server that someone else has since claimed.

Infrastructure focused testing puts weight on perimeter device configuration, remote access exposure, patch levels on internet-facing services, certificate and protocol hygiene, and segmentation between the public edge and everything behind it. It overlaps heavily with a standard external network pentest and is usually delivered as the same engagement with the emphasis moved. If your client's estate is mostly network gear and published services rather than custom applications, this is the shape you want. There is more detail in our guide to infrastructure penetration testing for MSPs.

What the deliverable contains

The report is the product your client actually receives, so it is built to survive an auditor reading it. Every engagement returns an executive summary written for a non-technical reader, a scope and methodology statement recording exactly what was tested and when, a full findings list with severity ratings, evidence and reproduction steps, prioritized remediation guidance, and a retest record showing which findings were closed.

Partners also get a letter of attestation confirming an independent third party performed the test, which is the document most auditors and cyber insurance underwriters actually ask to see. Reports ship white-labeled with your branding, or attested under the MSP Pentesting name where your client needs visible third-party independence. You choose per engagement.

On compliance: PCI DSS v4.0.1 Requirement 11.4.3 calls for external penetration testing at least once every twelve months and after any significant infrastructure or application change. SOC 2 does not name penetration testing as a required control, but auditors routinely accept a current pentest report as evidence under the common criteria covering monitoring and change management. Cyber insurance applications increasingly ask whether testing has been performed and by whom. Our reporting is structured so one engagement satisfies all three readers.

External penetration testing versus a vulnerability scan

These get sold interchangeably and they are not the same thing. A vulnerability scan is automated, runs in minutes, and produces a list of things that might be wrong based on version banners and signatures. It is cheap, it should run continuously, and it is genuinely useful for coverage.

A penetration test is a person attempting to break in. It confirms whether a finding is real, establishes what an attacker reaches once they use it, and catches the categories a scanner structurally cannot see: business logic flaws, chained low severity issues, weak credentials on exposed services, and access control failures. A scanner tells your client they have 340 findings. A pentest tells them which two of those findings get an attacker to the domain controller.

The practical answer for most MSP clients is both, at different frequencies: scanning monthly or continuously, manual testing annually and after significant change. If you need to make that argument to a client, our breakdown of vulnerability assessment versus penetration testing is written to be forwarded.

How scoping and pricing work for partners

External pentests are priced on the size and complexity of the attack surface, not on a headcount or a seat count. The variables that move a quote are the number of live hosts in the public ranges, the number of distinct web applications or APIs published on them, how many separate authentication surfaces exist, whether cloud endpoints are included, the turnaround you need, and whether remediation retesting is bundled.

Scoping is deliberately short. Send the IP ranges and domains, tell us the deadline and what the test is for, and you get a fixed quote against a defined scope. There are no rush fees. Pricing is channel rate, quoted to you rather than to your client, with room to mark up under your own brand. For how the variables translate into a number, see our breakdown of what an external penetration test costs, or ask us for current partner rates directly.

External pentesting services: common questions

How long does an external network pentest take? Most small and mid-sized external scopes are executed within a defined testing window and reported shortly after it closes. The window scales with the number of live hosts and published applications, and it is fixed in the quote so you can commit a date to your client.

Will the test knock anything over? Testing is conducted to avoid disruption to production. Denial of service is excluded by default, exploitation is controlled, and both sides hold emergency contacts so anything unexpected is stopped immediately.

How often should a client have one? Annually as a baseline, and again after any significant change to the perimeter: a new public application, a firewall migration, a move to a new hosting provider, or an acquisition. PCI DSS obligated clients follow the twelve month cycle in Requirement 11.4.3.

Does my client ever find out you exist? Only if you want them to. We are channel only. We do not sell direct, we do not market to your client list, and the default deliverable carries your branding. Where independence has to be visible for an auditor, we attest under our own name at your request.

What if we also need the internal side? Internal testing is a separate engagement covering lateral movement, privilege escalation and Active Directory abuse from inside the network. See internal penetration testing for MSPs, or scope both together and run them in one window.

Ready to price one? Get a pentest quote and send your scope. We reply with a fixed number against a defined scope, priced for the channel.