Pentest Scoping Checklist: What to Clarify Before the Test

A penetration test is only as good as its scope. Every disappointing test we have heard of, the report that found nothing because the interesting system was excluded, the test that stopped on day two for a missing account, the finding that nobody could reproduce in production, goes back to a scoping call where a question was not asked. This checklist is the list of those questions.

Go through it before the scoping call, and bring the answers. Half a day of your preparation is worth a testing day.

1. Targets: what exactly is tested

• List every target by name: URLs, hostnames, IP ranges, app store IDs, cloud account IDs, device model and firmware version, ECU variant and software release, plant segment.
• Draw the boundary. What is in scope, what is out, and what is grey: third-party components, shared services, the identity provider, the payment provider.
• Count what drives effort: user roles, pages or endpoints, integrations, interfaces on a device, diagnostic services on an ECU, network segments in a plant. These numbers decide the days and the price.
• Say what matters most. The customer data? The firmware signing? The safety function? Testers prioritise by what you tell them.

2. Environment: where it is tested

• Production, staging or a dedicated test environment? Staging only if it matches production in configuration, integrations and data shape.
• For hardware, IoT and ECUs: how many units, and may they be destroyed? Debug access, firmware images, schematics and a bench power supply or a test harness speed everything up.
• For OT: a test bench, a spare controller or a twin setup. Active testing on a running plant needs a maintenance window and a safety sign-off; see OT pentest without downtime.
• For cloud: which accounts or subscriptions, which read-only role for the testers, and whose approval the provider’s testing policy needs.

3. Access and test depth

Approach	Testers get	Right when
Black box	Nothing but the target name	You want to know what an outsider can do; longer for the same coverage
Grey box	Accounts per role, architecture overview, API specification	Most tests; best findings per day
White box	Source code, configuration, build artefacts, firmware	Products before release, security-critical code, compliance evidence

Whatever you choose: two accounts per role, so authorisation between users can be tested. Accounts must work on the first morning, with MFA enrolled and test payment methods where needed.

4. Rules of engagement

• Time window: dates, working hours, time zone, and whether night or weekend testing is allowed or required.
• Exclusions: denial-of-service, social engineering, physical access, destructive tests, specific hosts. Write them down.
• Fragile systems: anything that must be handled carefully, old appliances, a PLC that reboots on a port scan, a rate-limited third-party API.
• Stop conditions: what the testers do when they find data of real customers, evidence of a previous breach or a critical finding. Usually: stop, call, document.
• Contacts: one technical contact on your side who answers within hours, one escalation contact, one on the tester side, with phone numbers.
• Monitoring: does your SOC know? Decide whether the test is also a detection exercise or whether the blue team is informed in advance.

5. Legal authorisation

• A written authorisation signed by the system owner, naming the targets, the period and the testers. In Germany, security testing without authorisation falls under § 202a to § 202c StGB; the signed permission is what makes it legal. Zyberum does not start without it.
• Third parties: hosting providers, SaaS vendors, outsourcing partners whose systems are touched must consent in writing. Cloud providers have published policies for testing your own resources; read them.
• Data protection: if personal data may be seen, agree how it is handled, where evidence is stored, and when it is deleted. An NDA is standard.
• For products: confirm you may test components from suppliers, or exclude them.

6. Deliverables

• Report structure: management summary, scope and method, findings with reproduction and fix recommendations, CVSS and contextual severity, attack chains. See how to read a pentest report.
• Format needs: a mapping to a standard or regulation (OWASP ASVS, IEC 62443-4-2, ISO/SAE 21434 work products, CRA Annex I), a redacted version for customers, a letter of attestation after the retest.
• Results presentation: one hour with engineers and management, usually a week after the report.
• Retest: included or not, how many rounds, until when. Make it part of the offer.
• Language: German, English or both.

7. The questions testers will ask you

Expect these in the call; having answers makes the offer precise:

1. Why now? A customer requirement, a regulation, a launch, an incident, a routine?
2. Has it been tested before, and may we see the last report?
3. What changed since then?
4. Who fixes the findings, and when do they have time?
5. What would be the worst thing an attacker could do with this system?

Common scoping mistakes

• Excluding the interesting part because it is “handled by a partner”. The attacker does not care who runs it.
• Scoping by budget first. Decide what needs testing, then decide what to postpone, explicitly.
• No retest. A report full of open findings is not what your auditor wants to see.
• Accounts on day three. The most common cause of lost testing days.
• Testing a staging system nobody maintains, and then arguing about whether production has the same bug.

After scoping

You get a fixed-price offer with the targets, days, dates, exclusions and deliverables written down. That document, plus the signed authorisation, is the scope. If the target turns out to be larger during testing, a good provider tells you on the first day and lets you choose: extend, narrow or accept reduced coverage, documented in the report. Book a free scoping call and bring this list.