A client launch is coming
The client wants the application and APIs tested before go-live, while your developers are still on the project to fix what is found.
Security testing that fits your client delivery
Add a pentest, integration review or security engineering workstream to a client project. Who contracts, authorises, fixes and requests the retest is written down before testing starts.
When it comes up
The client received a security questionnaire
Your client's customer asks for a recent penetration test of the product you built. The client turns to you because you know the system and its deployment.
An enterprise customer is reviewing your client
A reviewer wants evidence of testing, a readable summary and proof that serious findings were fixed. Their requirements decide what the report contains and who should have tested.
A new integration or SSO
SAML or OIDC sign-on, a payment provider, a CRM sync or a partner API adds tokens, service accounts and webhooks that change who can reach which data.
Reassurance after an incident
After an exposed endpoint or a suspicious account, the client wants an outside party to test the affected area once your fixes are in. This is a scoped assessment, not incident response.
What we can do for you
Penetration testing
Application and API penetration test
Manual testing of the agreed application and APIs across roles, tenants and workflows, with request and response evidence your developers can reproduce.
Security engineeringSecurity engineering for the fix
When a finding needs design work, a separately scoped engagement reviews the control, proposes the correction and defines the acceptance test your team builds against.
Integration security reviewsIntegration and SSO review
The identity flow, service-account permissions, webhook handling and data exchanged with the third party, then authorised testing of the deployed connection.
AI application securityAI feature assessment
Assistants, retrieval over client documents and agents that call tools, assessed for prompt injection, cross-user data exposure and unintended actions, with OWASP LLM Top 10 as the reference.
How a project runs
A synthetic walkthrough. The companies and systems are fictional.
- 01
First call about one project
Synthetic example. Fernhill Digital (fictional agency) is building a booking portal for Larkspur Clinics (fictional client) at portal.example.com, with an API at api.example.com. The call covers what is built, the roles, the launch date and who fixes findings.
- 02
Scope and responsibility split
The proposal covers patient, staff and administrator roles, two clinic tenants, the booking workflow and the payment webhook. It names the assessment lead, sets out the responsibility table and states how the report will be attributed.
- 03
Authorisation and access
Larkspur, as system owner, signs the testing authorisation. Fernhill hosts staging, so it confirms the hosting provider's testing terms, creates accounts for each role in both tenants and seeds synthetic bookings.
- 04
Testing and live issues
The tester works through the agreed roles and workflows. A serious finding, here staff in one clinic reading another clinic's bookings by changing an ID, goes to the named contacts during testing.
- 05
Report and readout
The report goes to the people named in the proposal. A readout takes Fernhill's developers through each finding and its correction. Larkspur receives the executive summary for its board and its reviewing customer.
- 06
Fixes and agreed retest
Fernhill fixes in its next sprint and requests the retest once fixes reach staging. The tester re-runs each original test case and records a result per finding in an updated summary.
Who does what
Agreed in writing before any testing starts.
| Task | Agency | Client | ZenoPentest |
|---|---|---|---|
| Client contract and commercial relationship | Owns | Involved | Involved |
| Scope definition and quote | Involved | Involved | Owns |
| Signed testing authorisation from the system owner | Involved | Owns | Involved |
| Environments, test accounts and hosting provider permissions | Owns | Involved | Involved |
| Testing and evidence capture | Involved | Not involved | Owns |
| Report, readout and attribution | Involved | Involved | Owns |
| Report distribution to the client's customers and auditors | Involved | Owns | Involved |
| Fixing findings | Owns | Involved | Involved |
| Requesting the retest | Owns | Involved | Not involved |
| Answering the client's reviewer questions about the testing | Involved | Involved | Owns |
Owns owns Involved involved
The detail
A project, not a reseller programme
Most partner programmes are built for managed service providers selling recurring licences. An agency’s need is different. It arrives with a client project: a launch date, a questionnaire, an enterprise reviewer or a new integration. ZenoPentest starts there. Bring one real project to the first conversation, not a partnership application.
If several projects follow, the arrangement can be formalised. The partnership models page explains the options.
Who does what is written down first
The table on this page is the default split for a co-delivery project, where the agency holds the client contract. Under a referral, the client contracts with ZenoPentest directly and the first row moves. Whichever model you choose, the proposal records:
- who scopes and quotes, and who approves the fee
- who signs the testing authorisation, which is always the system owner
- who holds the test credentials and how they are handed over and revoked
- who talks to the client during testing
- who receives the report and who may pass it on
- who fixes, who asks for the retest and who answers the client’s auditor
Agencies carry the reputational risk if this goes wrong. Writing it down costs little and prevents the common failures: a test with no signed authorisation, credentials left active after the project, or a client hearing about a serious finding second-hand.
Who tested is never hidden
An agency-branded report can look tidy. It can also cause trouble. When the agency that built the system presents a test under its own name, a client’s auditor or enterprise reviewer may read it as the builder checking its own work. Some reviewers ask for the testing organisation to be named and to be independent of the developers.
Ask the reviewer early. If they need a named, independent tester, the report says so. If they only need evidence that testing happened and findings were fixed, there is more flexibility. Either way, the report states accurately who tested and who reviewed. Attribution formats are agreed per engagement and remain to be confirmed.
Retests on your schedule
In agency work the agency fixes the findings. The retest is requested by your team once fixes are deployed, so it follows your sprint plan rather than a date fixed at kick-off. Each original finding is re-tested with the same method and recorded as fixed, partly fixed or still open, with the evidence for that result. The updated executive summary gives your client something accurate to forward to their reviewer. Rounds and timing are set in the proposal, never left as an open-ended promise.
See the deliverable before you sell it
The sample report is public, with no form to fill in. It shows the scope table, findings with request and response evidence, remediation guidance and retest records, all synthetic. Share it with your client to agree expectations before the quote, so nobody is surprised by the format when the real report arrives.
When you host the application
Many agencies also host or deploy what they build. That adds a step: the hosting provider’s terms on security testing, and any third-party services in scope, such as payment or email providers. ZenoPentest checks these with you before testing, alongside the client’s signed authorisation. The agency client handoff checklist and the guide to security testing in agency client projects cover the preparation in detail.
Being confirmed
- Report attribution and any co-branded format
- Retest rounds and period
- Commercial terms per partner model
- Future contact with an agency's client
- Insurance and liability terms
- Delivery team and assessment lead
Read a complete sample report
Ungated. A fictional company, a real structure, and a note on why each section exists.
ZENOPENTEST · SECURITY ASSESSMENTNorthwind Billing
Northwind Billing
Web application & API
- Report
- v1.1 · includes retest
- Roles tested
- 4
- Assets
- 3
SUMMARY
| Severity | Findings |
|---|---|
| Critical | 0 |
| High | 2 |
| Medium | 2 |
| Low | 1 |
| Info | 1 |
| Verified fixed | 4 / 6 |
FINDING ZP-SYN-0042
Invoice read does not check tenant ownership
- 01 · CoverStates the system, version, roles and assets up front so a reviewer knows exactly what the report covers.
- 02 · SummaryWritten for your client’s or customer’s reviewer: what was tested, what was found and what is now fixed, in one minute.
- 03 · Scope recordShows every asset against every role, plus what was out of scope, so coverage claims can be checked.
- 04 · MethodNames the approach, standards and environment, so the reader can judge the depth of testing.
Useful before you start
- How to scope a web application and API penetration testWhat to inventory before you ask for a quote, what actually drives testing effort, how to choose an environment and test accounts, and what a written scope record should say before anyone signs an authorisation.
- Agency client handoff checklistWhat 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.
- Security testing in agency client projectsWhen to propose penetration testing in a statement of work, who signs the testing authorisation, which contract questions to settle, how to handle environments and data, and how to schedule testing, reporting and retest around a client launch.
Questions buyers ask
Can you white-label the report?
Report attribution is agreed for each engagement before testing starts. We will not hide who performed the testing when an auditor, the client or the client's customer needs to know. Whether a co-branded or agency-branded format is available is still to be confirmed, so raise it in the proposal rather than assume it.
Who talks to our client?
You decide, and the proposal records it. Serious findings go to the named contacts without waiting for the report.
What if the client finds out mid-project that they need a pentest?
Send the outline, deadline and any reviewer requirements. We scope what can be tested properly in the time available and say plainly what would have to wait.
How do retests fit our release schedule?
Your team requests the retest once fixes are deployed, so it follows your sprint rather than a fixed date. The number of rounds and the period they cover are set in the proposal.
Will you approach our client for other work afterwards?
Future contact with your client is agreed in writing before the engagement. No standard non-solicitation clause has been finalised, so raise it in the first call and it goes into the agreement.
Can our agency authorise testing of the client's system?
Usually not on its own. The system owner, normally your client, signs. If you host the application, your hosting provider's terms may also apply. Both are confirmed before testing.
Can our developers keep shipping during the test?
Tell us what will change. Deploys to the tested environment can invalidate evidence, so we agree a freeze on in-scope parts or record the build each finding was observed on.
Do you also fix the findings?
By default your team fixes, because you own the code. Where a fix needs design work, security engineering can be scoped separately with its own acceptance tests.
What do you need for a quote?
The application outline, roles and tenants, environment, deadline, reviewer requirements and who will fix. Please do not send credentials, client data or previous reports in an enquiry.
Is the sample report from a real project?
No. It is a labelled synthetic specimen using fictional companies and example.com domains.
Start with one project.
Tell us the system, the deadline and who needs the report. You get scoping questions, then a fixed quote.