The most common objective in a penetration testing scope of work is also one of the weakest: "ensure the application is secure." This objective is not testable. No test can confirm that a system is secure: it can only confirm that specific vulnerabilities were not found within a specific scope in a specific testing window. An objective that is not testable creates disputes at report delivery.
A well-written scope of work produces two things before testing begins: a shared understanding of what success looks like between the ANZ organisation and the testing provider, and a document that auditors can reference as evidence that the testing was structured, authorised, and bounded. The scope of work is broader than technical scope and different from the rules of engagement, the master services agreement, the NDA, the written authorisation letter, and the final report. Each is a separate document. Most ANZ organisations conflate several of these into a single document, which creates ambiguity that shows up at invoicing or at audit.
Element One: A Testable Objective
Scope is an assurance definition, not merely an asset count. It should start with the business or compliance objective, then map the system boundary before counting assets.
A testable objective names what an attacker starting from a defined position would need to do to succeed, and what the test will confirm. For example: "confirm that an authenticated low-privilege user cannot escalate to admin access through the API layer" is testable. "Ensure the platform is secure" is not.
Compliance-Driven Objectives
For ANZ compliance engagements, the testable objective should also name the framework the test needs to satisfy. "Produce penetration test evidence for the annual APRA CPS 234 control testing obligation" is a testable objective. It defines the evidence format the report must produce. A provider who does not know the compliance framework at the scoping stage will produce a report that does not satisfy it.
Element Two: A Complete Asset Inventory with Explicit Exclusions
Before testing begins, the tester should receive the organisation's current asset inventory: IP space, domain registrations, cloud account structure, known internet-facing services, and identity infrastructure overview.
APIs, user roles, and administrative functions should never be assumed to be included by default. Testing depth and scope breadth must be balanced explicitly. A web application test that does not name the API layer as in-scope will produce a report that covers the front-end interface. It will not cover the API layer that an attacker would target. The provider has met the scope. The buyer has not tested what matters.
Exclusions Matter as Much as In-Scope Assets
The exclusion list is as important as the in-scope list. Common exclusions that must be documented explicitly include:
- Subdomains and environments not in the approved asset inventory
- Third-party SaaS or infrastructure hosted by upstream suppliers
- Denial-of-service (DoS) and volumetric attack testing
- Social engineering of internal staff, executives, or customers
- Destructive testing such as live ransomware or wiper simulation
For how the asset inventory at the scoping stage connects to the testing evidence that auditors check in the compliance cycle, the guide to continuous penetration testing for SOC 2 and ISO 27001 compliance covers how scope documentation functions as the first artefact in the evidence chain that regulators and auditors follow.
Element Three: Rules of Engagement
The rules of engagement is a separate document from the scope that defines testing technique authorisation: whether social engineering is in scope, whether denial-of-service is permitted, whether destructive testing is explicitly authorised or prohibited, and whether password cracking using cloud compute resources is permitted.
The rules of engagement should also name the testing window (authorised hours for active testing), the escalation procedure if a zero-day or active third-party breach is discovered during testing, and the emergency contact chain with direct phone numbers for testing hours.
For ANZ organisations with production systems in scope, the rules of engagement must also document which systems require care during testing (payment processors, production databases, critical APIs) and what the stop procedure is if testing causes unexpected effects. APRA CPS 234 requires exclusion documentation with a business justification for systems where downtime is not acceptable. That documentation lives in the rules of engagement, not the scope of work.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
Element Five: Deliverables and Acceptance Criteria
Deliverables should be defined before testing begins, not negotiated at report delivery. A scope of work that names deliverables vaguely ("a penetration testing report") will receive different outputs from different providers. Specifically name: the report format and sections required, whether an executive summary is included, whether compliance framework mapping is required (and to which framework), whether a retest engagement is included or priced separately, and what the acceptance criteria for the final report are.
For ANZ compliance engagements, the acceptance criteria should confirm that the report satisfies the specific framework evidence requirement. An APRA CPS 234 engagement should specify evidence for the systematic control testing documentation that paragraph 27 requires. A SOC 2 engagement should specify coverage of systems within the Trust Services Criteria boundary.
The guide to what happens after a penetration test covers the specific artefacts auditors check after the initial report is delivered.
Book a scoping consultation with Capture The Bug to review your draft scope of work before sending it to providers, or to confirm that the scope you have received produces the ANZ compliance evidence your framework requires.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Frequently Asked Questions
What should a penetration testing scope of work include for ANZ organisations?
A complete ANZ penetration testing SOW includes five elements: a testable objective that names the business or compliance goal (not "ensure the application is secure"), a complete asset inventory with explicit exclusions, rules of engagement covering testing technique authorisation, testing window, escalation procedures, and stop conditions, signed written authorisation from an individual with legal authority to authorise the test, and deliverables and acceptance criteria that specify report format, compliance framework mapping, retest terms, and what constitutes acceptance. Each element is a separate document or section. Conflating them creates disputes at report delivery.
What is the difference between a scope of work and rules of engagement in a penetration test?
The scope of work defines the objective, asset boundary, exclusions, deliverables, timeline, and acceptance criteria. The rules of engagement is a separate document that defines testing technique authorisation: what is permitted, what is prohibited, the testing window, escalation procedures, the emergency contact chain, and stop conditions. The SOW tells the provider what to test. The ROE tells the provider how to test it and when to stop. Both should be signed before testing begins. APRA CPS 234 requires exclusion documentation with a business justification for systems where downtime is not acceptable. This documentation belongs in the rules of engagement.
What makes a penetration testing objective testable?
A testable objective names what an attacker starting from a defined position would need to do to succeed, and what the test will confirm. "Confirm that an authenticated low-privilege user cannot escalate to admin access through the API layer" is testable. "Ensure the platform is secure" is not. For ANZ compliance engagements, a testable objective also names the framework the test must satisfy: "produce penetration test evidence for the annual APRA CPS 234 control testing obligation" defines both the testing goal and the evidence format. A provider who does not know the compliance framework at scoping will produce a report that does not satisfy it.
Do APIs and user roles need to be explicitly named in the scope?
Yes. APIs, user roles, and administrative functions are never assumed to be in scope by default. A web application scope of work that does not explicitly name the API layer as in-scope will produce a report covering the front-end interface only. Similarly, each authenticated user role requires its own test pass. A SaaS platform with admin, member, billing, and staff roles needs all four roles named in scope to produce a test that validates access control for each role. If roles or APIs are not named, the provider has met the scope as written, even if the most critical attack surfaces were never tested.
How does the scope of work affect the compliance evidence a penetration test produces?
The scope of work is the first artefact in the compliance evidence chain. APRA CPS 234 supervisors, SOC 2 auditors, and ISO 27001 certification bodies review the scope to confirm that the systems they care about were tested, that the methodology was structured and authorised, and that the deliverables include the evidence format they require. A vague scope that does not name compliance framework mapping as a deliverable will produce a report that may not satisfy the auditor's evidence requirements, regardless of how thorough the testing was.
