Packaging Pentesting Into Your MSP Stack

Pentesting for managed service providers is a packaging problem before it's a technical one. Your clients' auditors, insurers and customers are already asking for a penetration test; the question is what you sell them, how often, at what tier, and with what written into the agreement. MSP Pentesting delivers manual, white-label pentesting only through MSPs, MSSPs, vCISOs and GRC firms, so this is the packaging conversation we have with partners every week. Here's how the ones who make it work structure the offer.

Where pentesting sits in the stack

Most MSP security stacks already have the preventive and detective layers: endpoint protection, patching, a vulnerability scanner, maybe SOC monitoring. Pentesting is the validation layer. It's the only line in the catalog whose job is to prove the rest of the stack holds up against a person trying to get in, and it's the one your client's auditor and cyber insurer ask about by name.

That's why it belongs in the catalog as its own service rather than as a bullet inside "security monitoring." It has its own deliverable (a report your client hands to a third party), its own cadence (driven by the client's framework), and its own economics (project revenue that converts to recurring).

Manual or automated is a packaging decision, not a religion

Automated platforms run a network attack path on a schedule and produce a report in hours. Human-led testing chains findings, tests business logic, works the Active Directory paths a scanner won't, and produces the methodology section an auditor reads. They're different products, and a mature catalog can carry both, labeled honestly.

• Continuous or monthly automated network testing as a standing service, sold as continuous validation.
• An annual human-led penetration test as the test of record, sold as the pentest, with the methodology, evidence and retest that an auditor expects.

The failure mode is selling the first one as the second. A scanner export labeled "penetration test" gets challenged by any competent QSA or SOC 2 auditor, and the challenge lands on you. The differences in depth are covered in AI pentesting versus manual pentesting, and the basics of what a pentest involves for MSP clients are in our overview.

Four packaging patterns that work

The compliance one-off. A client has a SOC 2, PCI DSS or HIPAA date in front of them. You sell a scoped engagement: external and internal network, or a web application, with the retest and an attestation letter included. This is the entry point for most clients and the easiest to close, because the deadline does the selling.

The annual bundle. For clients who show evidence every year, package external plus internal network testing and one application test into an annual line with a fixed price, the retest included, and the report delivered ahead of the audit window. This is where project revenue becomes recurring revenue.

The premium tier. For clients with real exposure (customer-facing applications, regulated data, a cyber insurance policy with conditions), add quarterly application testing or continuous automated validation on top of the annual manual test. Position it as the tier for clients whose customers audit them.

Post-incident validation. After an incident, a scoped test that proves the remediation held and the initial access path is closed. It's also the moment most clients finally agree to the annual bundle.

Cadence by framework

Match the cadence to what the client's framework says, not to what you'd like to sell.

• PCI DSS v4.0.1. Requirement 11.4 calls for internal and external penetration testing at least once every 12 months and after significant changes, with segmentation testing at least every 12 months (every six months for service providers), and correction plus retest of exploitable findings.
• SOC 2. The Trust Services Criteria don't prescribe a frequency; auditors treat an annual test with remediation evidence as the norm, and a retest section closes the loop.
• HIPAA. The Security Rule requires a risk analysis and periodic technical evaluation; an annual test is the common evidence, timed to the risk analysis cycle.
• ISO 27001:2022. Annex A control 8.8 on technical vulnerability management; the auditor wants the test tied to the risk treatment plan, so schedule it against the management review.
• Cyber insurance. Renewal questionnaires increasingly ask whether a penetration test was performed in the policy period. Time the annual bundle to the renewal date and you've removed a renewal risk for the client.

What goes in the agreement

The packaging holds up only if the paperwork does. Your statement of work or service schedule should state, in writing:

1. Scope by asset type and count: external IPs, internal ranges, applications, cloud accounts, and what's excluded.
2. Rules of engagement: testing windows, stop conditions, exploitation limits, who's on call on both sides.
3. Deliverables: the report, the attestation letter, the findings walkthrough, and who attends it under what title.
4. Timelines: scheduling lead time and days from test close to final report, because audit dates don't move.
5. Retest: included or not, and inside what window.
6. Cadence and renewal: when the next test happens, tied to the client's audit or renewal date.

Every one of those is a question your client's auditor may ask. Writing them down before the engagement is what makes the report survive the evidence request afterward.

Pricing the package

You buy at a partner rate and sell at your price. Two rules keep the margin predictable: quote from a fixed partner price list rather than a per-deal quote, and bundle the retest into the client price rather than listing it separately. The full economics, from margin structure to how to set the client price, are in the MSP guide to profitable pentesting and the worked numbers are in reseller pricing math for MSP pentesting.

Choosing the back end

None of this packaging works if the firm doing the testing sells to your client afterward, or ships a report your client's auditor sends back. Choosing that firm is its own evaluation: tester credentials, methodology, auditor fit, safe testing in regulated environments, white-label report quality, channel terms, insurance, retest and turnaround. We keep it in one place, how to vet penetration testing providers, and the contract side in how to vet a pentest vendor's channel terms.

For our part: channel-only, with a 24-month non-solicit in every reseller agreement; testers holding OSCP, CREST and CEH; the report under your brand or under ours as a named independent assessor; and a free retest on a timeline scoped to the engagement, so the closing evidence exists. Built for MSPs serving SMB and mid-market clients, and priced so the packages above have margin in them.

Frequently asked questions

Can I sell automated pentesting as the annual pentest?

You can sell it; the client's auditor decides whether it counts. For PCI DSS the methodology requirement in 11.4.1 makes a scanner-only result a hard sell. For SOC 2 it's the auditor's judgment. Sell automated testing as continuous validation and the human-led test as the pentest of record, and you never have the argument.

How do I introduce pentesting to clients who've never bought one?

Start from their obligation, not from the threat landscape. Their auditor, their insurer or their largest customer is already asking; show them the questionnaire line and offer the compliance one-off with the retest included. The annual bundle comes at the findings walkthrough.

Should the tester be on the client call?

Yes, for the findings walkthrough, under your rules and a title you choose. Clients ask better questions with the person who did the work in the room, and your partner agreement should say the tester joins as your security team and that no follow-up leaves the vendor's side without going through you.

Next step

If you want to see what the packages above look like with real numbers, get a pentest quote for one client engagement, or read how the partner program is structured before you call.