Success-Based Penetration Testing
Also known as No Hack, No Pay: an authorized, scoped penetration test where the testing fee becomes payable only if we demonstrate the security objective agreed in writing beforehand.
The idea
Buying a penetration test involves an uncomfortable asymmetry. You commit budget before anyone knows what will be found, and if the report comes back thin it is difficult to tell whether your product is genuinely resilient or whether the testing was shallow.
This arrangement moves that risk onto us. We agree a specific security objective with you in advance - something that would represent a real problem for your business if an attacker achieved it - and the testing fee becomes payable only if we demonstrate it. If we do not, you receive a written account of the work and owe no testing fee.
The arrangement only functions because the objective is defined precisely beforehand. That precision is the whole mechanism: it is what lets us take the risk, and it is what protects you from an argument about interpretation afterwards.
What this is not
It is not permission to do anything necessary to get paid. The scope, the permitted techniques, the exclusions, and the stop conditions are written down and signed before testing starts, exactly as in any other engagement we run. If a provider offers you outcome-based testing without those boundaries, the risk they are transferring is not commercial - it is legal, and it lands on you.
Nor is a negative result a certificate. If we do not achieve the objective, that tells you the specific objective was not achieved within a defined scope and timeframe by one team. It is useful, and it is not the same as being secure. We will not describe it as such.
How the engagement runs
Each step is documented, and nothing proceeds until the previous step is agreed in writing.
- 01
Eligibility review
We confirm the engagement can be defined precisely enough to work on this basis, and that you are entitled to authorize testing of every asset involved.
- 02
Objective definition
We agree a specific, testable security objective in writing - the outcome that would demonstrate a real risk to your business.
- 03
Success criteria
We define exactly what evidence would satisfy that objective, so neither side is interpreting the result afterwards.
- 04
Scope and exclusions
In-scope assets, out-of-scope assets, permitted techniques, testing window, and stop conditions are all recorded.
- 05
Authorization
You provide written authorization, and rules of engagement are signed by both parties before any testing begins.
- 06
Testing
We test within the approved scope, with an agreed contact route for questions and for immediate escalation.
- 07
Outcome and evidence
If the objective is met, you receive the full report with reproducible evidence and the agreed fee becomes payable. If it is not met, you receive a written account of what was attempted and no testing fee is due.
How success is defined
The objective is always specific to your product and written down before testing. These are illustrative examples of the form it takes.
- Demonstrating unauthorized access to another tenant’s data in a multi-tenant application.
- Demonstrating authenticated access to a defined administrative function without holding the required role.
- Demonstrating retrieval of a specific class of sensitive record from outside the authorized permission boundary.
- Demonstrating a path from a low-privilege application account to a defined cloud permission or resource.
Vague objectives are not accepted on either side. "Prove we can be hacked" is not a testable criterion, and an engagement cannot be run on a success basis without one.
Payment trigger
The agreed professional testing fee becomes payable when we deliver reproducible evidence that satisfies the success criteria recorded in the engagement documents, within the agreed scope and timeframe.
Evidence means a documented, reproducible demonstration: the steps taken, the conditions required, and the result observed, sufficient for your engineers to reproduce it independently. A theoretical argument that something should be possible does not trigger payment.
Eligibility, scope, success criteria, exclusions, fees, and payment terms are all agreed in writing before the engagement begins.
Excluded by default
These techniques are not used. Some can be considered only where a specialist process, legal review, insurance, and your explicit written approval are all in place - and never as part of a default engagement.
- Social engineering, phishing, pretexting, or any technique directed at your employees.
- Physical intrusion, access to premises, or tampering with hardware.
- Denial-of-service, load, stress, or volumetric testing.
- Destructive actions, data deletion, encryption of your data, or ransomware simulation.
- Establishing persistence, or retaining access beyond what evidencing a finding requires.
- Testing the production data of your customers where a representative environment can serve instead.
- Any asset outside the agreed scope, and any asset you cannot lawfully authorize us to test.
- Any technique your rules of engagement prohibit.
What we agree before testing begins
Rules of engagement are a document, not a formality. Both parties sign, and testing does not start until they are signed.
- Authorization
- Written authorization from a person entitled to grant it for every in-scope asset, obtained before any testing activity begins.
- Testing window
- Agreed start and end dates, and where relevant agreed hours, so your team knows when activity is expected and when it is not.
- Permitted techniques
- The techniques we may use are listed. Anything not listed is not permitted, rather than assumed to be allowed.
- Communication
- A named contact on each side and an agreed route for urgent matters, including out-of-hours where the window requires it.
- Critical findings
- A finding that presents an immediate and serious risk is reported to you promptly rather than held until the report.
- Stop conditions
- The circumstances in which testing pauses immediately - including instability, unintended impact, or your request - and how it resumes.
- Evidence handling
- How evidence is collected, stored, protected, and disposed of, and how any incidentally accessed data is handled.
- Confidentiality
- Findings remain confidential. We do not publish, disclose, or reference your findings without your written permission.
Common questions
What exactly does "No Hack, No Pay" mean?
It means the professional testing fee is contingent on outcome. If we demonstrate the security objective we agreed in writing before testing started, the agreed fee becomes payable. If we do not demonstrate it within the agreed scope and timeframe, no testing fee is due.
It does not mean unrestricted testing, and it does not mean we will do whatever it takes. The engagement is bounded by the same authorization, scope, and rules of engagement as any other assessment we run.
Does this mean you will use any technique necessary?
No, and any provider offering that should concern you. Permitted techniques are agreed in advance and written down. Social engineering, physical intrusion, denial-of-service, and destructive techniques are excluded by default, and anything not listed as permitted is not permitted.
A success-based fee changes who carries the commercial risk. It does not change the legal and ethical boundaries of authorized testing.
How is the objective agreed, and who decides whether it was met?
The objective and the evidence that would satisfy it are both written down before testing begins, in specific terms - which asset, which boundary, which class of data or function. That specificity is what makes the arrangement workable.
Because the criteria are defined in advance and every finding is evidenced with reproduction steps, the outcome is a matter of comparing evidence against the agreed criteria rather than a judgement call after the fact.
What do we receive if you do not meet the objective?
You receive a written account of the work: what was in scope, what was attempted, the areas examined, and any lower-severity findings or observations identified along the way. No testing fee is due.
We will not claim your product is secure on that basis. A negative result within a defined scope and timeframe means the specific objective was not achieved under those conditions, which is genuinely useful information but not a proof of security.
Which engagements are suitable for this arrangement?
Engagements where the objective can be stated precisely and where the scope is well defined - typically a specific application, a specific boundary, or a specific class of data. Multi-tenant SaaS products often fit well, because tenant isolation is a clear, testable boundary.
It is less suitable for broad discovery work, where the value lies in coverage across a wide surface rather than in achieving one defined outcome. In those cases a conventional scoped assessment gives you better value, and we will say so.
Is there any cost before testing begins?
Eligibility and objective definition may involve preparatory work, and whether that is chargeable is stated in the proposal before you commit to anything. There are no undisclosed costs.
Eligibility, scope, success criteria, exclusions, and all commercial terms are agreed in writing before the engagement starts.
How does this differ from a bug bounty?
A bug bounty is an open, ongoing invitation to many researchers, paid per accepted finding, with variable coverage and no guarantee that anyone examines a given area. This is a defined engagement with one accountable provider, an agreed scope, an agreed timeframe, and a single agreed objective.
The deliverable is also different: a bug bounty produces individual reports of varying quality, whereas this produces a structured assessment report with a debrief and a retest.
Important
This page describes a commercial arrangement in general terms. It is not an offer, and it does not create any obligation on either party. Eligibility, scope, success criteria, exclusions, fees, liability, and all other terms are governed solely by the written engagement documents signed by both parties.
Security testing carries inherent risk. We do not guarantee that testing will identify every vulnerability, and no assessment - successful or otherwise - should be read as a warranty that a system is secure. See our Terms of Service and Authorized Testing Policy.
Find out whether your engagement qualifies
Tell us about your product and the boundary that matters most. We will tell you honestly whether a success-based engagement fits, or whether a conventional scoped assessment would serve you better.