Choosing the right scope for your next pentest

Sep 24, 2026 • 5 min read

A customer asks for a penetration test report. An audit is approaching. Your team is preparing to launch a new application. You need a quote, but first you need to establish what the test should cover.

At Halo Security, we help clients define penetration testing scope around their goals, environment, budget, and deadline. You bring knowledge of your business and systems. We help identify where testing will be useful, what access testers need, and what can realistically be covered.

The result should be a proposal that makes clear what you’re buying, what you’ll receive, and what will remain untested.

Start with what you need the penetration test to answer

Tell your pentest provider what prompted the request. Different goals can lead to different scopes:

A customer security review: Which product or service does the customer use, and what evidence have they requested?
A compliance requirement: What does the specific requirement say about testing coverage and reporting?
A new application or major release: Which features, integrations, or permission changes need assessment before launch?
An attacker’s potential access: Are you concerned about someone on the internet, a compromised customer account, or an attacker already inside your network?

When you discuss scope with Halo Security, share the actual customer request or audit requirement when possible. We can help identify what it means for the engagement and which questions to resolve with the customer or auditor before you sign.

“Can one customer access another customer’s records?” gives the scoping conversation a more useful starting point than “We need a pentest.”

What does penetration testing scope include?

Penetration testing scope is the agreement about which systems will be tested, what access testers receive, what activities are permitted, and what the provider will deliver.

Two proposals labeled “web application penetration test” can cover different things.

Consider a customer portal with public pages, authenticated customer accounts, an administrative interface, and an API. One proposal might include all four. Another might cover only the customer interface and the API functions it uses.

The proposal should make those boundaries clear. An application name or URL alone may not explain which interfaces, roles, and workflows the testers will assess.

Identify the systems and workflows you need covered

You don’t need to design the test yourself. A useful starting point for a scoping conversation with Halo Security is a short application walkthrough, a list of known assets, and whatever documentation you already have.

Show us the applications, APIs, and network environments involved. Explain who uses them, including customers, employees, and administrators, and how their permissions differ.

Walk through the work those users perform. Creating accounts, inviting colleagues, approving transactions, uploading documents, and exporting records can reveal testing needs that a list of URLs won’t capture. Point out where sensitive data enters the system, who should have access to it, and where it goes next.

Include connected systems and third-party services in the discussion. An integration may need testing within your application, while testing the third party’s own infrastructure requires separate authorization.

If your inventory or documentation is incomplete, say so. Your provider should help identify the missing information and explain whether resolving it will affect the quote or coverage.

Agree on access and the testing environment

Work with your provider to decide whether testing will happen in production, staging, or both.

Staging can give testers more freedom to exercise workflows using test data. Its usefulness depends on how closely it represents the application you operate. Differences in code, configuration, authentication, or integrations can leave production behavior unassessed.

Production testing can assess the live environment, but operational restrictions may limit particular activities. Agree on those restrictions and their effect on coverage before testing begins.

Also confirm:

Which accounts and permission levels testers need.
Whether multiple accounts within the same role are needed to assess access between users.
Whether separate customer organizations or tenants are needed to test data separation.
Which workflows need realistic sample data.
Whether testing windows, access controls, or third-party permissions require preparation.

These choices determine what testers can examine. A single administrator account, for example, does not provide the same coverage as accounts representing customers with different permissions.

For mobile engagements, Halo Security’s guide to preparing for your mobile application pentest covers account setup, documentation, and application builds in more detail.

Match penetration testing coverage to your budget

Within a fixed testing budget, adding systems generally leaves less time to investigate each one. Ask your provider to explain how they would allocate that time.

Suppose your company has a customer portal, a public marketing site, and an internal application. The portal handles confidential customer documents, the marketing site publishes information, and the internal application manages employee access.

Your provider might recommend deeper testing of the portal’s data access controls. They might also identify the internal application as a priority because of the permissions it can grant. The decision should account for exposure, sensitive data, business impact, and any required coverage.

When reviewing options with Halo Security, ask:

What would you prioritize, and why?
What would receive less attention at this budget?
What would remain untested?

If the budget cannot support the required coverage, discuss a narrower engagement, additional funding, or testing in phases. Confirm that any phased approach still meets your customer’s or auditor’s deadline and expectations.

Confirm reporting, remediation support, and retesting

Before signing, clarify what your team will receive and how the provider will support the work that follows.

Ask which technical reports, executive summaries, and customer-facing documents are included. Confirm how urgent findings will be communicated and who on your team should receive them.

Find out whether your engineers can discuss findings directly with the tester. Clarify what remediation support includes, whether retesting is included, and any limits on its timing or number of rounds. Ask whether you’ll receive an updated report showing the status of verified fixes.

Separate the testing schedule from the reporting, remediation, and retesting schedule. Finishing testing on Friday does not mean you’ll have a report with verified fixes on Monday.

Give your provider the date you need usable documentation. Work backward from that date, allowing time for reporting, your team’s fixes, and verification. Ask how delayed access, environment changes, or additional testing could affect delivery.

Review your pentest proposal for gaps

Use this checklist before signing:

Named systems: Applications, APIs, domains, IP ranges, and relevant interfaces.
User roles: Account types, permission levels, and customer or tenant boundaries.
Environments: Production, staging, or both, with access requirements.
Testing boundaries: Permitted activities, restrictions, exclusions, and agreed priorities.
Timing: Testing dates, report delivery, and preparation deadlines.
Deliverables: Reports, customer-facing documents, and findings discussions.
Retesting: Included verification, deadlines, limits, and updated documentation.

Resolve assumptions such as “the API must be included,” “all user roles will be tested,” or “we can add another application later.” Ask the provider to put the agreed coverage in writing.

Also agree on how changes will be handled. If testers discover another application or an undocumented API, who decides whether to include it? Will the change affect cost, timing, or other coverage? Newly discovered systems should be discussed and authorized before testing expands beyond the agreed boundaries.

Define your pentest scope with Halo Security

You don’t need a finished technical specification before contacting Halo Security. Start with what you need to accomplish, a brief description of your environment, and any questions about coverage.

We’ll help you work through the options, explain the tradeoffs, and prepare a proposal with clear expectations before testing begins.

Bring Halo Security your testing goal, deadline, and a brief description of your environment. We’ll help you define the scope and prepare a clear proposal.