The quality of a penetration test is largely decided before the tester opens a laptop. A vague scope, test accounts that arrive on day three, or a fragile system nobody mentioned will each surface later, either as a limitation in the report or as an outage. This note lists what to settle before work starts.
The UK NCSC describes penetration testing as a way to gain assurance in a system by attempting to breach it with the techniques an adversary might use. Its guidance is equally clear about the limits: the test validates your vulnerability management process, and does not replace it.
Start with the decision the test will inform
Write down, in a sentence or two, what will change depending on the result. A test commissioned to satisfy a customer contract needs a defensible methodology and a report in the expected form. A test meant to establish whether an attacker can reach a production database from the internet needs different access, a different duration and different success criteria. If the real aim is to learn whether your security team detects an intrusion, you are describing a red team exercise, and it should be scoped as one. Where the open question is which type of exercise to buy, the related note on red teaming, penetration testing and validation covers that choice.
The capture list
The list below draws on NIST SP 800-115, the NCSC guidance and the PCI Security Standards Council penetration testing guidance. For web applications, the OWASP Web Security Testing Guide supplies the test-case structure that testers commonly work from.
| Item | What to record | Why it matters |
|---|---|---|
| Objective and end condition | The decision the test supports, and when it ends: for example access to a defined data set, administrative control of a defined domain, or no compromise found. | Stops the test drifting past agreed boundaries, and tells you afterwards whether the result was a pass. |
| Scope | In-scope assets with named owners: IP ranges, domains, applications, APIs, cloud accounts, environments. What is excluded, and why. | What is not tested is not assured. Components discovered mid-test need a rule for being added or logged as a limitation. |
| Hosting and third parties | Assets run by cloud, SaaS or managed service providers, the provider’s testing policy, and any approvals required. | Testing infrastructure you do not control can breach provider terms. Provider management portals are usually out of scope unless agreed. |
| Knowledge level | Whether testers start with no information, partial information or full documentation and source access. | No-information testing models an unknown outsider. Full-information testing models a known insider, or makes better use of limited days. |
| Architecture and data flow | Network and data-flow diagrams, expected exposed services, API specifications, application documentation. | Cuts days spent on discovery and points testing at where the data actually is. |
| Accounts and access | One test account for each application role, VPN or network access, tokens. Verified working before the start date. | A frequent cause of lost test days. Authorization flaws cannot be found without more than one role. |
| Known issues and history | Recent scan results, prior test findings, unremediated issues, compensating controls, planned changes. | Testers avoid rediscovering what you already know, and can judge how accurate your own assessment is. |
| Fragile systems and constraints | Legacy or production-sensitive systems, restricted data, blackout periods, change freezes. | Prevents avoidable outages and defines where testing runs manually or at reduced intensity. |
| Security controls | Which controls stay on (WAF, IPS, EDR, rate limiting), and which are relaxed or allow-listed for tester source addresses. | The answer depends on the objective. See the decisions below. |
| Who knows | Which staff are told, which monitoring or response staff are not, and a senior contact able to end the test. | Decides whether detection and response are exercised, or deconflicted early. |
| Rules of engagement | Testing windows, permitted depth of exploitation, whether denial of service is allowed, social engineering limits, tester source addresses and equipment. | Tester and client should work from the same document, agreed before the start. |
| Sensitive data handling | Whether testers may touch real data, proof-of-concept limits, and how evidence is stored, transferred and deleted. | Test evidence is itself sensitive. |
| Contacts and escalation | A technical contact reachable at short notice, an out-of-hours number and an escalation path on both sides. | A blocked test, or a critical finding waiting on a callback, is costly. The NCSC lists a missing technical contact as a common pitfall. |
| Stop conditions | What triggers an immediate pause: signs of a prior or active compromise, system instability, access beyond scope. | Evidence of real attacker activity should start incident response, not continued testing. |
| Authorization | Signed approval from asset owners, the legal basis for testing, and consent from third parties. | Testing without authority can create legal exposure for the tester and the client. |
| Reporting and retest | Report format and audience, severity scale (for example CVSS alongside a qualitative rating), retest terms, how findings will be tracked. | Findings need an owner and a route into remediation. |
That is a long list for one form, which is why it works best as a one-page pre-test brief completed jointly by the system owner and the security team, then agreed with the tester before a start date is confirmed. Add the tester’s credentials and the named people who will do the work. The NCSC notes that tester skill largely determines test quality.
Four decisions that need an owner, not a default
-
Whether security controls are relaxed. A test run with the WAF in blocking mode may tell you a great deal about the WAF and little about the application behind it. Allow-listing tester addresses exposes the application’s own resistance to exploitation. Leaving controls on tests detection and blocking. Choose according to the objective.
-
Whether the monitoring team is told. If the aim is to exercise detection, limit knowledge to a small deconfliction group that can end the test if real activity appears.
-
Who accepts the risk of testing production. Production gives realistic results and a real chance of disruption. Name the person who makes that call.
-
What happens when scope grows. Newly found components outside scope are either added or recorded as limitations. The NCSC places that decision with the risk owner.
What not to expect
A penetration test describes the system on the days it was tested. It does not replace vulnerability assessment or continuous control testing, and the report is not a list of everything that is wrong. The NCSC warns against using the test as the main security check and against handing risk decisions to the testers. Ideally you already know most of what they find. If a test turns up many problems you did not know about, the finding to act on may be the weakness in your own vulnerability management.
Plan for the return trip as well. Reassessing severity should clarify risk, not shrink it. Consider alternatives to the suggested fix, such as removing unneeded software or adding compensating controls. And use previously unknown findings to improve detection.
NEXT STEP Fill in the capture list for your next planned test before you request quotes. Quotes based on the same brief can be compared against each other. Quotes based on a one-line scope cannot. |
Sources
-
UK National Cyber Security Centre, Penetration testing. https://www.ncsc.gov.uk/guidance/penetration-testing
-
PCI Security Standards Council, Penetration Testing Guidance. https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf
-
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment. https://csrc.nist.gov/pubs/sp/800/115/final
-
OWASP, Web Security Testing Guide. https://owasp.org/www-project-web-security-testing-guide/
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionProtect What MattersGuard the identities, data and systems the business depends on.See how we work →Related service
Penetration Testing & Red Teaming
Use this to choose and scope security validation.