What the conversation should produce.
- A scoping document that records the testable objective, the asset boundaries, the assumptions, and the evidence standards agreed before testing begins.
- A boundary table that lists each in-scope and excluded system alongside the business or methodological reason for its status.
- A methods and evidence matrix that maps each planned test type to the level of confirmation required before a finding is recorded.
Translate a broad concern into a testable objective
A broad concern such as fear of data exposure rarely survives contact with reality unless it is converted into a specific question. The first step is to separate the underlying business worry from the technical symptoms that people assume cause it. A statement like we need to know if our customer records are at risk becomes a testable objective when the scope identifies the data class, the access path under review, and the condition that would count as a finding. This conversion prevents the engagement from drifting into a general audit that produces conclusions nobody can act on.
The testable objective should include a clear boundary around what counts as evidence and what does not. A hypothesis such as an attacker could reach the payment database through the public web portal is testable because it names the starting point, the target, and the condition for confirmation. The objective must also acknowledge what it cannot prove, since any assessment examines a slice of a live environment rather than the whole system. Stating these limits upfront keeps the engagement honest and makes the eventual report easier to interpret.
List assets, dependencies and third-party boundaries
Every assessment touches systems that the testing team does not own, and failing to map those boundaries creates both risk and confusion. The scoping exercise should produce a list of in-scope assets alongside the dependencies that support them, including shared databases, authentication providers, and integration endpoints. Third-party services introduce a distinct category of uncertainty because access, ownership and available evidence depend on the service and the authority granted. The scope must therefore state which external components are included, which are excluded, and what evidence will be accepted from the customer rather than from direct observation.
Dependencies often determine whether a finding is actionable or merely theoretical. A web application may appear secure in isolation, but if it relies on a legacy internal service that lacks logging, the overall risk picture changes. The scoping document should capture these relationships as a dependency map rather than a simple asset inventory, because the map reveals where evidence will be thin and where the assessment will need to rely on customer-provided information. This distinction matters when the report later explains why certain areas remain untested or why a conclusion rests on indirect evidence.
Agree the starting assumptions and the evidence threshold
Every assessment proceeds from assumptions that must be made explicit before work begins, because unexamined assumptions become the source of most disagreements after the report is delivered. The starting assumptions include the tester's access level, the knowledge available about the environment, and the classification of the systems under review. These assumptions shape what methods are appropriate and what conclusions can reasonably be drawn. A scope that assumes no prior knowledge of the target produces a different exercise than one that assumes detailed architectural documentation is available, and the difference should be stated rather than implied.
The evidence threshold determines what level of confirmation is required before a finding is recorded, and this decision should be agreed in advance. A hypothesis that a misconfiguration exists may be supported by a single observation, while a hypothesis about an attacker's ability to move laterally may require multiple corroborating indicators. The scope should describe the standard of evidence for each category of finding so that the team and the customer share the same expectation. This agreement also prevents the report from being interpreted as proof of anything beyond what was actually observed.
Bring operational owners into the planning conversation
Include the operational knowledge and authority needed to plan the work, while being explicit about any scenario-specific limits on participant awareness. In some exercises, a designated control group coordinates with owners without informing every defender of the detail. The people governing the engagement still need to understand constraints such as maintenance, dependencies and potential effects. Record what information will be shared, with whom and why, so realism does not become an excuse for ambiguous authority or unavailable operational support.
Operational owners also define the communication cadence that the exercise will follow, which is as important as the technical scope. Agree an update cadence and an escalation route appropriate to the work. These arrangements help surface small issues and route urgent observations, without guaranteeing that every problem can be prevented. The planning document should record who receives which information, when, and in what format, because ambiguity in this area is a common source of friction. Including these details in the scope makes the engagement predictable for everyone involved.
Specify stop conditions and a controlled change process
An assessment must define the conditions under which testing stops, because uncontrolled testing can escalate from observation into disruption without anyone intending it. Stop conditions should cover both technical triggers, such as repeated service degradation or unexpected data modification, and procedural triggers, such as the discovery of evidence that suggests criminal activity or the involvement of systems outside the agreed scope. The scope should state who has the authority to invoke a stop, how that decision is communicated, and what happens to the evidence collected up to that point. This structure protects both the customer's operations and the integrity of the exercise.
A controlled change process governs what happens when the testing team encounters something that was not anticipated, because ad hoc decisions in the moment rarely survive scrutiny. The process should describe how a new observation is logged, who evaluates whether it warrants further investigation, and what documentation is required before any additional testing proceeds. This is not about slowing the work down; it is about ensuring that every deviation from the plan is recorded and justified. The scope should include a simple decision tree so that the team can act quickly without abandoning discipline.
Write a brief that makes unanswered questions visible
A scoping brief that only lists what will be tested inevitably hides what will not, and those omissions are where most misunderstandings originate. The brief should therefore include a dedicated section that records the questions the exercise cannot answer, such as whether a control that was not observed functions correctly, whether a system outside the scope behaves as expected, or whether the evidence gathered is sufficient to support a particular conclusion. Making these gaps visible converts uncertainty from a liability into a documented limitation, which is far more useful than an implicit assumption that the assessment covered everything.
The brief should also distinguish between areas that were intentionally excluded and areas that were excluded because they could not be reached with the agreed methods. An intentional exclusion reflects a business decision, such as choosing not to test a legacy system that is scheduled for retirement, while an inability to reach an area reflects a methodological constraint. Both types of gap deserve explicit notation because they shape how the eventual findings should be interpreted. A brief that treats all omissions the same way produces a report that readers will inevitably misread.
Illustrative scenario: assessing a customer-facing portal with a shared backend
This scenario is illustrative and describes an illustrative situation. A mid-sized retailer wants to understand whether its public e-commerce portal exposes customer data. The scope identifies the portal, the authentication service, and the order-processing database as in-scope assets, while excluding the warehouse management system that shares the same network. The team assumes no prior knowledge of the portal's code and agrees that a single anomalous response is insufficient evidence of a data exposure. The operational owner for the portal is included in planning and defines a stop condition if checkout latency exceeds a set threshold.
- Decide whether the shared authentication service is in scope, because findings there may or may not apply to the portal depending on how access controls are enforced across both systems.
- Agree what observation would support the specific exposure conclusion while minimising data collection. A single well-supported record can be significant; collecting more sensitive records is not automatically necessary or justified.
- Decide how to document the exclusion of the warehouse system, because readers may otherwise assume the assessment covered all systems on the same network segment.
This scenario establishes that scoping decisions determine which questions the exercise can answer and which remain open. It does not establish that the portal is secure or insecure, because the scenario describes planning rather than results. The value lies in showing how assumptions, boundaries, and evidence standards are recorded before testing begins.
Useful decision table for scoping choices
| Question | What to establish | Useful output |
|---|---|---|
| Which systems are in scope and which are excluded | The business reason for each inclusion or exclusion, and whether the exclusion is intentional or constrained by access | A boundary table listing each asset, its scope status, and the rationale for that status |
| What level of access the testing team will have | The knowledge assumption, the permitted methods, and the evidence threshold for each category of finding | A methods and evidence matrix that maps each test type to its required confirmation standard |
| How operational impact will be managed during testing | The stop conditions, the escalation path, and the communication cadence agreed with the operational owners | A change and escalation procedure document signed by the relevant owners before work begins |
Scroll the table horizontally on smaller screens.
Useful questions.
Can a scoping document prevent a finding from being disputed later?
No document can prevent every disagreement. A clear scope provides a common record of included areas, agreed methods, assumptions and evidence expectations. That makes later questions easier to examine against the actual plan. Keep changes traceable and distinguish a disagreement about the observed facts from one about the significance of those facts.
Is it acceptable to leave some questions unanswered in the scope?
It is not only acceptable but necessary to leave some questions unanswered, because a scope that claims to answer everything is usually hiding its limitations. The scoping document should record which questions it cannot answer and why, distinguishing between intentional exclusions and methodological constraints. This transparency is more valuable than an incomplete list of answers, because it tells readers exactly where the exercise's conclusions rest on direct observation and where they rest on inference or customer-provided information.
Further reading: NIST SP 800-115: testing and assessment guidance. This independent resource provides background; no affiliation, certification or endorsement is implied.