How to scope a penetration test that produces fixes

If the scope is vague, the report will be too. Write the boundaries before anyone quotes a day rate.

A useful penetration test starts with a written scope: systems in and out, rules of engagement, evidence format, and what happens if something serious appears mid-week. Without that, you buy a PDF that nobody can act on.

Start with the outcome

Most scopes fail before the first packet is sent. Someone asks for “a pen test”, a day count appears, and the conversation moves to scheduling. Nobody has said what done looks like.

Write the outcome first. You want reproducible findings against named systems, prioritised for your stack, with a retest path for the items you accept. If that sentence feels too sharp, the engagement is not ready to price.

Outcomes also kill vanity. “Cover as much as possible” is not an outcome. It is how you spend the budget on low-value surface area while the payment API sits untouched.

Name what is in and out

List every host, application, API, and cloud account that is fair game. Then list what is not: third-party SaaS you cannot authorise, shared infrastructure, production payment rails you will only touch in staging, staff laptops, physical sites.

Ambiguous neighbours are the usual mess. A marketing subdomain on the same certificate, a forgotten staging box with production credentials, a partner portal that shares SSO. If it can be reached from an in-scope entry point, decide now whether it is fair game or a hard stop.

Environments matter as much as hostnames. “Production only” and “staging first, production later” are different projects. Write which one you bought.

Agree the rules of engagement

Rules of engagement are not paperwork theatre. They answer the practical questions testers hit on day two: Can we create accounts? Can we spam password resets? Do we stop at proof of concept or attempt data access? Who gets the emergency call at 23:00?

Name people on both sides. A shared inbox is not an escalation path. If the tester finds an active compromise indicator, they need a mobile number that answers.

Time boxes belong here too. Testing windows, blackout dates, and change freezes stop a “quiet week” from colliding with a release.

Decide what evidence looks like

Ask for the format before the work starts. Screenshots without requests are weak. Severity labels without reproduction steps are weaker. You want enough detail that an engineer who was not in the kickoff can rebuild the issue.

Agree where evidence lives: your share, encrypted archive, named bucket. Email attachments of exploit notes are how sensitive material ends up in the wrong retention policy.

If you need a questionnaire-friendly mapping to a control framework, say so up front. Retrofitting CVEs into a compliance matrix after delivery wastes everyone’s week.

Plan for bad news mid-engagement

Serious findings arrive early more often than people expect. Scope should say what happens then: pause and notify, continue with a narrowed focus, or open a separate incident track.

Without that clause, the tester either soft-pedals or keeps going while your team is already in crisis mode. Neither is professional.

A scope you can defend in writing is the difference between a test that changes the backlog and a PDF that sits in a shared drive until the next audit asks for it.

Questions

Can we skip a formal scope if we already trust the tester?

No. Trust does not replace boundaries. Scope protects both sides when a finding sits next to a system nobody meant to touch, or when the client expected retesting that was never written down.

How detailed should the asset list be?

Detailed enough that a stranger could tell whether a host is in or out without calling you. Domains, environments, IP ranges, and explicitly excluded vendors beat “the production estate”.

Should social engineering be included by default?

Only if you want it. It changes authorisation, risk, and reporting. Put it in writing as in or out. Leaving it implied is how engagements go sideways.

Let's Talk.

Five questions, about two minutes. A named person replies within one working day.

Start a brief