Agency client handoff checklist
What an agency should settle with its client and its testing provider before, during and after a penetration test on a client project, from SOW and authorisation to report routing, fixes, retest and honest attribution.
In agency work, a penetration test involves three parties: the client who owns the system, the agency that built or runs it, and the provider doing the testing. Most handoff problems come from unspoken assumptions between them. Who signs the authorisation? Who sees the report first? Who pays for fixes to code the agency wrote? Who is named as the tester when the client’s customer asks?
This checklist puts those questions in order, from the statement of work through to retest. It suits referral, co-delivery and subcontract arrangements alike, though the answers will differ for each.
How to use it
Start at the SOW stage, not in the week before testing. The first two groups shape the commercial agreement and should be settled with the client before the project plan is fixed. The contract group is a list of questions, not answers. Agree the position with your legal adviser and make sure the client contract, the agency contract and the testing provider’s terms line up.
The remaining groups run alongside delivery. Pair them with the pentest readiness checklist, which covers inventory and test-account detail.
Notes
No testing starts from an enquiry or a quote. It starts only once a written scope is agreed and the system owner has signed an authorisation. Retest rounds, report identity and any shareable summary for a ZenoPentest engagement are agreed in the proposal, not assumed.
For the reasoning behind each group, including scheduling around a launch date and when a co-branded report suits the reviewer, read security testing in agency client projects. To discuss a specific client project, use the partner enquiry.
Statement of work
- Add testing to the SOW as its own line with scope, dates and a named commissioning party.Testing raised in launch week becomes a surprise cost and a threat to the date.
- Record whether the agency, the client or the client directly with the provider commissions the test.The commissioning party determines who contracts, who pays and who receives the full report.
- Reserve developer time for remediation between report and retest.Fixes are cheapest while the developers who wrote the code are still on the project.
- If the client declines testing, record that as a client decision in the SOW.A written decision protects both parties when security questions arise after launch.
- Ask the client whether their customer, auditor or investor has specific testing requirements.A reviewer's scope or provider requirements change what has to be tested and reported.
Authorisation
- Identify the system owner and have them sign the testing authorisation.The owner of the application and data must permit testing, and an agency's signature alone is not enough.
- Add the agency as a signatory if it hosts, deploys or administers the environment.The party with operational control is affected by testing and may need to consent to it.
- Check testing policies for every hosting, cloud, CDN and identity platform involved.Platforms may restrict test types or require notice, and their rules are separate from the client's permission.
- Confirm the authorisation names assets, window, methods, exclusions, provider and stop contact.A precise authorisation lets everyone check whether an activity was permitted.
Contracts to settle with your legal adviser
- Agree who bears the risk of service disruption during authorised testing.Testing carries a small risk to availability or data, and the contracts should say who carries it.
- Agree whether findings in agency-built code trigger warranty or defect obligations.Settling this before the report arrives stops findings from turning into disputes.
- Agree report confidentiality, ownership and whether the client may share it onward.The report describes how to attack the client's system and its distribution should be deliberate.
- Confirm the client contract permits bringing a third party in for testing.Some client contracts restrict subcontracting or require named approval.
- Check whether a data processing agreement is needed between any of the parties.Testers may encounter personal data in the test environment.
Environment, data and access
- Agree which environment is tested and record its differences from production.Drift between staging and production changes how the report should be read.
- Populate test tenants with synthetic data, never copied production personal data.Realistic synthetic data exposes object-reference flaws without putting real people's data at risk.
- Provision two accounts per important role and at least two tenants before the window opens.Horizontal and cross-tenant access cannot be tested without paired accounts.
- Send credentials through an agreed secure channel and plan their revocation.Credentials in project tools or email outlive the engagement.
- Freeze or tag the build being tested and pause deployments to in-scope features.A moving build makes findings hard to reproduce and fixes hard to verify.
During testing and reporting
- Name stop contacts at both the agency and the client.Someone with authority on each side must be reachable if testing has to pause.
- Agree who is told about a critical finding mid-test and who decides on a hotfix.Serious issues should reach the right people through an agreed route, not wait for the final report.
- Decide who receives the full report and who receives any shareable summary.The client's CTO, their customer's reviewer and their auditor need different documents.
- Hold a joint readout with the client and the developers.Walking through findings together keeps the focus on fixes rather than blame.
Fixes, retest and attribution
- Agree which findings the retest covers, how it is requested and what counts as new scope.Undefined retest terms leave fix status unclear for the client.
- Batch fixes so the tester can verify them together.One consolidated retest gives a clean updated status for the client's reviewer.
- Obtain the updated remediation status in writing after retest.Reviewers read verification evidence as closely as the original findings.
- Decide report identity before testing starts and make sure it states who performed the test.Reviewers who require independent testing need to see that the tester is not the build team.
- Revoke test accounts and confirm evidence retention and deletion once the retest is complete.Leftover access and evidence are avoidable exposure for the client.
Get a fixed quote for your release.
A short form about the product and the deadline. We reply with scoping questions, then a fixed written quote.