White-Label Penetration Testing Agreement: Scope, Evidence, and Liability

An agency wins a new SaaS client, and the client’s enterprise prospect requests an independent penetration test before signing. The agency can arrange qualified testing under its own brand. Then procurement asks who will authorize production testing, who can receive the raw evidence, whether the actual tester can be identified, and who pays if a retest falls outside the delivery window.

Those questions cannot be settled by placing the agency’s logo on a report. A white-label penetration testing agreement must connect the agency’s promise to its client with the testing partner’s authority, access, deliverables, and obligations. A gap between those two arrangements can leave the client with incomplete assurance, the agency with an unpriced commitment, or the tester with unclear instructions during a sensitive finding.

This guide is for agency owners, MSP leaders, consultancy founders, and procurement teams evaluating that arrangement. It gives you a buyer checklist, an agreement-clause matrix, and decisions to make before issuing credentials. It is a practical scoping guide, not a substitute for counsel reviewing the governing contract and applicable law.

Why a white-label penetration testing agreement matters

White-label delivery usually involves three parties: the end client that owns or operates the systems, the agency that manages the commercial relationship, and the specialist that conducts the test. The agency may own the client conversation and present the final deliverable, but it does not automatically acquire permission to authorize every activity on the client’s infrastructure. Likewise, the testing partner may have technical access without permission to contact the client directly or reuse client evidence.

The white-label penetration testing delivery model explains the available partnership structure. The agreement for an individual engagement still needs to translate that model into named systems, authorized activities, reporting routes, and commercial commitments. A master partnership agreement can establish standing terms; an engagement-specific statement of work and rules of engagement should describe what this particular client has approved.

Start by comparing three documents: the agency’s contract with the end client, its agreement with the testing partner, and the engagement’s written authorization or rules of engagement. Each should tell a consistent story about scope, dates, deliverables, data handling, escalation, and retesting. If the client expects a production API assessment but the subcontractor’s scope covers only a staging web interface, the branding is irrelevant to the assurance gap.

As a useful control, name one decision-maker at each organization. The client authorizes its environment and owns risk acceptance. The agency coordinates the relationship and commitments it sells. The tester controls its testing methods within the approved boundaries and promptly reports material observations through the agreed channel. The contract should specify when a decision must move beyond the routine account-contact chain, particularly during a suspected exposure or service disruption.

Define white-label pentest scope and testing authority

A signed NDA protects information, but it is not a complete authorization to test. NIST’s definition of rules of engagement describes the guidelines and constraints established before a security test that authorize the team to perform defined activities. For an agency engagement, the end client’s authorization must reach the actual testing provider through a clear, documented chain. Counsel can determine the appropriate signature and delegation language for the parties and jurisdiction.

Define the assets by environment and identifier, not by a broad label such as “the platform.” Record domains, applications, APIs, mobile builds, cloud accounts, third-party integrations, and tenant or role boundaries where applicable. Distinguish production from staging, approved test accounts from real customer accounts, and first-party assets from services requiring another owner’s consent. Document material exclusions so that a clean report cannot be mistaken for assurance over something never tested.

Scope should also say what the tester is expected to prove. For a SaaS product, a basic unauthenticated review and a multi-role authorization assessment answer different buyer questions. If the client needs evidence that users cannot cross tenant boundaries, the agency should budget for suitable roles, test data, workflows, and review time. Our guide to multi-tenant SaaS authorization scope describes why that depth changes the evidence and effort required.

Use established methods as a reference for coverage, without treating a framework name as the whole statement of work. The OWASP Web Security Testing Guide is a methodology reference for web applications. The OWASP API Security Top 10 identifies relevant categories such as API1:2023 Broken Object Level Authorization, API3:2023 Broken Object Property Level Authorization, and API5:2023 Broken Function Level Authorization. A client-facing scope should explain which risks and business workflows will be examined and which are outside the fee. It should not promise “full OWASP coverage” without defining the system and test depth.

Set the operational limits as well: testing window and time zone; authorized source addresses if needed; rate or load constraints; use of sensitive or live data; prohibited techniques; account provisioning; stop conditions; and an emergency contact reachable during the test. Specify whether the tester may continue after observing an unexpected sensitive result or must pause for approval. If a critical finding appears late in the window, the escalation procedure matters more than the planned date of the final report.

Agreement-clause matrix for agency review

Use the matrix as a negotiation checklist, not boilerplate. A small staging assessment and a production, multi-tenant, compliance-driven engagement should not carry identical access rules or evidence obligations. The agency should test whether the client-facing promise can actually be delivered under the subcontractor’s signed scope.

Set evidence custody, ownership, and reporting rights

Pentest evidence can include screenshots, request and response excerpts, account details, configuration observations, and proof that a business boundary failed or held. Some items may contain customer information or secrets. The agreement should separate ownership or licensed use of the deliverable from custody of working evidence. Otherwise, “the client owns the report” may be misread as permission for every party to retain or circulate raw material indefinitely.

Decide what the tester may collect, how sensitive values will be minimized or redacted, where evidence may be stored, who can access it, and how it will move to the agency or end client. Agree on retention and deletion triggers, including what must be kept for an agreed retest, dispute, or legal preservation requirement. A confidentiality clause alone does not answer these operational questions. Where client-specific regulatory duties apply, the agency should have its privacy and legal advisers confirm the correct processing and transfer terms.

The final report should identify the authorized scope, test period, methodology at an appropriate level, limitations, findings, severity rationale, impact, remediation advice, and status of any retest. Ask to inspect a sample penetration testing report before agreeing to a branded format. Decide whether the end client receives only the final report, a technical annex, a management summary, or all three. Restrict distribution of sensitive appendices without removing the detail needed for engineering to fix findings.

Branding and independence need an explicit rule. A report may carry the agency’s logo while still truthfully describing the testing provider’s qualifications when the end client, auditor, insurer, or enterprise buyer asks. The parties should agree on who can attest to the work, whether the tester can join a technical debrief, and how identities will be disclosed where contractual or procurement questions require them. White-label delivery should never depend on making a false statement about who conducted the assessment.

Keep a version history. If the agency edits layout or adds an executive cover, it should not silently change a finding, severity, limitation, test date, or retest conclusion. Specify who approves substantive revisions and how the final, signed-off version is identified. That protects the agency as much as the end client when a later security questionnaire cites the report.

Assign remediation, retesting, and escalation before delivery

Testing identifies and validates conditions; the end client normally controls its code, infrastructure, and change process. The agency may coordinate remediation or sell implementation work, but that is a separate responsibility to define. The agreement should name who receives each finding, who decides priority and risk acceptance, who implements a fix, and who asks the independent tester to verify it.

One included retest can mean different things unless the terms identify the window, eligible findings, affected environment, number of cycles, prerequisites, and output. Does it begin on report delivery or after the client submits fixes? Is it limited to the original findings and scope? What happens if a major release changes the application or the client misses the window? The client-facing proposal and subcontractor agreement must answer those questions consistently. The remediation ownership plan gives client teams a practical way to assign findings and assemble closure evidence.

Define an urgent path separately from the ordinary reporting schedule. The tester should know whether a high-impact observation goes first to the agency security lead, the end client’s incident contact, or both. Record who is empowered to stop testing, preserve relevant evidence, and decide whether an incident response process is needed. A suspected active compromise should not be handled as another finding awaiting a formatted report. NIST SP 800-61 Rev. 3 provides a current reference for integrating incident response into wider cybersecurity risk management.

For routine work, set checkpoints around kickoff, access readiness, testing completion, draft review, final report, and retest. A delivery date is meaningful only if the client supplies accounts and approvals on time. Make delays visible and assign the decision about a revised schedule. A change-control route should cover newly discovered assets, extra roles, an expanded environment, or a requested deadline change before extra effort is performed or promised.

Hypothetical scenario: An MSP sells a branded API pentest to a healthcare SaaS client ahead of an enterprise review. The client expects testing across administrator, clinician, and patient roles. The subcontractor’s signed scope provides only one standard account. During testing, an authorization issue requires another role to confirm its impact, but the additional account takes four days to approve. The agency has already promised a final report that week. A defined scope matrix, access-readiness gate, and schedule-change rule would make the limitation and revised delivery decision visible before the client relies on a partial assessment.

Address disclosure, liability, and the commercial handoff

A white-label arrangement can protect the agency’s client relationship without obscuring facts a buyer is entitled to know. Specify whether the testing firm may contact the client, attend calls, use the client’s name, publish a case study, or approach the client for other work. The live Pentest Testing Corp partnership page describes restrictions on direct client contact and use of client data; the executed agreement should state the terms that govern the specific relationship.

Ask whether further subcontracting is permitted and, if so, how approval works. Identify who will access production systems and evidence, what confidentiality obligations bind them, and whether a substitution requires notice. Enterprise procurement may request tester identity, qualifications, location, or an explanation of subcontracting. Agree on a truthful response before the questionnaire arrives. The same principle applies when evaluating a specialist for AI systems: the questions in our guide to selecting an AI testing firm help distinguish provider competence from a broad service label.

Liability deserves a comparison across the contract chain, not a quick acceptance of a single number. A liability cap is generally a ceiling on specified claims under an agreement; it is not an upfront payment to the partner. Its practical effect depends on the clause’s wording, applicable law, exclusions, and the claims involved. Counsel should compare the agency’s obligations to the end client with the subcontractor’s obligations to the agency, including confidentiality, mishandled evidence, unauthorized activity, service disruption, and intellectual-property or reporting disputes.

Review the basis of each cap: a fixed amount, fees paid or payable under an engagement, or fees during a defined period. Then review what sits outside the cap, if anything; how indirect loss is treated; whether the parties owe indemnities; and how claims are notified and defended. Do not assume that a larger client-facing commitment automatically flows through to the tester. Ask for relevant insurance details and verify whether the contemplated activity fits the coverage. These are legal and commercial allocation questions, so have counsel negotiate the operative language.

Commercially, align the quote with the work. Record wholesale fee and payment triggers, what the agency may charge its client, expenses, taxes where relevant, rush work, added assets, aborted windows, retest extensions, and support for procurement questions. A fixed fee only controls cost when its assumptions and change process are clear. The agency should also decide who is allowed to approve additional work; a casual request from the client’s engineer should not silently become an unpriced obligation.

What leadership should decide before signing

The agency owner or practice lead should make six decisions and have the resulting answers reflected in the documents and operating contracts:

1. What are we promising? State the product, environments, test depth, report, debrief, and retest in terms an end-client security reviewer can verify.
2. Who authorizes the actual tester? Confirm asset ownership, any third-party permissions, the approval chain, rules of engagement, and stop authority.
3. Who controls the evidence? Approve minimization, custody, access, transfer, report distribution, retention, and deletion rules before credentials are shared.
4. How will we handle a serious finding? Name the urgent contacts, notification route, incident handoff, and person who can pause testing.
5. Can we answer procurement truthfully? Decide how to disclose the tester, qualifications, methodology, limitations, subcontractors, and retest status when asked. The evidence questions in an AI red teaming vendor questionnaire illustrate how quickly a buyer can move beyond a report title.
6. Do the economics and risk terms match? Compare both contract layers for scope changes, fees, retest obligations, confidentiality, insurance, liability, and termination.

For a prospective partner, request a sample report and a proposed engagement package: master terms, statement of work, rules of engagement, data-handling schedule, escalation contacts, and retest terms. Run one realistic client opportunity through them. If the documents leave a key promise to be decided after kickoff, resolve it before committing to the end client.

SOC 2 and ISO/IEC 27001 considerations reinforce this discipline, but neither should be presented as a blanket requirement for a particular contract clause or liability amount. AICPA describes outsourcing risks that organizations need to identify, assess, and manage. ISO/IEC 27036-2 addresses requirements across supplier and acquirer relationships. The practical aim is to show that the provider relationship and its evidence are governed in a way appropriate to the client’s risk and audit scope.

Ready to evaluate the model?

Review Pentest Testing Corp’s white-label partnership options, then bring a representative client scope to the discussion. Agree on authorization, evidence, disclosure, escalation, and retesting before making the client-facing commitment.