Penetration Testing for MSPs: Delivery Guide

Managed service providers are often the first people a client asks when a customer, insurer or auditor requests a penetration test. Adding the service can deepen the relationship, but it also introduces legal, technical and operational responsibilities that ordinary IT support does not.

The strongest model is simple: the MSP owns coordination and client context; a capable offensive-security team owns authorised testing and technical conclusions; the client retains visibility and decision-making throughout.

Decide what service you are actually offering

“Security assessment” is not a sufficient scope. An MSP should distinguish between:

• Vulnerability scanning: automated identification of known issues and exposed services.
• Configuration review: assessment of settings against a defined standard or secure baseline.
• Penetration testing: authorised exploitation and attack-path validation by skilled testers.
• Red teaming: an objective-led exercise that tests detection and response across people, process and technology.

These services complement one another, but they are not interchangeable. In particular, do not sell a scanner report as a penetration test. The buyer should understand the depth, limitations and human involvement before signing.

Choose a delivery model

Referral

The MSP introduces a specialist provider and the client contracts with that provider directly. This creates the clearest division of technical and legal responsibility, but gives the MSP less control over the commercial relationship.

Managed coordination

The client contracts through the MSP, which coordinates scope, scheduling and remediation while a named specialist performs testing. This can create a smoother client experience, provided the contract and data flows clearly identify every party.

In-house delivery

The MSP employs and governs its own offensive-security team. This provides the most control but requires sustained investment in tester capability, quality review, methodology, insurance, secure evidence handling and professional development.

For most MSPs entering the market, managed coordination with a transparent specialist partner is the practical starting point.

Build authorisation into the workflow

Testing without valid permission can cause serious harm. Before work begins, collect written authorisation from the organisation that owns—or is formally authorised to test—every target.

The rules of engagement should include:

• Legal entity names and accountable contacts.
• Exact domains, applications, APIs, IP ranges, cloud accounts and physical locations in scope.
• Third-party systems that are excluded or require separate approval.
• Testing dates, time zones and maintenance restrictions.
• Allowed and prohibited techniques.
• Source IP addresses where appropriate.
• Critical-finding escalation contacts.
• Stop conditions and emergency communication routes.
• Data retention, deletion and report-distribution rules.

Never assume that an MSP's administrative access grants permission to attack a client's systems. Operational access and penetration-testing authorisation are different things.

Create repeatable scoping inputs

A consistent intake form helps your delivery partner estimate effort without flattening every engagement into the same template.

Web applications and APIs

Record application URLs, technology, environments, user roles, authentication methods, API collections, major workflows, recent changes and test-data constraints. A three-role financial application is not equivalent to a public marketing site simply because both have one hostname.

Networks

Capture internal and external IP ranges, segmentation, directory services, remote access, wireless networks, representative endpoints and assumed-breach access. Decide whether the goal is perimeter exposure, internal attack paths or both.

Cloud

Identify providers, accounts or subscriptions, regions, services, identity model, deployment approach and shared-responsibility boundaries. A cloud penetration test should consider configuration and identity attack paths as well as exposed applications.

Mobile applications

Provide platforms, builds, distribution method, test accounts, API dependencies, certificate-pinning constraints and device requirements. Coordinate mobile and API testing when the application relies heavily on backend services.

Select the testing partner

Evaluate the people and operating model, not only the company brochure. Ask:

1. Who will test each technology and what relevant experience do they have?
2. How are tool- or AI-generated leads validated before reporting?
3. How are critical findings escalated during the engagement?
4. Can the client see and discuss findings before the final report?
5. What evidence and remediation detail does a typical finding include?
6. How does quality review work?
7. What is included in retesting and when does the retest window expire?
8. Where are credentials, screenshots, traffic captures and reports stored?
9. How is data separated between your clients?
10. Which organisational accreditations or individual credentials can be evidenced?

Request a redacted sample report and inspect a finding, not just the executive-summary design. A technically useful report should let an engineer reproduce the issue and let a decision-maker understand why it matters.

Keep every client's data separate

An MSP delivery workflow naturally holds sensitive data from multiple organisations. Treat tenant separation as a primary security control.

• Give each client an isolated workspace and explicit membership list.
• Apply least privilege to MSP staff, client users and testers.
• Never reuse test credentials across clients.
• Store secrets in a purpose-built encrypted mechanism, not tickets or email threads.
• Limit report exports and evidence access to authorised users.
• Record access, status changes and significant project actions.
• Remove access promptly when a team member changes role or leaves.
• Define retention and secure deletion periods contractually.

If the platform cannot explain how a user, project, finding and file are scoped to a client tenant, it should not hold penetration-test evidence.

Design the client journey

A professional service feels joined up from the first scope call to the final retest.

1. Qualification

Confirm why the client needs testing, what decision the report must support, deadlines, mandatory assurance and budget ownership.

2. Technical scoping

Bring the testing team into the conversation. Resolve architecture, roles, boundaries and dependencies before issuing the proposal.

3. Proposal and authorisation

State deliverables, assumptions, days, exclusions, dates, price and retesting terms. Collect acceptance and the rules of engagement through an authenticated process.

4. Readiness

Validate target availability, credentials, allow-listing, test data, backups, monitoring contacts and third-party permissions.

5. Delivery

Give the client a clear status view. Escalate critical issues immediately and make verified findings available as agreed rather than keeping everything hidden until the last day.

6. Debrief and report

Deliver an executive narrative, scope and limitations, methodology, prioritised findings, evidence and remediation guidance. Hold a debrief with both technical and accountable stakeholders.

7. Remediation and retest

Keep ownership and target dates visible. Retest the implemented fix, update the finding status, and issue a clear record of what was fixed, partially fixed or remains open.

Price the outcome honestly

The commercial model may be fixed-price, day-rate, subscription or a committed annual programme. Whichever model you use, the proposal should expose its assumptions.

Avoid promising “unlimited” testing unless the contract explains concurrency, fair use, scope limits and response times. Likewise, avoid creating margin by silently reducing tester days. A narrowly scoped, well-executed assessment is more useful than a broad promise with insufficient depth.

MSPs should also decide who owns:

• Pre-sales scoping time.
• Rescheduling caused by client readiness.
• Urgent out-of-hours escalation.
• Additional roles or assets discovered after scope lock.
• Retests outside the included window.
• Report customisation and compliance mapping.

Clear rules protect the client relationship and the delivery team.

Make recurring testing risk-led

Recurring pentesting can be valuable for clients with frequent releases, sensitive data or contractual deadlines. Build the schedule around events and exposure rather than arbitrary monthly activity.

A typical programme might include:

• Annual external and internal network testing.
• Web and API tests before major releases.
• Targeted cloud testing after material architecture or identity changes.
• Quarterly or biannual tests for the most frequently changing critical applications.
• Retesting after remediation.
• A separate vulnerability-management process between human-led assessments.

Pentesting as a Service can coordinate this portfolio through one delivery workflow. It should increase continuity and shorten feedback loops while retaining the authorisation, tester judgement and evidence expected from a real penetration test.

Measure service quality

Finding count is a poor performance metric. It rewards noise and varies with scope. Better operational measures include:

• Time from scope approval to scheduled delivery.
• Readiness failures caught before testing.
• Time to escalate a critical verified finding.
• Percentage of findings accepted without clarification.
• Median remediation time by severity.
• Retest turnaround time.
• Repeat findings across successive tests.
• Stakeholder satisfaction after the technical debrief.

Use these measures to improve coordination—not to pressure testers into rushing validation or inflating severity.

FAQs

Can an MSP arrange a penetration test for a client?

Yes, but the testing provider needs explicit written authorisation from the organisation that owns or is authorised to test every in-scope asset. The contract should identify the client, target systems, permitted techniques, testing window, contacts and stop conditions.

Should an MSP perform penetration testing itself or use a specialist partner?

That depends on the MSP's offensive-security capability, insurance and governance. Many MSPs use a specialist delivery partner while retaining the client relationship. Responsibilities, data handling, escalation and report ownership should be explicit.

How can an MSP make penetration testing a recurring service?

Build a risk-based testing calendar around major releases, material infrastructure changes and annual assurance needs. Recurring delivery should mean scheduled human-led assessments and retests, not relabelling automated vulnerability scans as penetration tests.

Pentestly can scope a multi-engagement testing programme with an MSP and its client while keeping human ownership explicit. Speak to the team to discuss the environments, delivery model and authorisation path.