How to Vet Penetration Testing Providers

Vetting penetration testing providers is a different job when you're the one who'll resell the work. You're not buying a test. You're buying a deliverable your client's auditor will open, a tester who'll be inside a regulated network under your name, and a contract that decides whether the vendor is standing next to you at renewal or across the table. MSP Pentesting sells only through MSSPs, MSPs, vCISOs and GRC firms, so we sit on one side of this evaluation and won't pretend otherwise. What follows is the checklist we'd want a partner to run on us.

Most content about penetration testing service providers is written for an end client buying one test. You already run detection and compliance in-house, so this one skips the explainer and gets to the questions that separate pen test vendors you can resell from ones you can't.

Three questions that end most conversations

1. Do you sell to end clients? If the answer is yes, or "not usually," every referral you make is a lead in their CRM, and everything adjacent to the pentest becomes their retention play on your client.
2. Who, by name, will be on my engagement? Websites list the firm's best credentials; your engagement gets whoever is free that week. Ask for names, certifications, and whether any of the work is subcontracted.
3. Can I see a redacted report from a comparable scope? Not a template. A real one. If it's a scanner export with a cover page, you've just learned what you'd be putting your name on.

A provider that fails one of these isn't a partner, whatever else it is.

Tester credentials: what OSCP, OSEP and CREST actually tell you

Certifications are a floor, not a verdict. They're still the fastest way to separate people who can exploit from people who can talk about it.

• OSCP (OffSec Certified Professional) is a hands-on exam: compromise live machines in a lab inside a fixed window, then document it. It proves someone can get from a foothold to a domain user without a scanner holding their hand. Treat it as the minimum for internal network work.
• OSEP (OffSec Experienced Penetration Tester) covers evasion and Active Directory attack paths against defended environments. It matters when your clients run EDR that actually works and you want the test to reflect that.
• CREST operates at two levels. Member company accreditation means the firm's processes, methodology and data handling were assessed. Individual certifications such as CRT and CCT sit on top of that. When a provider says "we're CREST," ask which one they mean.
• CEH is primarily a knowledge exam. It tells you someone studied. We hold it too; we don't lead with it.

Then the question that matters more than any acronym: what's the split between manual work and tool time, and how do they prove it? Look for it in the sample report. Chained findings, business-logic flaws, a privilege escalation path written as a narrative. Scanners don't write narratives.

Documented methodology, and what "documented" means

You want a written methodology you can hand to a client's auditor, and a scoping process that produces a rules-of-engagement document before anyone touches a keyboard.

The references a serious provider will map to:

• PTES for the overall engagement structure.
• OWASP Web Security Testing Guide for web applications, and the OWASP MASTG for mobile.
• NIST SP 800-115 for the assessment approach and the vocabulary auditors recognize.
• MITRE ATT&CK for technique mapping, so findings translate into detection work for your SOC instead of sitting in a PDF.

Mapping to a framework is cheap. What you're testing is whether the methodology shows up in the deliverable: what was in scope, what was excluded and why, which techniques were attempted and failed, where the testers stopped. A report that only lists what was found tells an auditor nothing about coverage.

Will the report survive your client's auditor?

This is the test most vendors fail quietly. The report looks fine, it gets attached to the evidence request, and the auditor comes back with questions nobody on the call can answer.

What auditors actually check, by framework:

• SOC 2. The Trust Services Criteria never say "penetration test." Auditors typically map it to CC4.1 (separate evaluations) and CC7.1 (identifying vulnerabilities). They'll want scope, dates, tester independence, findings and remediation evidence. A retest section closes the loop.
• PCI DSS v4.0.1. Requirement 11.4 is explicit: a defined methodology (11.4.1), internal and external tests at least every 12 months and after significant changes (11.4.2 and 11.4.3), exploitable findings corrected and retested (11.4.4), and segmentation testing where the CDE is segmented (11.4.5, moving to every six months for service providers under 11.4.6). A QSA reads the methodology section, so it has to exist.
• ISO 27001:2022. Annex A control 8.8 covers technical vulnerability management, and the ISO 27002 guidance for it names penetration testing. The auditor wants the test tied to the risk treatment plan.
• HIPAA. The Security Rule requires a risk analysis and periodic evaluation (45 CFR 164.308(a)(1)(ii)(A) and 164.308(a)(8)). A pentest is the common evidence for both, so the report has to speak in terms of ePHI exposure, not CVSS scores alone.

Two deliverables worth insisting on: a report structured the way auditors read them (hand your vendor what auditors actually look for in a pentest report as the spec), and a letter of attestation the client can share with customers and insurers without disclosing findings.

Safe testing in regulated and OT environments

Clients in healthcare, finance and manufacturing won't tolerate a tester who treats production like a capture-the-flag. Ask how the provider handles:

• Testing windows and stop conditions. Who's on call on both sides, what triggers a halt, how fast it happens.
• Exploitation limits. Denial of service is out unless explicitly scoped. Exploits against fragile services get validated in a non-production copy first, or documented as likely exploitable with evidence, not fired at a database server at two in the afternoon.
• Data handling. What gets pulled as proof (a row count, not the rows), where evidence lives, when it's destroyed.
• OT and ICS. A loud port scan can stop a PLC. A malformed Modbus packet can lock up a building management system. NIST SP 800-82 Rev. 3 is blunt that active scanning and exploitation can disrupt control systems, and IEC 62443 assumes the same caution: passive discovery on live segments, active work only against spares, test rigs or inside a change window. A provider that "does OT too" with the same team and tooling as its IT work is a no. Our OT and ICS work runs through a separate practice, Cascadia OT Security, with its own operations team and safety constraints.

White-label report quality

Your logo on a bad report is worse than no report. The split of labor is simple (who does the work in a white-label service); the quality bar isn't. Judge the sample on three things.

Structure. An executive summary a board member can read in two minutes, a findings section an engineer can act on the same afternoon, an evidence appendix. Findings ranked by real exploitability and business impact, not sorted by CVSS.

Voice. The report should read like your firm wrote it. No vendor fingerprints in the document metadata, no "tested by" footer unless you've chosen the attested version on purpose, no tool screenshots carrying another company's watermark.

Rewrites. Ask whether they'll rework a finding's wording when your client's compliance lead wants it phrased differently. Most won't. The ones who will understand the report is your product, not theirs.

Our sample pentest report shows the structure we deliver under partner branding, and the white-label pentesting service page covers what changes on the cover, in the footer and in the metadata. Compare every vendor's sample against something, even if it isn't ours.

Non-solicit and channel terms

This section decides whether you still hold the account in three years.

"We don't poach" is not a contract term. Look for:

• A written non-solicitation clause covering both the engagement and the client relationship, with a stated duration that survives termination of your agreement. Twelve months is the floor.
• A no direct marketing commitment. Your client never receives the vendor's newsletter, webinar invite or renewal reminder.
• Clarity on who owns the relationship in every artifact: report, attestation letter, scoping call, findings walkthrough.
• A direct sales pipeline you're allowed to ask about. If one exists, your referrals eventually flow into it, whatever the clause says.

We wrote up the full list of clauses to check in how to vet a pentest vendor's channel terms. Short version: our reseller agreement carries a 24-month non-solicit, and we have no direct sales motion to end clients, which is the only reason that clause is easy for us to sign.

Insurance, liability and what happens when something breaks

Ask for the certificate of insurance before you sign, not after an incident. You want professional liability (errors and omissions) and cyber liability, with limits that make sense against what your own MSA promises clients. Then read the vendor agreement for:

• Limitation of liability, and whether it's capped at the fee. It usually is; know that going in and price it into your own terms.
• Indemnification for claims arising from the tester's negligence.
• Authorization language: the client signs the rules of engagement, and the provider holds signed authorization for every target, including assets hosted by a third party.
• Incident handling: if a test takes a system down, who calls whom, and who pays for recovery.

None of this is exotic. A provider that has done real channel work has these documents ready; one that gets defensive is telling you something useful.

Retest policy and turnaround

Two operational questions that separate a partner from a vendor who makes you look slow.

Retest. Is remediation verification included, and inside what window? A pentest without a retest leaves your client with an open findings list and no closing evidence for the auditor. Some providers sell the retest separately, which you either absorb or pass on. We include it, on a timeline scoped to the engagement, so the closing evidence exists.

Turnaround. Three numbers: quote time on a signed scope, scheduling lead time, and days from test close to final report. Audit dates don't move. A provider quoting six-week lead times in the fourth quarter costs you either the deal or the audit.

Pricing is an operational question here, not the headline. You're buying at a channel rate and selling at yours, so what matters is a fixed partner price list you can quote from without a call. How managed security pricing models work and the economics of reselling pentests matter more than the sticker price.

The scorecard: nine criteria, one table

Put every provider through the same table. One call and one sample report fill most of it in, and the pen testing firms that resent the exercise have answered the channel question for you.

Run one paid engagement before you commit

Don't sign a partner agreement off a sales call. Buy one scoped engagement for a client you know well, ideally one with an audit date, and judge the full cycle: scoping, communication during the test, report quality, how they handle a disputed finding, and the retest. One real engagement tells you more than any RFP.

To see how the options stack up before you shortlist, we've ranked the best penetration testing companies from a reseller's perspective, and broken down the types of penetration testing firms and which resale model each is built for.

Frequently asked questions

Does the provider need to be independent of my firm for audit purposes?

For most frameworks the tester has to be organizationally independent of whoever built and runs the systems. PCI DSS 11.4.1 requires organizational independence of the tester, and SOC 2 auditors prefer an external party. That's what the attested third-party option is for: the report names MSP Pentesting as the independent testing firm, while you still run the scoping, the client relationship and the billing.

Manual or automated: does the auditor care?

Auditors care about scope, method and evidence. A scanner run labeled "penetration test" gets challenged by any competent QSA or SOC 2 auditor, because the methodology section can't describe what the tool didn't attempt. Ask the vendor to state the manual-to-tool split in writing.

What if a client insists on picking their own pentest vendor?

Some will, especially in finance. Offer the attested version: your firm coordinates, an independent named provider tests, and the report says so. Most clients want the auditor satisfied and one accountable party, not a fourth vendor relationship.

Can one provider cover IT, cloud and OT?

Rarely well. IT and cloud, yes. OT needs a different methodology and safety discipline. If OT is staffed by the same team with a Modbus plugin, refer that scope somewhere else.

Next step

Run the scorecard on us. Our partner program is channel-only by contract, the team holds OSCP and CREST credentials, the report ships under your brand, and the retest is included. Get a pentest quote for one engagement and judge the full cycle for yourself.