Security testing in agency client projects

An agency’s security test is rarely about the agency. It is about a client’s launch, a client’s enterprise customer or a client’s auditor, delivered by the agency’s team on the agency’s timeline. When it goes well, the client gets a report their reviewers accept and fixes made while the developers who wrote the code are still on the project. When it goes badly, testing is squeezed into launch week, findings land after the team has moved on, and nobody is sure who was allowed to authorise the test.

This guide is for agency founders, delivery directors and technical leads who want to bring penetration testing into client projects deliberately. It covers commercial and operational questions, not legal advice. Where contracts or liability come up, agree the position with your legal adviser.

When to propose testing

The best time to raise security testing is when the statement of work is being written. At that point it is a line item with a date. Raised later, it becomes a surprise cost and a threat to the launch.

Signals that a project should include testing:

• the application handles personal data, payments, health information or credentials;
• there are multiple user roles, especially admin or support roles with broad access;
• the product is multi-tenant, or one client’s users must never see another’s data;
• the client sells to enterprises, regulated sectors or the public sector, and will face security questionnaires;
• the client is preparing for SOC 2 or ISO 27001 and needs testing evidence for their auditor;
• the build introduces SSO, OAuth, payment, webhook or AI integrations;
• the client’s own customer has asked for a pentest as a condition of purchase.

If the client says they do not need testing, record that in the SOW as a client decision. It protects both parties when the question comes up later.

What to put in the SOW

SOW element	What to say
Testing scope	The applications, APIs, roles and environments to be tested. Refine later, but name them.
Who commissions the test	Agency, client, or the client directly with the testing provider. This determines who contracts and who receives the report.
Testing window	A date range tied to a build milestone, with readiness conditions.
Fix allowance	Developer time reserved for remediation after the report. Without it, fixes compete with launch work.
Retest	Whether a retest is included and when, as agreed with the testing provider.
Report recipient	Who receives the full report and who receives any shareable summary.
Client responsibilities	Signing authorisation, providing third-party permissions, nominating a stop contact.

Three ways to bring a tester in

How you structure the relationship affects who signs what, who talks to whom and whose name is on the report.

	Referral	Co-delivery	Subcontract
Who contracts with the client for testing	Testing provider	Agency, with the provider named	Agency
Who the client talks to during testing	Provider and agency	Agency, provider joins where needed	Agency
Report identity	Provider’s report to the client	Agreed in advance per engagement (format to confirm)	Agreed in advance; delivery must be disclosed truthfully
Who fixes findings	Agency, under its client contract	Agency	Agency
Fits when	Client wants a direct relationship with the tester	Agency wants to own delivery while being clear about who tests	Agency owns the full commercial relationship

Which arrangement fits is agreed per engagement. Subcontract arrangements are discussed case by case, with the delivery chain stated truthfully in the report. Terms for any arrangement are agreed in writing per engagement.

Who signs authorisation

Penetration testing without permission from the system owner can be unlawful. Every engagement needs written, signed authorisation before any testing starts. In agency work the question is whose signature.

The system owner signs. Usually that is the client: they own the application, the data and the business risk. An agency’s signature alone is not enough if the client owns the system.

The agency may also need to sign if it hosts the application, manages the infrastructure, or holds administrative control of the environment being tested.

Third parties may have their own rules. Cloud providers, managed hosting platforms, CDNs, payment providers and identity providers often publish policies on security testing of resources on their platforms. Some permit testing of your own resources within limits. Some exclude certain test types. Some require notice. Check each provider’s current policy, record what applies in the scope, and leave out anything the platform does not permit.

The authorisation should name the assets, the testing window, permitted and excluded methods, the testing provider, the stop contact and the signatory’s authority to grant permission. See scoping and authorisation for how ZenoPentest records this.

Contract and liability questions to settle

These need answers before testing starts. This guide cannot give them for you. Agree the position with your legal adviser, and make sure the client’s contract, the agency’s contract and the testing provider’s terms line up.

• Liability for service disruption. Testing carries a small risk of affecting availability or data, especially in production. Who bears that risk, and is it capped?
• Liability for findings. If testing finds a serious issue in code the agency wrote, does that trigger warranty or defect obligations under the client contract?
• Confidentiality. The report describes how to attack the client’s system. Who may see it, and under what restrictions?
• Report ownership and onward sharing. Can the client share the report with their customers, auditors or investors? In what form?
• Data protection. Testers may see personal data in the test environment. Is a data processing agreement needed between any of the parties?
• Insurance. Does each party’s cover respond to incidents arising from authorised testing? Ask your broker rather than assuming.
• Subcontracting permissions. Does the client contract allow the agency to bring in a third party for testing?
• Fix obligations. Is remediation of findings included in the agency’s fee, a change request, or a separate engagement?

Test environments and data

Which environment

Most agency projects test a staging or UAT environment that mirrors production. That keeps real customers out of the way and lets the tester try destructive or high-volume actions. The trade-off is drift. If staging uses different configuration, integrations or feature flags, record the differences in the scope so the report can be read correctly.

If production must be tested (for example, because it is already live), agree off-limits actions, testing hours, rate limits and a stop contact who can be reached throughout.

Test data

• Use synthetic data. Do not copy production personal data into a test environment for the tester’s benefit.
• Populate each test tenant with realistic records: orders, invoices, files, messages. An empty system hides object-reference bugs.
• Create at least two accounts per important role and at least two tenants, so the tester can attempt horizontal and cross-tenant access.
• Freeze or tag the build for the testing window. Deploying mid-test makes findings hard to reproduce.

Credentials and access

Provision test accounts before the window opens. Send credentials through a separately agreed secure channel, never through an enquiry form, project management comment or email thread. Revoke them when testing and retest are complete.

Scheduling around the launch

A frequent agency mistake is testing too late. If the report arrives two days before launch, there is no time to fix anything, and the client launches with known open findings or delays the launch.

A workable sequence:

1. Feature freeze for in-scope functionality. The build being tested should be the build being launched, or close to it.
2. Testing window. Duration depends on scope and is agreed in the proposal.
3. Report and readout. Walk the client and the developers through findings together.
4. Fix window. Reserved developer time, ideally the same people who built the features.
5. Retest. The tester verifies fixes for the findings agreed in the proposal.
6. Updated status. The report or summary reflects which findings are fixed and verified.
7. Launch.

Work backwards from the launch date. If the gap between feature freeze and launch cannot hold all of these steps, either move testing earlier with a narrower scope or agree with the client that some findings will be fixed after launch, and record that decision.

Critical findings during testing

Agree in advance how a critical finding is reported while testing is still running. Who is told, through which channel, and who decides whether to pause testing or hotfix? In agency work that usually means both the agency’s technical lead and the client’s nominated contact.

Sharing the report with the client

How the report reaches the client depends on the arrangement you chose. Whatever the route:

• Agree the audience in advance. The client’s CTO, their customer’s reviewer and their auditor need different documents.
• Hold a joint readout. Walking through findings with the client and the developers together avoids findings being read as blame, and lets the tester explain impact in context.
• Separate the full report from shareable summaries. The full report contains reproduction steps. Most clients share a summary with their customers and keep the full report under NDA.
• Pair findings with a plan. Arriving with the report and a remediation plan, owners and dates turns a list of problems into a project the client can approve.

Retest timing

Retest is where agency projects get the most value, because the developers who wrote the code are still on the project.

• Schedule the retest in the project plan, not as an afterthought.
• Batch fixes so the tester verifies them together rather than one at a time.
• Agree in the proposal which findings a retest covers, how a retest is requested and what counts as new scope. A fix that introduces a new feature is not a retest.
• Ask for the updated remediation status in writing, so the client has evidence of verification for their reviewer.

Retest rounds, windows and scheduling rules for any ZenoPentest engagement are agreed in the proposal rather than published as a standard term.

Attribution and white-label honesty

Agencies often want security work to sit under their own brand. That is understandable, and sometimes appropriate. But who actually performed the test matters to the people reading the report.

• An enterprise reviewer asking for “independent third-party testing” wants to know the tester is not the team that built the product. If the agency built it, an agency-branded report with no named tester may not meet that requirement.
• An auditor may ask who performed the testing and how they relate to the system owner.
• A report that hides the testing organisation can create problems for the client later, even if nobody intended to mislead.

A practical rule: the report identity should match the truth about delivery, and it should suit the reviewer who will read it. Co-branded reports that name both the agency and the testing provider often meet both needs. Whatever the arrangement, decide report identity before testing starts and say who did the testing.

Next steps

• Use the agency client handoff checklist to confirm authorisation, environments, contacts and report routing before the window opens.
• Read the scoping guide to build the inventory for a client application.
• See how ZenoPentest handles scoping and authorisation and reporting and retest, and how partner arrangements work on the partners page.
• If you have a client project in mind, discuss it through the partner enquiry. No testing starts from an enquiry: a written scope and signed authorisation from the system owner come first.