Penetration testing scope of work: what to define
Updated 2026-09-24
A penetration testing scope of work names the exact assets in and out of scope, the rules of engagement (dates, hours, source addresses, allowed techniques, contacts), the method the tester follows, what the report must contain and how retesting works. Write it before you ask for prices, because two quotes against a vague scope cannot be compared.
What to check
- List every asset in scope by URL, IP range, application build or API specification, and list what is explicitly out of scope.
- State the test type: black box, grey box with test accounts, or white box with source code access.
- Agree rules of engagement in writing: test window, source IP addresses, forbidden techniques, and an emergency stop contact on both sides.
- Name the methodology the tester follows, such as the OWASP Web Security Testing Guide or NIST SP 800-115.
- Define the report: severity scale, reproduction steps, evidence, and a summary your leadership can read.
- Agree how many retests are included, within what period after the report, and at what price.
- Check the named testers' experience and whether any part of the work is subcontracted.
Ask the vendor
- Which methodology will you follow for this test, and which of its test cases do you expect to be out of reach given our scope?
- Who, by name, will perform the test, and what similar applications have they tested?
- Which parts of the work are automated scanning and which are manual testing, and how much time goes to each?
- What will you do if you find a critical issue during the test: how fast do you tell us and through which channel?
- How do you store and destroy our data, credentials and findings after the engagement?
- Is a retest of fixed findings included, and what is the time limit for asking for it?
Why the scope comes first
A security testing quote is an estimate of effort against a scope. If you send "please quote for a pen test of our web app", each bidder guesses a different scope, and you end up comparing a two-day scan with a two-week manual test. Write the scope first, send it to every bidder, and ask them to price against it.
NIST SP 800-115 treats planning as its own phase of a security assessment, before any testing starts. The OWASP Web Security Testing Guide gives a catalogue of test areas for web applications that you can use to say what you expect to be covered.
Assets in and out of scope
Be concrete. A useful scope table looks like this:
| Asset | In scope | Details |
|---|---|---|
| Customer web app | Yes | app.example.com, staging build, two test roles |
| Public API | Yes | OpenAPI spec attached, test tenant provided |
| Admin console | Yes | Grey box, one admin test account |
| Marketing site | No | Hosted by a third party |
| Payment provider pages | No | Owned by the provider |
| Office network | No | Separate engagement |
List environments, roles, and any third-party services the application calls. Anything you do not list will be read as out of scope by some bidders and in scope by others.
Test type and access
State which view the tester gets:
- Black box. No credentials or documentation. Shows what an outside attacker sees, but spends time on discovery.
- Grey box. Test accounts for each role and API documentation. Usually a better use of paid time for an application test.
- White box. Source code and architecture access as well. Useful for complex authorisation logic.
Say which one you want, or ask bidders to propose one and justify it.
Rules of engagement
Write these down and have both sides sign them before testing starts:
- Test window: dates, hours and time zone.
- Source IP addresses the tester will use, so your monitoring team can tell the test from a real attack.
- Allowed and forbidden techniques, for example no denial of service, no social engineering, no testing of production data changes.
- Emergency contacts on both sides and a stop procedure.
- How credentials are provided and revoked.
- What happens if the tester finds a critical issue or evidence of a past compromise: who is told, how fast, and whether testing pauses.
Methodology
Ask the bidder to name its method and map its planned work to it. For a web application, the OWASP Web Security Testing Guide is a common reference; for broader technical assessments, NIST SP 800-115. A bidder that cannot say which method it follows, or only lists tool names, is a red flag worth raising.
Also ask how the time splits between automated scanning and manual testing. The manual part is where logic flaws, broken access control and chained issues are found.
The report
Define what you will receive:
- An executive summary a non-specialist can read.
- Each finding with severity, affected asset, reproduction steps, evidence and remediation advice.
- The severity scale and how it was applied.
- A list of what was tested and what could not be tested, and why.
- Tester names and test dates.
Ask for a redacted sample report from a past engagement during selection. The sample report guide explains what to look for.
Retest and follow-up terms
Retesting is where quotes differ most. Agree in the contract:
- How many retest rounds are included.
- The window after the report in which you can request a retest.
- Whether the retest produces an updated report or a letter.
- The day rate for extra retests.
Contract points
Security testers get privileged access and handle sensitive findings. Add to the contract:
- Confidentiality of findings and deletion of your data, credentials and evidence after an agreed period.
- Named testers and approval before any substitution.
- No subcontracting without written approval.
- Written authorisation from you to test the listed assets, which protects both sides.
The contract clauses tool includes confidentiality, subcontracting and key personnel clauses you can adapt. Use the RFP generator to set security testing as a separate lot with its own scope table, and read how to verify ISO 27001 and SOC 2 for checking the tester's own security posture.
The selection path shows how a security lot fits into the wider selection timeline.
Tools for this
Questions buyers ask
- Is a vulnerability scan the same as a penetration test?
- No. A scan runs automated checks for known issues. A penetration test adds manual work to find and exploit weaknesses, including logic flaws a scanner cannot see. Ask each bidder to state how its time splits between the two.
- Can my general QA vendor do security testing?
- Some can run basic checks. For a penetration test, ask for named testers with security testing experience, a stated method and a sample report. If the QA vendor subcontracts it, you need to know to whom.
- Do I need permission from my hosting provider?
- Check your hosting and cloud providers' terms before testing, and include third-party services in the out-of-scope list unless their owner has agreed in writing.