White-Label Penetration Testing: An Operational Playbook for Audit Firms and MSPs

White-label penetration testing lets audit firms and MSPs offer certified security testing under their own brand, without hiring, training, or managing testers in-house. The four standard partnership models are white-label delivery, revenue share, referral, and subcontracting. Each model distributes scope, delivery responsibility, and margin differently. Choosing the wrong one creates client relationship problems, delivery gaps, or margin compression that compounds across every engagement.

This playbook breaks down each model operationally: how delivery actually works, what you own versus what your partner owns, where things go wrong, and what to verify before you sign anything.

Why Audit Firms and MSPs Are Adding Penetration Testing Without Hiring Testers

SOC 2, PCI DSS, and HIPAA audits increasingly require evidence of penetration testing, not just a vulnerability scan. Auditors at regional CPA firms are watching their clients arrive with scanned PDFs that do not satisfy the testing requirement and then scrambling to find a testing firm mid-audit. MSPs are seeing the same pattern: a managed client gets a cyber insurance renewal requirement, needs a pen test letter within 30 days, and calls the MSP first because they manage the environment.

Hiring a full-time OSCP-certified tester costs between $110,000 and $160,000 annually in fully loaded compensation, before tools, lab infrastructure, and the management overhead that comes with running offensive security engagements. For firms doing fewer than 20 engagements per year, the economics do not work. A partnership model lets you capture the revenue and satisfy the client relationship without that fixed cost structure.

The compliance driver is real and measurable. PCI DSS v4.0 Requirement 11.4 requires annual penetration testing and segmentation testing for in-scope systems. HIPAA's Security Rule (45 CFR §164.308(a)(8)) requires covered entities and business associates to conduct periodic evaluations of security measures, which OCR guidance and most HIPAA-focused auditors interpret as including penetration testing. When your clients need this, they will find someone to provide it. The question is whether that someone is you, or a competitor.

Penetration Testing Partnership Models: How Each One Actually Works

The four models below cover every commercial arrangement a testing firm offers to channel partners. Understanding the operational mechanics of each one is what separates a partnership that scales from one that breaks down on the third engagement.

1. White-Label Delivery

Your firm sells the engagement, scopes it with the client, and signs the statement of work. The testing firm executes the engagement entirely behind the scenes. The final report carries your logo, your firm name, and your contact information. The client never knows a third party was involved.

What you own: the client relationship, the scoping conversation, the commercial terms, and the report delivery meeting.

What the testing firm owns: methodology execution, exploitation, findings documentation, technical remediation guidance, and CVSS scoring.

This model works best when you have a consistent client base with recurring testing needs and you want to build a repeatable service line. Margin is highest here because you set the price and absorb the full spread between your rate and the testing firm's wholesale rate.

The operational risk in white-label delivery is report quality. You are presenting the report as your own work, which means any methodological gap, finding miscalculation, or remediation guidance error reflects directly on your firm. Before committing to white-label delivery, review a sample report in full. Specifically, verify that the report distinguishes manual findings from automated scan output, that each finding includes a proof-of-concept evidence section, and that remediation guidance is specific to the technology stack rather than generic.

Download a sample report to evaluate IVASTA's documentation standard before any conversation about partnership: IVASTA-security.com/IVASTA-penetration-test-sample-report.

2. Revenue Share

You introduce clients directly to the testing firm and receive a percentage of the closed engagement value. The testing firm handles scoping, delivery, and reporting under its own brand. You stay involved as the relationship holder but have no delivery responsibility.

Revenue share percentages in the penetration testing market typically run between 10% and 20% of the engagement value, depending on deal size and exclusivity arrangements. On a $15,000 web application and API penetration test, that represents $1,500 to $3,000 per referral with zero hours of delivery work.

This model suits firms that encounter penetration testing demand incidentally, where it is not a core service line but comes up regularly enough to warrant a formal arrangement. The operational ask is minimal: make the introduction, confirm the client's authorization to proceed, and let the testing firm carry the engagement.

3. Referral

A referral arrangement is structurally similar to revenue share but typically involves a flat fee rather than a percentage, and often operates without a formal partnership agreement. You refer a client, the testing firm closes and delivers the engagement, and you receive a one-time referral payment.

The distinction from revenue share matters for accounting and relationship management. Referral fees are one-time and transactional. Revenue share implies an ongoing arrangement with tracking, reporting, and usually a signed partner agreement.

For audit firms that encounter testing needs from two or three clients per year, a referral arrangement requires the least administrative overhead. The risk is that without a formal agreement, referral payments depend entirely on the testing firm's goodwill and tracking. Get the referral fee structure in writing even if the overall arrangement feels informal.

4. Subcontracting

Subcontracting means your firm holds the prime contract with the client and places the testing firm as a named or unnamed subcontractor in your delivery team. You bear full delivery accountability to the client. The testing firm delivers to your SOW requirements rather than their own standard format.

This model is most common when a client has procurement or compliance requirements that mandate a single-vendor relationship. Government contractors, healthcare enterprises, and large financial institutions sometimes require this structure for regulatory documentation purposes.

Subcontracting requires the most operational coordination. You need to define the deliverable format precisely in your subcontract agreement, establish clear rules of engagement sign-off procedures, and build in review time before the report goes to the client. Plan for a minimum 48-hour review window between receiving the draft report and client delivery.

Partnership Model Comparison: What You Own at Each Stage

The table below maps the four models against the six operational stages of a penetration testing engagement. Use this to identify where your firm's involvement begins and ends under each structure.

What Delivery Actually Looks Like: From Scoping Call to Final Report

The process below describes a white-label engagement where your firm owns the client relationship and the testing firm operates entirely behind the scenes. Adjust ownership labels for other models using the table above.

1. Scoping call (your firm leads). You define the target environment with the client: URLs, IP ranges, authentication levels, business-logic flows to test, and any systems to exclude. You collect this information and pass a structured brief to the testing firm. The testing firm uses this to generate a detailed statement of work and rules of engagement document.
2. Rules of engagement sign-off. The rules of engagement document specifies: testing window (dates and hours), authorized IP ranges or hostnames, emergency contact procedures if a production system is impacted, and any explicit exclusions. Your firm reviews this for accuracy, then presents it to the client for signature. Do not allow testing to begin without a signed authorization document, regardless of how trusted the client relationship is.
3. Reconnaissance and threat modeling. The testing firm begins with open-source intelligence gathering against the target, passive subdomain enumeration, and technology stack fingerprinting. For web application engagements, this phase identifies the authentication mechanisms, API surface, and third-party integrations before any active testing begins. See what web application penetration testing covers in full scope.
4. Active testing phase. This is where manual exploitation differentiates the engagement from an automated scan. A skilled tester chains findings together: a verbose error message reveals a framework version, that version has a known deserialization vulnerability, the tester confirms exploitability manually and documents the full attack path. Automated scanners identify the error message. They do not execute the exploit chain. For API-heavy applications, business logic flaws including BOLA (broken object level authorization) and mass assignment vulnerabilities require manual testing by design. API penetration testing methodology covers these vulnerability classes in detail.
5. Draft report delivery to your firm. The testing firm delivers the draft report to you, not the client. Your review window (48 hours minimum, 72 hours recommended) lets you verify findings, flag anything that needs clarification, and prepare your delivery narrative. In white-label delivery, you present the report as your own work. Know what is in it.
6. Client-facing debrief. You present findings in a walkthrough call, organized by severity and remediation priority. The testing firm is available behind the scenes if a technical question arises that you want to escalate. This call is the highest-value moment in the client relationship: it is where you demonstrate security expertise and justify the engagement cost.
7. Remediation support and retest. After the client addresses critical and high findings, a retest confirms that the remediations are effective. This is typically scoped as a separate line item or included at a reduced rate within the original engagement. Either way, make sure the retest scope is defined in the original SOW before you sign.

How to Vet a White-Label Penetration Testing Partner: Eight Non-Negotiables

These are the criteria that separate a testing firm that will protect your client relationships from one that will damage them. Every one of these is verifiable before you sign a partnership agreement.

• Manual testing evidence. Ask for a sample report. Confirm that findings include proof-of-concept screenshots or request/response captures, not just CVE references. A CVE reference with no exploitation evidence is automated scanner output.
• OSCP or equivalent certifications. OSCP (Offensive Security Certified Professional) is the minimum bar for credible penetration testers. OSEP and CRTO certifications indicate more advanced capability. Ask which certifications each tester holds, not just whether the firm has certified testers.
• Rules of engagement process. A competent testing firm has a documented rules of engagement template and requires client authorization before any active testing begins. If a firm starts testing without a signed authorization document, that is a legal and relationship liability you absorb in white-label delivery.
• Report turnaround SLAs. Draft reports should arrive within five business days of testing completion for standard engagements. Longer turnarounds create client relationship problems, especially when the testing timeline was communicated up front.
• Confidentiality and NDAs. The testing firm must sign a mutual NDA covering the client's environment details, findings, and the existence of the partnership. In white-label delivery, the client cannot know the testing firm's name. This requires a specific confidentiality clause, not a general NDA.
• Insurance coverage. The testing firm should carry professional liability (errors and omissions) and cyber liability insurance. Ask for a certificate of insurance. Penetration testing carries inherent risk of system disruption; you need to know that coverage exists if something goes wrong.
• Scope of services available. Confirm that the testing firm covers the full range of services your clients are likely to need: web application penetration testing, internal network penetration testing, external network penetration testing, cloud security assessments, and vulnerability assessments for clients who need scoping clarity before committing to a full test.
• Communication model during testing. Confirm whether and how your firm gets status updates during the active testing phase. For white-label delivery, you need enough visibility to answer basic client questions without exposing the subcontractor relationship.

Running the Scoping Conversation With Your Client

The scoping conversation is where white-label delivery is won or lost. If you collect incomplete information, the testing firm either widens scope (increasing cost) or narrows it without telling you (reducing value). The client notices the gap when they see the report.

Collect these specifics in every scoping conversation:

• Application type: single-page application, monolith, microservices, mobile with API backend
• Authentication mechanisms: username/password, SSO, MFA, API key, OAuth 2.0 flows
• User roles in scope: anonymous, authenticated standard user, authenticated admin, service-to-service
• Third-party integrations that process client data or handle authentication
• Known sensitive data flows: PHI, PII, cardholder data, financial records
• Explicit exclusions: production databases, specific IP ranges, third-party vendor systems not under the client's control
• Compliance context: whether the test is for SOC 2, PCI DSS, HIPAA, cyber insurance, or internal assurance

The compliance context changes the report format requirements. SOC 2 Type II auditors want to see that the test was conducted within the audit period and that findings were remediated or accepted with documented risk. PCI DSS requires testing against all in-scope cardholder data environment components. Knowing this before testing begins means the report structure matches the evidence requirement.

Where White-Label Partnerships Break Down

Most partnership failures fall into one of three categories. Knowing them before you commit saves you from discovering them on a live engagement.

Scope Creep Without Authorization

The testing firm finds a subdomain outside the agreed scope and tests it anyway. This is well-intentioned but creates serious legal and contractual risk. Penetration testing authorization is document-specific. Testing outside the authorized scope, even if the client owns the asset, can void the rules of engagement and expose both parties to liability. Your partnership agreement must require the testing firm to halt testing and seek written authorization expansion before touching anything outside the original scope.

Finding Quality Variance Between Testers

Testing firms with larger teams often rotate testers across engagements. The lead tester on your first engagement may not be the tester on your third. Ask whether engagements are assigned to named testers or a rotating pool, and whether the testing methodology is standardized enough that tester rotation does not create report quality variance. Review the first three reports from any new partner more carefully than you will review later ones.

Confidentiality Exposure

A tester on a white-label engagement mentions the testing firm's name in a Slack message to the client's DevOps team. The client discovers they are not working directly with your firm. This happens more than it should, and it is almost always accidental. Your NDA should include a specific clause prohibiting testing firm personnel from disclosing the nature of the subcontracting relationship, in writing or verbally, during or after the engagement.

The Mutual Referral Model: How Partnerships Flow Both Ways

The most durable channel partnerships are bidirectional. Your firm refers penetration testing clients to the testing firm. The testing firm refers IT management, compliance, and infrastructure clients to you.

IVASTA Security works with audit firms and MSPs whose clients need penetration testing, and refers IT management, compliance readiness, and infrastructure work back to partners when that work arises within our client base. Neither side requires exclusivity. Both sides grow the relationship by performing well on referred work.

A mutual referral structure creates natural quality accountability. If you refer a client who receives poor testing and is unhappy, they may leave your firm as a managed client. The same incentive works in reverse. The structure aligns interests more cleanly than a one-directional commission arrangement.

Starting a Partnership with IVASTA Security

IVASTA Security's testers are OSCP-certified and execute manual penetration tests against web applications, APIs, internal networks, external networks, and cloud environments. Every engagement includes manual exploitation, business logic testing, and a written report that distinguishes manual findings from automated scan output.

The partnership conversation starts with a 30-minute scoping call where we establish which model fits your practice, confirm what your clients' compliance requirements look like, and review a sample report together so you know exactly what your clients will receive.

Request a partnership scoping call at IVASTA-security.com/contact-us. We respond within one business day to confirm availability and send the sample report in advance of the call.