A penetration testing contract should put five things in writing: who authorised the test and for which systems, how serious findings are escalated during testing, what happens to your data afterwards, who owns and may see the report, and where liability sits if something breaks. Check all five before you sign, not after the report arrives.
Most penetration testing contracts are the provider’s standard terms with a scope document stapled to the back. That’s normal, and it isn’t a problem in itself. Standard terms are written to protect the provider, which is what standard terms are for. Your job is to make sure the handful of lines that protect you are in there too.
One thing first. I’m not a lawyer, and neither is this post. It tells you which terms to look for and what to ask. Your lawyer decides whether the answer is good enough.
This is the last step in buying a test. If you’re still working out what it should cost, start with our guide to penetration testing cost. If you’re still choosing who to buy it from, the 15 questions to ask a penetration testing company come before this.
Penetration Testing Contract Terms at a Glance
Ten terms, ordered from the ones every contract needs to the ones most buyers only think about afterwards.
| # | Contract term | What to get in writing | Backed by |
|---|---|---|---|
| 1 | Authorisation and scope | What is tested, how, and who signed off for your organisation | CREST guide |
| 2 | Third-party systems | Who gets permission from your cloud, hosting or managed service provider | CREST guide |
| 3 | Testing windows and contacts | Dates, times, locations, named contacts on both sides | CREST guide · NCSC |
| 4 | Critical-finding escalation | What counts as critical, who is called, and how fast | NCSC · CREST guide · CREST Code of Conduct |
| 5 | Data retention and destruction | What evidence is kept, where, for how long, and how it’s deleted | CREST Code of Conduct · ICO |
| 6 | Confidentiality | Who else may see anything about your test | CREST Code of Conduct |
| 7 | Subcontractors and named testers | Who is testing, and whether any of it is subcontracted | CREST Code of Conduct · ICO |
| 8 | Liability and insurance | The cover held, the liability cap, and what happens if a live system fails | CREST Code of Conduct · CREST guide |
| 9 | Report ownership and use | Who owns the report and who you may share it with | |
| 10 | Complaints route | How to complain, and to whom beyond the provider | CREST Code of Conduct |
Basic Penetration Testing Contract Terms Every Agreement Needs
These four terms decide whether the test can legally and practically happen. Leave any of them vague and the first morning of testing is spent arguing about it.
1. Put the Authorisation and Scope in Writing
The contract should record exactly what is being tested, how, and who in your organisation authorised it. Without that, a penetration test is just someone attacking your systems.
CREST’s guide for buyers is plain about it: “The penetration tester must be authorised to perform any tests on your systems, which can often be achieved by formally defining what is to be tested and how it will be tested.” It adds that “The test team will also require a disclaimer stating it is legally authorised to carry out specified activity on your property and systems.” (CREST, (opens in a new tab)A Guide to Penetration Testing (opens in a new tab), December 2022 (opens in a new tab).) In the UK, unauthorised access to computer material is an offence under the Computer Misuse Act 1990 (opens in a new tab).
The question to ask: does the person signing the authorisation actually have authority over every system in scope? An IT manager can authorise the servers they run. They usually can’t authorise the payment platform another division owns.
2. Agree Who Gets Permission From Your Third Parties
If anything in scope is hosted, managed or run by someone else, the contract should say who asks that third party for permission, and what happens if they refuse.
Cloud platforms, hosting firms and managed service providers often have their own rules about security testing. CREST’s guide advises that if you can’t test an important environment controlled by a third party, you should seek assurances about it instead. Either way, it needs deciding before the test starts, not on the day. Our guide to preparing for a penetration test covers the practical side.
The question to ask: is getting third-party permission our job or yours, and whose problem is it if permission hasn’t arrived by the start date?
3. Fix the Testing Windows and the Named Contacts
The contract or its scope statement should name the dates, times and locations of testing, and a contact on each side who can be reached throughout.
Both CREST and the NCSC treat this as basic. CREST’s list of what a scope statement should include has “Defined testing times and locations” and “A problem escalation process” as separate items, and its guide recommends you “Nominate a senior manager (who can be easily contacted during the testing process) to be accountable for managing test delivery”. The NCSC adds that “During the test phase, you should ensure that a technical point of contact is available at all times.” (NCSC, (opens in a new tab)Penetration testing (opens in a new tab), last reviewed 10 January 2022.)
The question to ask: if your tester needs something at 7pm on day two, whose phone rings?
4. Define How Critical Findings Are Escalated During the Test
The contract should say what happens when the tester finds something serious mid-test: what counts as serious, who they call, and how quickly. Waiting for the final report is not an answer.
The NCSC says a technical point of contact matters because “This allows the test team to raise any critical issues found during testing, and resolve problems which are blocking their testing.” CREST’s buyer’s guide describes on-going communication during tests as “regular updates, which are supported by alerts if a serious vulnerability has been discovered.” And CREST’s Code of Conduct (opens in a new tab) (v26, 11 September 2024) requires member companies to “ensure that any serious issues identified that require more formal reporting are highlighted to the client.”
The question to ask: if you find a way into our customer database on day one, who do you call, and within how many hours?
Advanced Contract Terms for Data, People and Third Parties
The next three terms are about what the tester sees, who else sees it, and who the tester actually is. They’re the ones standard terms tend to cover in a single vague sentence.
5. Say What Happens to Your Data After the Test
The contract should state what evidence the provider keeps, where, for how long, and how it’s deleted or returned when the engagement ends. “Handled securely” is not a retention period.
A tester may see customer records, hold passwords to your systems and keep screenshots as evidence for the report. CREST’s Code of Conduct requires member companies to “safeguard the confidentiality of all information concerning their Clients”, but it contains no clause on how long test data is kept or when it’s destroyed. That has to come from your contract.
Where the testers will handle personal data, the ICO’s guidance on controller and processor contracts is a useful benchmark for the questions to ask. Among the terms it lists, a processor must, “at the controller’s choice, delete or return to the controller all the personal data it has been processing for it” (ICO, (opens in a new tab)What needs to be included in the contract? (opens in a new tab), last updated 8 September 2026).
The question to ask: how many days after the final report is our data deleted, and will you confirm it in writing?
6. Check Who Else May See Anything About Your Test
The contract should say that nothing about your test, including the fact that it happened, is shared without your agreement.
CREST’s Code of Conduct already sets the bar for member companies: they “must not disclose to any third party, formally or informally, any information about their Clients or results of any assignments without the specific approval of the Client and/or unless obliged to do so by law or a governing Regulator or a Scheme owner.” A good contract says the same thing in its own words, whether or not the provider is CREST-accredited. If your organisation insists on its own non-disclosure agreement, sign it before scoping, not after.
The question to ask: will you use our name, or anything from our test, in case studies or marketing? The answer should be “not without asking”.
7. Name the Testers and Rule on Subcontracting
The contract should say whether any of the testing is subcontracted, and to whom. The names and qualifications of the testers can sit in the proposal, but they should be there.
CREST’s Code requires member companies to provide details of the qualifications held by everyone scoping, conducting, supporting or signing off a CREST assignment. It also requires that if a provider delivers work its CREST accreditation doesn’t cover, “the Report provided to the Client clearly states that the Services are not covered by the Member Company’s CREST Accreditation.” Where personal data is involved, the ICO’s benchmark is that “the processor should not engage another processor (a sub-processor) without the controller’s prior specific or general written authorisation”. Our provider checklist covers what to ask about the testers themselves.
The question to ask: if a named tester is off sick, who replaces them, and do we get a say?
Expert Contract Terms Most Buyers Only Think About Afterwards
The last three are the terms that nobody reads until something goes wrong. That is exactly when you need them to be clear.
8. Find Out Where Liability Sits If a Live System Fails
The contract should state the provider’s liability cap, the insurance behind it, and what each side is responsible for if a live system goes down during testing.
Testing live systems carries a small risk that something falls over. CREST’s buyer’s guide tells you to “Take back-ups of critical systems and files before testing”, which is sensible, and also a hint about whose problem a failure is likely to be. CREST’s Code of Conduct lists “Carrying appropriate insurances for the work being undertaken” among the good practices it expects of companies. Neither tells you what’s appropriate for your test. Your contract should.
It’s rather like hiring a removals firm. You agree what’s insured before the piano goes down the stairs, not when it’s halfway down.
The question to ask: what is your liability cap for this engagement, what are the exclusions, and what insurance stands behind it? Then give the answer to your lawyer.
9. Agree Who Owns the Report and Who You Can Share it With
The contract should say that the report is yours to use, and that you can share it with the people who will ask for it: your auditor, your QSA, a customer’s security team or an insurer.
This sounds like a formality until a customer asks for evidence of testing and you discover the terms say the report is confidential to your organisation only. Some providers offer a separate letter or summary for exactly this. Ask.
The question to ask: can we share the full report with a third party, and if not, what can we share?
10. Check the Complaints Route Is Written In
The contract should tell you how to complain, and to whom beyond the provider if the complaint isn’t resolved.
For CREST-accredited work this is a requirement, not a courtesy. CREST’s Code of Conduct says each member company “will provide CREST contact details in the tender and/or contractual documentation for a CREST Assignment and include reference to the CREST Complaints Handling Process.” If you’re buying CREST-accredited testing and that reference isn’t there, ask why.
The question to ask: is this a CREST assignment, and where is the complaints route written down?
Penetration Testing Contract Mistakes to Avoid
Three mistakes account for most contract regret, and none of them needs a lawyer to spot.
| Mistake | Why it hurts | The fix |
|---|---|---|
| Signing the standard terms unread because the scope looked right | The scope says what’s tested; the terms say what happens when it goes wrong | Read tips 4, 5, 8 and 9 against the terms, not the scope |
| Letting someone without authority sign the authorisation | The test stalls, or goes ahead on systems nobody cleared | Match every in-scope system to an owner who signs (tip 1) |
| Agreeing dates with no rescheduling or cancellation terms | A missed third-party permission or a change freeze turns into a cancellation fee | Ask what happens if either side has to move the dates |
I once spent an evening reading the terms and conditions for a new fridge. I have, on occasion, seen organisations spend less time on the contract for someone who’s about to try to break into their network.
Penetration Testing Contract FAQs
Who Should Sign the Authorisation for a Penetration Test?
Someone with authority over every system in scope. CREST’s guide says the tester “must be authorised to perform any tests on your systems”. If systems belong to different owners, get each one to sign.
Is a Statement of Work the Same as a Penetration Testing Contract?
Not usually. The statement of work, or scope, says what will be tested and how. The contract says what happens around it: liability, data, confidentiality, report ownership and complaints. You need both, and they should agree with each other.
Should a Penetration Testing Provider Sign Our NDA?
If you require one, yes, and before scoping, because scoping is where you share architecture and asset details. CREST member companies are already bound by confidentiality under CREST’s Code of Conduct, but your NDA sets the terms you need.
What to Send Your Lawyer Before You Sign a Penetration Testing Contract
Send the provider’s terms and the scope together, with the ten questions above written in the margin. Your lawyer will tell you whether the answers are good enough. The questions tell them where to look.
If you’d like a second pair of eyes on a proposal or a set of terms before it goes to your lawyer, do get in touch. We’ll tell you what we’d ask, even if you end up signing with someone else.
A good penetration testing contract isn’t the one with the most clauses. It’s the one nobody needs to open after the test.