How to scope a penetration test

How to scope a penetration test before you sign anything

A penetration test scope is the written agreement that names the targets, environments, accounts, exclusions, testing windows and rules of engagement for the work, and it is settled during planning, before any testing begins. If a framework, a customer security review, a product launch or an insurer requires a test, the buyer is the party who must define what gets tested, because no provider can infer that from the requirement alone. NIST SP 800-115 treats planning as its own phase: rules are identified, management approval is finalized and documented, testing goals are set, and no testing occurs until that is done. Its appendix provides a rules of engagement template that is a practical starting point for the document you will sign.

A vague scope is expensive in three ways. It drives cost because the tester must spend paid hours establishing what is in bounds, and disputes about boundaries surface mid-test when the clock is running. It misses risk because systems that nobody listed are either never tested or tested by accident, which can cause outages. It fails auditors because a report that does not match a documented scope gives an assessor little to rely on. Decide the knowledge level for each target as part of the scope. PCI SSC's guidance defines black-box testing as no information provided, grey-box as partial details and white-box as full details of the network and applications, and notes that PCI DSS tests are typically white-box or grey-box. Black-box work may take more time and resources to meet the same deliverables, so state the level explicitly in the agreement.

Before you request quotes, assemble an inventory of in-scope IP ranges, domains, applications, APIs, cloud accounts and subscriptions, and third-party hosted components, and confirm which of them you actually control. Name the test accounts and roles the tester will use, such as a standard user, an administrator and a read-only auditor, and state who provisions and removes them. List exclusions, including production systems that must not be disrupted and any third-party services whose providers prohibit testing, and confirm those restrictions with the providers. Agree testing windows, emergency contacts and a stop-test procedure. Confirm the cloud provider's published testing rules and any sign-off your organization needs from internal approvers. Each of these items is a decision you can make now, and each one that stays open becomes a question the tester must answer during the engagement.

What can sit inside a penetration test scope

A scope is a list of targets, owners and boundaries, and each component below needs its own answers before testing starts. Network, application, cloud, identity and segmentation targets often share accounts, trust relationships and hosting, so an unclear boundary in one area changes what can be tested in another. Confirm each component in writing, and name what is excluded as clearly as what is included.

External and internal networks

External scope covers public IP addresses and domains the organization owns and can authorize testing against. Internal scope covers network segments reached from a defined position, such as a office network or a jump host. For each, confirm the named owner, the exact address ranges and hostnames, and whether any addresses belong to a hosting provider or CDN that needs its own authorization. Ask the provider how it will verify that every address in scope is owned by the client.

Web and API applications

Applications are scoped by base URL, environment, user roles and the business flows that matter, such as login, payments, account recovery and data export. Confirm which environment is in scope, whether production data is present, and who can create and reset test accounts for each role. Request the API definitions or documentation the tester will use, and confirm whether third-party services called by the application are excluded.

Cloud accounts and Kubernetes clusters

Cloud scope is defined by account or subscription identifiers, tenants, regions and the services inside each, not by a single application name. Confirm which accounts belong to the client, which are managed by a third party, and which provider testing rules apply to the services in scope. For Kubernetes, confirm the clusters, namespaces and whether the control plane is managed by the cloud provider, since that affects what the client can authorize.

Active Directory and remote access

Identity scope covers domains, forests, trust relationships, VPN gateways, remote desktop services and identity providers. Confirm which domains and sites are included, which privileged accounts the tester may use, and whether test accounts need standard or elevated rights. Agree how domain controllers and backup systems are handled, since a test can affect authentication for the whole environment, and confirm the time window and a contact who can stop testing.

Segmentation boundaries

Segmentation testing checks whether a boundary between networks, such as the cardholder data environment and other systems, actually stops traffic and access. The PCI SSC guidance expects segmentation results to appear in the report, so the scope must list each boundary, the systems on each side and the expected controls. Confirm the network diagrams, firewall rule owners and the systems that define the cardholder data environment, and record the boundaries the client believes are out of scope.

Exclusions and provider cloud rules

Exclusions must be written down, not implied. Name third-party hosted services outside the client's control, such as a SaaS vendor's own infrastructure, and confirm whether that vendor's terms permit testing. Confirm which systems are off limits for stability reasons, such as legacy hardware or production databases, and check the testing rules published by each cloud provider that hosts in-scope assets. An exclusion list that omits a provider or vendor is a common source of dispute after testing starts.

How scoping fits the phases of a penetration test

Scoping is not a single form to fill in. It runs through the whole engagement, starting with written rules and approval before any testing, and each later phase produces evidence that the client can check against what was agreed.

Set goals and get management approval
Before anything else, the client states why the test is being run: a compliance requirement, a customer security review, a product launch or a concern about a specific system. Senior management approves the test in writing, which NIST SP 800-115 places in the planning phase. Testing has not started at this point, and no traffic should reach the client's systems. The output is a signed statement of goals and authority that names who approved the work.
Agree the rules of engagement
The client and the tester document the rules that govern the work. NIST SP 800-115 provides a rules of engagement template in Appendix B, which is a useful starting point, though NIST does not endorse one methodology over another, so the parties should record which methodology they follow and why. The rules cover permitted techniques, testing windows, contacts for emergencies and the procedure for stopping a test. The output is a signed rules of engagement document that both sides can point to if a question arises during testing.
Define targets, environments and accounts
The scope statement lists the systems in and out of testing: IP ranges, domains, applications, APIs, cloud accounts, and the environments they run in, such as production or a staging copy. It also records which test accounts and roles the tester will use, and at what privilege level, and whether the test starts from outside the network or from a user position inside it. The knowledge level, black, grey or white box, is set here, using the PCI SSC definitions. The output is a target list that the client signs off, with every exclusion named.
Share information and confirm testing windows
The client provides the information the tester needs for the agreed knowledge level, such as architecture diagrams, asset lists, network segmentation details and hosting provider rules where they apply. The parties then fix the testing windows, the people who will be notified in advance and whether the internal security team knows about the test. NIST notes that overt testing, carried out with the knowledge of IT staff, is less expensive and carries less risk than covert testing. The output is a shared information register and a confirmed schedule.
Test within the agreed boundaries
The discovery and attack phases run inside the rules of engagement. Discovery maps the target and identifies the potential weaknesses, and the attack phase tests whether those weaknesses can be used to defeat security controls, with the tester recording each action and staying within the scope. Any activity that falls outside scope, or that threatens availability, is raised with the client's contact before it continues. The output is a log of testing activity and any scope changes, each approved in writing.
Report against the agreed scope
In the reporting phase, the tester writes up the results against the scope, methodology and limitations that were agreed earlier. The PCI SSC report outline expects a statement of scope, a statement of methodology, a statement of limitations and a list of the environment clean-up performed. Findings should show how severity was derived. The client should check that the report covers every target on the signed list and explains any target that was not tested. The output is a report the client can take to its auditor or customer.
Retest the fixes against the original scope
After remediation, the tester checks that the corrected findings no longer present the original risk, and the report records which findings are closed and which remain open. PCI DSS requirement 11.4.4 requires exploitable vulnerabilities to be corrected and the testing repeated to verify the corrections. The retest should use the same scope and rules of engagement where possible, and remediation that happens long after the original test may need a new engagement. The output is a retest report that documents each closed finding.

Choosing black, grey or white box for your scope

Black box testing starts with no information about the network or applications beyond what an attacker could find on their own. PCI SSC's Penetration Testing Guidance (Information Supplement v1.1, September 2017) defines it as testing where no information is provided. This approach tests how exposed your organization looks from outside, but it spends much of the engagement on discovery that a client could have shared, so the scope document is short and the discovery effort is high. The same guidance notes that a black box assessment may require more time, money and resources for the deliverables to meet PCI DSS requirements.

Scope document: Lists the external target boundaries, such as domains or address ranges you own, and the rules for what is off limits, but few system details.
Information you share: Authorization letter, emergency contacts, testing window and any third-party hosts that must be excluded. You may share nothing about internal design.
Effort profile: Most time goes to reconnaissance and identifying what is reachable, which can raise cost for the same depth of findings.
Coverage limits: Internal logic, role models and configuration details stay hidden, so some weaknesses will not be found.
Where it fits: Useful when the question is how an outsider sees you, not whether a known application is sound.

Before choosing this level, confirm with the provider how it will meet the deliverables your auditor expects.

Scope gaps that hide the most important weaknesses

This table lists five scoping gaps that most often leave high-risk areas untested, what each looks like in a scope document, why it matters for compliance or risk, and how to close it. Use it as a checklist when reviewing a draft scope before signing. Each gap is a category, so confirm the specifics against your own environment and your assessor's expectations.

Scoping gap	What it looks like	Why it matters and how to close it in the scope document
Missing internal segments	Scope lists external addresses or one application tier, while internal subnets, management networks or segments that hold cardholder or sensitive data are absent	Segmentation claims depend on these zones being tested. List every internal segment in scope or explicitly exclude it with a documented reason and a segmentation test plan for PCI DSS-relevant boundaries.
Untested payment or authentication flows	The scope names a host or application but not the login, password reset, MFA enrollment, checkout or payment callback paths that users actually take	Compliance frameworks single out these flows, and attackers target them. Name each flow in the scope, including the roles and transactions that must be exercised end to end.
Unlisted third-party integrations	Identity providers, payment processors, webhooks, email services or data feeds connected to the application are not mentioned in the scope or the architecture diagram	Weaknesses often sit in the connection points. Inventory each integration, state whether it is in scope, and record who owns the third party and what written authorization is needed to test it.
Shared accounts with unclear roles	Test credentials are described as a single generic user, or roles such as administrator, support agent and customer are not defined with their permissions	Role-based access flaws are only found when each role is tested. Specify every account or role to be provided, its privileges, who owns it, and whether it will be created for the test and removed afterward.
Cloud or SaaS components outside the boundary	Managed databases, identity services, object storage, Kubernetes clusters or SaaS tools that the system depends on are assumed to be someone else's problem and left undefined	Shared responsibility means the client still owns configuration and data flows. Mark each cloud account, cluster or SaaS tenant as in scope, out of scope, or handled under the provider's published testing rules, and confirm the provider's policy before testing.

What rules of engagement must say before testing starts

The rules of engagement are the written agreement that turns a scope into permitted activity. Before any testing starts, they should fix the testing window, the source addresses the testers will use, emergency contacts reachable at the time of testing, and the stop conditions that halt work immediately, such as service degradation or discovery of data the tester was not expected to reach. NIST's planning phase in *NIST SP 800-115* treats these rules, management approval and testing goals as things to document before any testing occurs, and the agreement should name who on the client side can change them mid-test.

The agreement must also say how production data will be handled. Decide whether testers may access live customer records or only prove access with test accounts, how any sensitive data encountered will be recorded and destroyed, and whether the security operations team will be notified in advance. That last decision matters: NIST notes that *overt* testing, carried out with the knowledge of IT staff, is less expensive, carries less risk and is used more often than *covert* testing, which is slower and costlier because of its stealth requirements. Choose overt or covert deliberately and write the choice into the agreement, since it changes how alerts are interpreted and how much of the test runs unseen.

Before signing, confirm two operational facts yourself: that change freezes do not overlap the window, and that current, restorable backups exist for every in-scope system. Then make sure the agreement is signed by someone with authority to accept the risk of testing, typically an executive who owns the systems, not only the engagement sponsor. An unsigned or underauthorized agreement leaves the tester exposed and the client without a defensible record if an outage or incident occurs during testing.

Scope decisions that move cost and duration

Each scope choice below changes the number of hours a tester spends and how long the engagement runs. PCI SSC contrasts vulnerability scans, which take seconds to minutes per host, with penetration tests, which may last days or weeks depending on scope. The cards cover the decisions buyers make early, so the written scope can be priced and checked against the goal.

Number of targets and applications

Each external address, host, application and API adds reconnaissance, setup and manual validation work. Testers price by what they must examine, not by how many addresses appear in a list. Ask which hosts are live, which are retired and which share code or infrastructure. Grouping similar targets, such as several instances of one application built from the same codebase, can cut effort without dropping coverage, if the grouping is written down and the tester agrees to it.

Roles and account types

Testing one user role is less work than testing several roles with different permissions, because each role needs its own access paths checked for privilege escalation and broken access control. Decide which roles matter for the business risk, such as customer, administrator and service account, and whether the tester receives valid credentials for each. Every additional role should appear in the scope document with its purpose.

Production, staging or both

Testing production gives the most accurate picture but carries operational risk and needs tighter testing windows and rollback plans. Staging is usually cheaper to test and safer to break, but it only reflects production if configuration, data flows and integrations match. Testing both doubles setup and reporting work. Ask the provider how each environment will be verified and whether differences will be documented as limitations.

Test depth and manual work

Depth is the amount of manual validation after automated discovery. A deeper test follows attack paths across systems, chains weaknesses and proves impact, which takes more tester time. A shallower test confirms the most likely issues. OWASP ASVS notes that running an automated tool without thorough testing is insufficient for verification. Ask what share of the hours is manual, which techniques are used and what each finding will prove.

Knowledge level

Black-box testing gives the tester no information, while white-box testing gives full details of the network and applications. PCI SSC states that black-box assessments may need more time, money and resources to meet PCI DSS deliverables, and that PCI DSS tests are typically white-box or grey-box for more accurate results. Decide what the tester receives, such as architecture diagrams, API documentation and test accounts, and write that list into the scope.

Retest and reporting needs

A retest verifies that fixes close the original risk, and PCI SSC advises that remediation long after the original test may require a new engagement. Agree now whether retests are included, how many rounds apply and the window in which they must happen. Report requirements also change effort, for example a segmentation section, a summary for auditors or a findings register in a specific format. Name the audience for each deliverable before work starts.

How compliance requirements shape the scope

This table compares what PCI DSS and CIS Controls expect of penetration test scope, timing and remediation follow-up. Read each row as a question to ask: does the test cover the systems the framework names, at the frequency it requires? The main takeaway is that the assessor or customer will check whether your tested scope matches the cardholder data environment or the systems you state.

Requirement	What it expects of scope	Evidence an assessor will look for
PCI DSS 11.4.2 and 11.4.3	Internal and external penetration tests at least every 12 months and after significant change, covering the in-scope environment	Dated test reports showing internal and external coverage, plus records linking tests to significant changes
PCI DSS 11.4.4	Exploitable vulnerabilities corrected by risk ranking, then testing repeated to verify the fixes	Remediation records tied to findings, and a retest report confirming the corrections
PCI DSS segmentation and in-scope systems	Segmentation controls tested if they are used to reduce scope, with the cardholder data environment defined before testing	A documented scope statement, a data flow or system inventory, and segmentation test results
CIS Controls 18.2	External penetration tests at least annually, covering the internet-facing estate you state as in scope	Annual external report listing addresses and services tested, dated within the last twelve months
CIS Controls 18.5	Internal penetration tests at least annually, covering the internal networks and systems you state as in scope	Internal test report with network ranges, segments and exclusions stated in the scope section
Customer security reviews	Scope matches the systems, data and environments named in the contract or questionnaire	Scope statement that maps tested assets to the customer's stated services and data types

What the client must provide before the scope is final

Before a tester can write a scope, the client has to supply a working set of facts about what exists and who may touch it. The core items are an asset inventory, IP ranges and domain names, cloud account identifiers for each subscription or project in scope, architecture or data flow diagrams showing where sensitive data moves, and a named test user account for each role the application or platform defines, such as anonymous, standard customer, administrator and any partner or API role. Ask for the emergency and escalation contacts who can stop a test within minutes, the change freeze dates when no production changes may land, and written consent from any third-party provider whose hosting, SaaS or managed service sits inside the target. Cloud and SaaS providers often publish their own testing rules, so confirm which ones apply before scheduling.

Incomplete inputs do not stop a test. They change its shape. When an asset is missing from the inventory, the tester either leaves it out, which narrows coverage, or adds time to find it, which raises cost and may push the engagement past the agreed window. When role accounts are absent, authorization testing is limited to what can be seen from one identity, and that gap has to be recorded. PCI SSC's suggested report outline includes a statement of limitations, and this is where unresolved inputs belong. A reader who sees that the test ran without a partner role account, or without a diagram of a segment that was later found to matter, can judge the findings correctly. A limitation written in advance is far better than one discovered after delivery, because an auditor will read the report against the scope signed at the start.

Treat this list as a gate. Ask the provider to confirm in writing which items are needed before the kickoff date, who on your side owns each one, and what happens if an item arrives late or changes during testing. Record any asset that cannot be confirmed as in or out of scope, and decide whether to include it, exclude it with a documented reason or test it in a later phase. Agree how test accounts are created, locked and removed afterward, and confirm that the accounts carry only the access the role needs. These decisions are cheaper to make now than during an active engagement, and they give your auditor a traceable record of how the scope was set.

What a scoped test delivers and how it reads for auditors

What must a penetration test report contain?

A useful report follows the outline PCI SSC suggests for penetration test reports: an executive summary, a statement of scope, a statement of methodology, a statement of limitations, a testing narrative, segmentation test results where relevant, the findings, the tools used and the environment clean-up. Each finding should carry references such as CVE and CWE identifiers so engineers and auditors can trace it to a known weakness category. Agree this structure in the statement of work so the report is written against the scope you approved, not improvised at the end.

Scope and methodology statements that match the agreed rules of engagement
Limitations that state what was excluded or could not be tested
Findings with evidence, impact and remediation advice
Clean-up notes confirming what test accounts or data were removed

How is the severity of a finding decided?

Severity should be derived from a recognized scoring method, typically CVSS, and the report should explain how the score was reached. PCI SSC guidance says that when a score is adjusted for your environment, the reasoning must be traceable, for example why an internet-facing system is rated higher than the same flaw behind strong access controls. Ask the provider to show base scores, the environmental adjustments and the justification for each one. Your own risk ranking then decides remediation order, which is the basis PCI DSS requirement 11.4.4 uses for correcting exploitable findings.

What does a retest produce and when is it needed?

A retest checks whether the fixes for the original findings actually reduce the risk, and it produces a report that records each finding as closed, partly remediated or still open, with the evidence used to decide. PCI SSC guidance says testers should retest once remediation is complete, and PCI DSS requirement 11.4.4 expects exploitable findings to be corrected and the testing repeated to verify the correction. If remediation drags on long after the original test, the provider may advise a new engagement instead. Confirm retest terms, including how many rounds are covered, in writing before testing starts.

Will the engagement include a letter for a customer or auditor?

The test report itself is the primary evidence for an assessor, and a separate summary letter is only a yes if the statement of work names it as a deliverable. DeployOpen prepares systems, controls and evidence for compliance assessments, including test reports and retest records. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those judgments, so ask your assessor which documents they will accept and agree the format of any summary with the provider before work begins.

How do auditors read a penetration test report?

Auditors usually check that the test was in scope, performed by a qualified tester using a stated methodology, and that findings were ranked, fixed and retested. They look for the statement of scope to cover the systems in their assessment, the limitations section to be honest about gaps, and the retest record to show closure. Reports built on a recognized methodology, such as the approach in NIST SP 800-115, are easier to defend than a list of tool output. Ask your assessor early which elements they require so you can confirm them in the scope.

Can a scan alone satisfy a penetration testing requirement?

No. PCI SSC guidance distinguishes vulnerability scans, which identify and rank weaknesses mostly with automated tools, from penetration tests, which are a mainly manual process that tries to exploit weaknesses to defeat security features. OWASP ASVS also states that running an automated tool without thorough testing is insufficient for verification. Your scoped test should describe manual work, the depth of testing per target and the tools used as support, so the report shows more than scanner output.

Can we write the report and retest ourselves to save money?

Your team can prepare evidence, track remediation and run its own checks, but an independent assessor will expect the penetration test and its report to come from a tester outside the team that built or operates the system. Decide early which parts your staff will own, such as remediation tracking and evidence collection, and which parts the provider will own, such as testing and the findings report. Confirm in writing who signs off on the final report and who your assessor will accept as the tester.

How scope differs across external, internal, cloud and application targets

External scope starts with an inventory of what is reachable from the internet. Ownership of IP addresses, domain names and hosted services is often spread across teams, business units and third parties, so the scope document should be built from the client's own asset records and checked against what is actually exposed. Testing is usually black-box or grey-box for external work, and the client should decide in advance which addresses are in bounds and which belong to a hosting or SaaS provider whose terms restrict testing.

Address ranges and hostnames: List each IP address or CIDR block and each domain or subdomain by name, with the owner of each.
Third-party hosted assets: Identify systems run by cloud or SaaS providers and confirm whether the provider permits testing or requires its own approval.
Accounts provided: Usually none for a black-box external test. For grey-box work, agree which low-privilege accounts or VPN credentials the client will supply.
Excluded systems: Name fragile devices, production payment links or systems that must not be probed, and state any allowed time windows.
Notification contacts: Name the person who can halt testing if an external service degrades.

Confirm that the scope matches your external asset inventory and that you have authority over every address listed.

What to ask a provider to confirm in the scope

A scope document is only as good as the provider's process for writing it, changing it and testing within it. The cards below cover the questions that show whether a provider will hold to the agreed scope, disclose how it tests and bring the right people to the work. Ask for written answers before signing.

How scope and approval are documented

Ask who signs off the scope for your organization and what the tester records as management approval before any testing starts. NIST SP 800-115 places rules, management approval and testing goals in a planning phase where no testing occurs. A provider that cannot show this written record before the first packet is sent has skipped the step your auditor will ask about.

Written and signed scope changes

Confirm that any change to targets, accounts, dates or test types is written, approved by a named person on your side and recorded in the final report. Ask what happens when a tester finds that a target belongs to a third party or a cloud provider's rules apply. Verbal scope changes are the most common source of disputed findings.

Handling out-of-scope discoveries

Testers often find systems that were not listed, such as forgotten hosts or exposed admin panels. Ask the provider to stop, notify a named contact within an agreed period and wait for written direction before testing further. Also ask how it will record what it saw and whether it will delete any data it collected.

Methodology disclosure

Ask which methodology the provider follows and how it combines them, since NIST does not endorse one methodology over another. OWASP ASVS expects testing methods to be disclosed in the report, and insufficient testing is not met by running an automated tool alone. Request the methodology document and check that the report will name the methods used.

Tester qualifications and accreditation

Ask who will do the work, what they have done in comparable environments and which certifications they hold. CREST accreditation of the company and certifications of individuals are useful indicators to check. PCI SSC says it does not validate or endorse certifications and that they alone do not establish experience, so also request references and sample work.

How retest scope is set

Confirm in the scope whether retesting is included, how many rounds apply and which findings will be retested. PCI SSC advises retesting once remediation is complete and notes that remediation long after the original test may need a new engagement. Ask the provider to define the time limit for retesting in writing.

Common questions about scoping a penetration test

How long does scoping a penetration test take?

Scoping time depends on how many systems are involved, how well they are documented and how many people must approve the boundaries. A single public web application with clear ownership is far quicker to scope than a hybrid estate spanning several cloud accounts, a legacy network and third-party hosted services. The main drivers are the number of targets and environments, whether an asset inventory exists, how many business owners must sign off, and whether legal or third-party consent is needed. Ask any provider to state in writing what scoping involves and what it needs from you before the quote is final.

Can we define the penetration test scope ourselves?

Yes, your team can draft the initial scope, and most engagements benefit from it. Internal staff know which systems matter, which data is regulated and which changes are planned. The draft becomes reliable when the tester reviews it for gaps, such as shared components, identity providers or management interfaces that are easy to overlook. NIST SP 800-115 treats planning as the phase where rules, management approval and testing goals are documented before any testing occurs, so the written scope should record who approved each target and why it was included. Expect the provider to challenge the draft rather than simply accept it.

What does the penetration test need from our team?

The engagement needs named contacts with authority to approve scope and testing windows, technical staff who can explain architecture and access, and a point of contact who can respond during testing. Testers typically need a list of in-scope hosts, domains and applications, account details for each role to be tested, and any known exclusions. Confirm whether your team is expected to provide test accounts, network access, VPN details or source code. Also agree how urgent findings will be communicated and who can stop testing if a production service is affected. Missing contacts and unclear ownership are common causes of delay.

Can an automated scan replace penetration test scoping?

No. A vulnerability scan can help you build an asset inventory, but it does not define what a penetration test should cover or what the tester is allowed to attempt. PCI SSC's guidance distinguishes vulnerability scans, which identify and rank issues mostly through automated tools, from penetration tests, which are a mainly manual process that exploits vulnerabilities to test whether security features can be defeated. Scan results are useful inputs to scoping, but the test goals, roles, exclusions and rules of engagement still need human agreement. Ask providers how their scoping work differs from a scan configuration exercise.

How do we scope cloud or third-party systems in a penetration test?

Start by separating what you own and control from what a provider operates. Cloud platforms and many SaaS services publish their own testing rules, which may limit the types of tests allowed, require prior notice or prohibit testing certain services. Under the shared responsibility model, your team may be able to test your applications and configurations but not the provider's underlying infrastructure. For third-party systems, confirm written permission from the owner before scope is agreed, and record any requirement for the third party to be informed. Scope these systems explicitly, including the boundary where your responsibility ends, so findings do not depend on assumptions.

How do scope changes work after a penetration test starts?

Scope changes should be handled as written amendments, not informal requests made during testing. Typical triggers include discovering a new host that belongs to the client, a system turning out to be owned by a third party, or a finding that suggests a wider exposure. Agree in advance who can authorize a change, how quickly it must be documented, and how it affects the schedule and cost. A change to a scope that has already been priced usually changes the effort, and the report must state any change in scope and any limitations it introduced. Retesting after remediation may also need its own scope agreement.

What drives the effort to scope a penetration test?

Effort rises with the number of targets, the number of environments (production, staging, development), and the number of distinct roles or accounts that must be tested. Knowledge level matters too. PCI SSC notes that black-box work may need more time and resources to meet PCI DSS deliverables, while white-box and grey-box tests rely on information that must be gathered and validated during scoping. Compliance deadlines, regulatory requirements and the need for segmentation testing also add work. Ask any provider which of these factors apply to your estate and how each one changes the planning effort.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that runs security testing for self-hosted open-source platforms and other targets inside the client's own infrastructure. We agree the scope in writing before any testing starts, then document how the work is run, what is delivered and how retesting fits the client's remediation plan.

How we scope

Written scope names the targets, environments, test accounts and roles before any testing begins
Exclusions, testing windows and emergency contacts are recorded in the rules of engagement
Engagements are fixed-scope, with deliverables and timelines agreed in writing up front

How we build

Testers work from the agreed information set, such as black, grey or white box access as scoped
Manual testing is the core of the work, with automated tools used to support it, not replace it
Testing methodology is stated in the report so the client and its auditor can see how it was done

How we hand over

Reports include scope, methodology, limitations and findings with severity reasoning and evidence
Remediation advice is written for the engineers who must fix each finding, with clear priorities
Environment clean-up and any test data removal are confirmed in writing at handover

How we support

Retesting of closed findings is scoped separately so the client can confirm each fix works
Ongoing support, upgrades and continuous testing are available as retainers after the initial test
Ask us to confirm how the report will be used with your auditor or customer before scoping starts