Why scoping is important
If you don’t scope well, you can miss dangers, go behind time, or go over budget. Standards put a lot of stress on preparing before involvement since it leads to results. NIST’s technical guide says that planning is the most important part of testing, analysis, and fixing problems.
It’s much more crucial to get the scope correct now that breach costs are going up. IBM’s 2025 study says that the costs of breaches have gone up again, and they are now higher because of differences between regions and new AI-related dangers.
Step 1: Focus on the business goal
Don’t just tick off a box for the test.
Goals that are common
Check security before a launch or move.
Meet a client or market need, such PCI DSS or a buyer security review.
For example, web app and identity attacks are the most common types of attacks mentioned in DBIR. Reduce the risk for these approaches.
What does success mean?
The outcome of the executive. A “Board ready summary that maps findings to business impact” is an example.
Technical result. For example, “Proof that SSO and MFA stop account takeover against X personas.”
Outcome of compliance. “Meets PCI guidance for segmentation and annual testing” is one example.
Step 2: Make a list of the attack surface
Make a small list of target systems that is versioned. Only change requests should be used to update it.
Minimum number of fields per target
Name of the system or software, the environment, and the owner.
Points of entry. IP ranges, domains, APIs, mobile packages, and thick clients.
Roles and pathways for authentication.
Third parties and webhooks that could be in the blast radius, such Stripe or Plaid.
The crown jewels. Types of data, important workflows, or transactions.
Use the PTES pre-engagement questions to make this list.
Step 3: Pick the kinds of tests and how deep they should go.
Choose the styles that fit the goal and the resources.
Common combinations
OWASP WSTG guides web and API testing. Good for projects with a lot of features and modern API stacks.
Testing the outside network for services that are open to the public and settings that are wrong.
Testing the internal network to create a foothold.
IAM, network segmentation, and service policies all need cloud configuration and identity testing.
Testing mobile apps for iOS or Android packages and an API backend.
Segmentation testing, which requires confirmation that the scope bounds really do hold.
Settings for depth
The black box. Very little context. Finding things takes longer. Good for checking resilience.
Box in gray. Few credentials or design notes. Most teams get the best signal to noise.
A white box. Complete records and documents. Best for hardening that has to be done by a certain date.
Step 4: Set guidelines on how to interact
Rules make sure that tests are safe and helpful.
Important things
Windows for timing and maintenance. Don’t plan on releasing things.
Things that are not in the scope. Creating harmful payloads, social engineering, or DDoS attacks is not allowed unless you get permission first.
Handling data. How testers will save, send, and erase data.
Words that are safe and conditions that stop. For warnings about service problems or fraud.
Letter of permission. Asset owners must sign a written permission slip to test. NIST and PCI literature stress the importance of getting explicit permission and setting clear boundaries.
Step 5: Make sure the effort is the right size.
Not just counting, but also estimating by target complexity.
Things that make you work hard
Number of different apps and APIs.
Role matrix, SSO flows, and auth complexity.
Integrations with third parties and webhook flows.
Cloud surface area and tenancy.
Needs for proof of compliance and data sensitivity.
Quick planning ratios
Use these as a guide, but change them based on your prior data and the architecture….
| Target type | Light coverage | Standard depth | Deep or white box |
| Single page app + API | 3 to 5 days | 7 to 10 days | 12 to 15 days |
| Small external network, up to 64 hosts | 2 to 3 days | 4 to 6 days | 7 to 10 days |
| Internal network, single site | 3 to 5 days | 7 to 10 days | 12 to 15 days |
| Cloud tenancy review | 2 to 4 days | 5 to 8 days | 10 to 15 days |
To explain why you should focus on this, compare it to known attack behaviors in DBIR, including credential misuse on online apps.
Step 6: Choose the accounts and test data
Give safe, real data and user profiles.
Things you need
Test tenants or fake production clones for cloud and SaaS.
User roles that are like how people really use the system.
Use test payment cards or sandbox keys to check integrations.
MFA routes and any flows that bind devices.
Step 7: Lock the document for the scope
Make a scope that everyone can read that is one to two pages long.
Include
In the list of things to do. Assets, endpoints, and environments.
List of things that are not in scope.
Types and depth of tests.
Credentials and personas are given.
Rules about how to act and who to call in an emergency.
Daily standups, a schedule, and a reporting strategy.
Terms for retesting and acceptance requirements.
PTES calls this the end of the interactions that happened before the engagement. Without this, testing can go off track easily.
Step 8: Make a plan for reporting and evidence
Plan ahead how the results will be shared and used.
Reports that are good include
Executive summary with risks linked to company results.
Technical results that have an effect, procedures to reproduce, and a clear fix.
Proof, pairs of requests and responses for APIs, and screenshots.
Scoring severity and linking to relevant standards like OWASP or NIST.
If you need PCI or marketplace proof, make sure the report sections match the language of the guidance. This stops the need for more work.
Step 9: Add notes on compliance-specific scoping
Your control frameworks must be able to handle the scope.
PCI DSS. Show how to split things off, describe how close the CDE is to other things, and test the limits. Guidance says that segmentation controls should be tested for penetration and checked on a regular basis.
SOC 2 or ISO 27001. Check that the test scope matches the items in the risk register and the important controls.
Cloud marketplaces and big purchasers. Some buyers, like Google’s supplier security pages, want any part that handles their data to be tested at the application level.
Step 10: Make sure change control is in place
New releases come out during testing. Make a change gate.
Only accept changes to the scope if they are in writing.
We will retest with minor adjustments to the material.
Changes to the material, such adding an authentication provider or a key feature, need to be made.
Checklist for example scoping
Use this to get your call started.
Business aim, choice to help, and deadline.
Target types of data, environments, and inventory.
Roles for users, SSO routes, and MFA.
Payment flows, third parties, and webhooks.
Types of tests. Web, API, mobile, cloud, external, internal, and segmentation.
How deep. A box that is black, gray, or white.
Rules on how to act, when to stop, and who to talk to.
Deliverables and retesting.
Mapping for compliance.
Letter of permission.
Partnering with someone
If you want a human-powered, senior-led strategy, think about working with a specialist partner like DeepStrike Penetration Testing Services that can tailor the scope to your business’s risk and compliance needs. You may also find out how vendors use methodology here, in the article “Top Penetration Testing Companies 2025.”
In conclusion
Great scopes are the first step in great penetration tests. Make a business choice, figure out what parts of the system are vulnerable, choose the types and depth of tests, and agree on how to interact with the system. Use standards like NIST SP 800 115, PTES, and OWASP WSTG to decide what to do, and use breach data to help you decide what to do first. Write it down and then test it for a reason.
