What Decision Is This Test Supposed to Inform?
Scoping sets the limits of what a penetration test can report. The boundary you draw decides which findings are possible, because a report can only describe what the testers were allowed to reach. Draw it around the wrong systems and the result answers a question you did not need answered.
Start with the decision. Write one sentence naming what the result will change. A new customer portal either goes live or it does not. The segmentation between the office network and the production network either holds or it does not. Fixes from the last round either work or they do not. An assessor needs evidence against a specific control. Each of those sentences implies a different target list, a different depth, and a different report.
If no sentence comes, the scoping conversation has nowhere to start, and that is worth knowing before a provider is engaged. Write the sentence with the people who will act on the result: the application owner, whoever runs the network, and whoever will be asked to fund the remediation. If the honest answer is that you are not yet sure a penetration test is the right instrument, that is a different question from this one, and the earlier article comparing a penetration test with a vulnerability scan is where it is addressed.
Draw the Boundary Before Anyone Touches a Keyboard
A usable scope names things. “Our web presence” leaves a tester to guess which systems you meant. Named hosts, ranges and applications do not.
Third-party hosting is worth settling first, because you can only authorize testing of what you control. Hosted platforms, SaaS applications and managed service providers set their own testing rules, and a verbal yes from an account manager is not written authorization. If any item on the list below sits with a provider, obtain their written authorization during scoping rather than on the morning testing starts.
- Exact domains, subdomains, IP ranges and application URLs, noting which sit on shared infrastructure
- Cloud accounts, subscriptions or projects by identifier, and whether the control plane is in or out
- Identity systems: directory domains, single sign-on tenants, and whether password attacks against live accounts are permitted
- Mobile or desktop clients by build, plus the APIs behind them
- Operational technology or building system segments, with any device that must never be touched written down by name
- Everything explicitly out of scope, including anything hosted by a provider whose own authorization you do not have
How Much Information Should You Hand Over?
Black box testing starts with little more than a company name and imitates an outsider’s view. Gray box supplies credentials and some architecture. White box adds source code, design documents and an engineer who answers questions.
The tradeoff is where the hours go. Time spent rediscovering an application’s structure is time not spent probing authorization logic, tenant isolation, or the workflow that lets a low-privilege user approve their own request. If you want depth in the parts of the system your business runs on, hand over the map. If the question is genuinely what a stranger can find from outside, hold information back and accept that coverage inside will be shallower.
Either way, supply credentials for every user role rather than the obvious ones alone: the read-only auditor, the support agent with an impersonation feature, the service account an integration uses.
Rules of Engagement, in Writing
Nothing intrusive begins before scope, authorization and constraints are agreed in writing and signed by someone with the authority to grant them. That document protects both sides, and it gives your own responders a documented basis for telling authorized testing apart from an intrusion.
Decide in advance whether your monitoring team is told. Leaving them uninformed tests detection and response as well as the target, which is worth doing, but only when someone senior knows and the stop conditions are unambiguous.
- Testing windows, including hours when all activity must stop
- The source addresses testers will work from, so your own responders can tell the test from the real thing
- Techniques excluded by agreement, such as denial of service, physical entry, or social engineering against staff
- How credentials, extracted data and screenshots are stored, transmitted and destroyed
- Named contacts on both sides who are reachable during the window, with an escalation path
- Stop conditions: what pauses testing immediately, and who can make that call
Production, Staging, or a Bench?
Staging is safer, and it can be wrong in ways that matter. Configuration drifts, data volumes differ, integrations are stubbed, and any finding invites the argument that production is set up differently. Production is accurate and carries real risk to real users. A practical split is production for read-mostly checks, with anything destructive or state-changing done against a copy built from the same pipeline. Say which is which in the scope document.
Industrial control and building system segments need clauses of their own rather than the same rules applied more carefully. Name the devices that must never be touched, state whether any active probing is permitted at all and inside which maintenance window, put safety instrumented systems out of scope in writing, and name the engineer who is present and holds the authority to stop. Why these environments need separate handling is covered in the earlier article on plant floor security and on the OT and ICS assessment page. The point here is narrower: the scope document has to say so explicitly rather than leave it to judgment on the day.
What a Penetration Test Cannot Tell You
A test describes what a specific group of people found, inside an agreed boundary, during a fixed window, using the information they were given. It is a sample, not a proof. No engagement can show that a system has no remaining vulnerabilities, and a report that implies otherwise is overstating what the method can do.
So read a quiet report carefully. It may mean the application is well built. It may also mean the scope was narrow, the window was short, or the interesting functionality sat behind a workflow the testers were never credentialed to reach. The debrief conversation is where you find out which.
It also does not replace continuous work. Code changes the week after the report is written, and scoped testing sits alongside scanning, dependency monitoring and secure development practice.
Agree the Deliverables and the Retest Before Work Starts
The report is a deliverable with requirements like any other. Decide during scoping what it must contain: reproduction steps a developer can follow, evidence, severity explained in terms of your environment rather than a generic score, and remediation guidance specific enough to become tickets.
Agree the retest at the same time. Which findings qualify, how long you have to fix them before it happens, and whether the retest covers only the original findings or the code that changed around them. If that is left open, whether a retest happens at all becomes a separate negotiation after the report has landed.
Related service: Related service: The penetration testing service page covers how an engagement is delivered once a scope like this one is agreed in writing. If you are still deciding whether a penetration test or a vulnerability scan answers your question, the earlier article comparing the two covers that choice.
Related service: penetration testing and security assessment.