How to Scope a Penetration Test (and What to Ask the Tester)

What the rules expect

• NIS2 digital providers: Implementing Regulation (EU) 2024/2690 requires a security testing policy. You set the need, scope, frequency and type of tests from your risk assessment, test to a documented methodology, record type, scope, time and results with a criticality for each finding, and apply mitigating actions for critical findings (Annex, point 6.5).
• DORA financial entities: the testing programme includes penetration tests among other tests (Article 25(1)), tests must be carried out by independent parties, internal or external (Article 24(4)), and systems supporting critical or important functions must be tested at least yearly (Article 24(6)), except for microenterprises.
• Customers: enterprise buyers often ask for a recent third-party test. See answering security questionnaires.

1. Start with the objective

Write one sentence on what the test must answer, for example "Can an external attacker reach customer data through our web application or its API?" The objective decides the scope, the test type and how you judge the result.

2. Choose the test types

3. Define targets and exclusions

• List every target precisely: domains, URLs, IP ranges, API endpoints, cloud accounts, environments (production or staging).
• List what is out of scope, for example third-party SaaS you do not own, payment pages hosted by your provider, or fragile legacy systems.
• Decide the level of knowledge: black box (no information), grey box (user accounts provided) or white box (code and architecture shared). Grey box usually gives the most value per day.
• Provide test accounts for each user role, so authorisation flaws between roles can be tested.

4. Agree the rules of engagement

• Testing window and time zone, and whether production testing is allowed.
• Contacts on both sides, and an emergency stop procedure if something breaks.
• What testers may and may not do: denial of service, data modification, exploiting further after initial access.
• How test data and any personal data they encounter are handled, stored and deleted.
• Immediate notification of critical findings, without waiting for the report.

5. Get authorisation in writing

Testing systems without permission can be a criminal offence. Sign a written authorisation that names the targets and dates, and check that you may authorise testing of every target: your hosting or cloud provider's acceptable use or penetration testing policy may require notification or exclude some services.

6. Define the deliverables

• An executive summary in plain language.
• Each finding with a description, evidence, affected targets, severity rating with the method used, and remediation advice.
• The methodology followed, for example the OWASP Web Security Testing Guide, PTES or NIST SP 800-115.
• A retest of fixed findings, and a short summary letter you can share with customers.

Questions to ask the tester: Who exactly will test, and what qualifications and experience do they have? Is the work manual or mostly automated scanning? Can we see a sanitised sample report? Is the retest included? How do you protect our data and findings? Do you carry professional liability insurance?

After the test

Triage the findings, assign owners and deadlines by severity, fix critical findings first, and retest. Record what was tested, when and with what result: that record is the evidence NIS2 and DORA expect, and it shapes next year's scope.

A scoping document ready to send. The Cybersecurity Starter Pack includes a penetration test scoping document with methodology options, plus a patch and vulnerability management procedure, an asset inventory and a 90-day security roadmap.

Sources

• Commission Implementing Regulation (EU) 2024/2690, Annex, point 6.5 (security testing), EUR-Lex
• Regulation (EU) 2022/2554 (DORA), Articles 24 and 25, EUR-Lex
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide

Related tools