ToolsOffensive testing
Penetration test scope builder.
Answer the scoping questions once and send the same brief to every provider.
Runs in your browser. Nothing you enter is sent, stored or logged.
What is in scope
Counts only. Hostnames and address ranges belong in a separate annex you send once a provider is engaged.
Each distinct application with its own codebase or its own login.
Everything reachable from the internet, including anything a supplier hosts for you.
Servers, workstations and appliances inside the network, if internal testing is in the engagement.
Separate accounts or tenancies you want reviewed.
Count each platform build separately.
Only those you want exercised separately from the application in front of them.
Authentication and roles
Count the levels of access that see different things, for example a standard user, an administrator, and a customer of your customer.
Environment and authorisation
Whoever owns the systems being tested, which is not always whoever asked for the test.
Why the test is being run
Only if the contract, questionnaire or insurer actually names one.
Constraints
Hosting providers, managed service providers, a customer whose tenancy you sit in.
Scope reading
Enter what is in scope to start the brief.
Nothing is in scope yet
Enter counts above. A provider needs to know how many applications, addresses, hosts, tenants and APIs sit in the engagement before anything else matters.
The target environment is not settled
Production and a mirror are different engagements. Production restricts technique and needs a rollback contact. A mirror only produces useful findings if its configuration and data volume genuinely match.
Nobody is named as the authorising party
No provider can start without written authority from whoever owns the systems being tested. Settle this before you send the brief, because it is the item most likely to move a start date.
Why the test is happening is not stated
The driver shapes the deliverable. A contract obligation needs something a customer will accept, a pre-release check needs findings a development team can act on this sprint, and a post-incident test needs specific attention on the path that was used.
Permitted testing windows are not set
This is a scheduling question that changes what a provider can commit to. Testing restricted to outside business hours is a different piece of work from testing at any time.
Third-party hosting consent is not in hand
Anything hosted or managed by someone else needs their written agreement before testing starts. Check every target against who actually runs it.
What data sits in the target is not confirmed
It decides what handling terms the engagement letter carries and whether findings can quote records. Answer it before a provider drafts the agreement.
Credentials
Whether the test runs credentialed, who issues the accounts, at which roles, and by when. State it explicitly so unauthenticated quotes are not compared against authenticated ones.
Retest terms
Whether verification of fixes is in the price, how long the retest window stays open, and whether the retest produces an updated report you can hand to whoever asked for the test.
Escalation contact
A named person reachable during testing, the agreed condition for pausing, and the path for a critical finding that cannot wait for the report.
Report format
The deliverable you actually need. An executive summary, a technical annex, a letter a customer will accept, and whether findings have to map to a named framework.
This assembles what you entered into a document. It does not test anything, does not price the work and does not judge whether a penetration test is the right assessment for you. A provider will still ask questions this form does not.
Scoping brief
A reload clears this draft. Copy it out before you leave the page.
PENETRATION TEST SCOPE BRIEF Prepared by the requesting organisation. Vendor neutral, written to be sent to several providers unchanged. TARGETS In scope: nothing entered yet. Out of scope: web applications, the external perimeter, the internal network, cloud configuration, mobile applications, APIs tested separately from the application. Target identifiers (hostnames, address ranges, application URLs) are supplied separately. AUTHENTICATION AND ROLES Distinct roles to be tested: none stated Public self-registration: closed, accounts are provisioned by us Multi-factor authentication in the login path: no Test accounts available before the start date: no ENVIRONMENT AND AUTHORISATION Environment: not yet decided Change freeze or blackout windows: none that affect the engagement Authority to authorise testing: not yet settled WHY THE TEST IS BEING RUN Driver: not stated Framework named in the request: not yet confirmed CONSTRAINTS Permitted testing windows: not yet decided Rate limits or fragile systems: none known Third-party hosting consent: not yet checked Data in the target environment: not yet confirmed DECISIONS STILL OPEN Nothing is in scope yet. Enter counts above. A provider needs to know how many applications, addresses, hosts, tenants and APIs sit in the engagement before anything else matters. The target environment is not settled. Production and a mirror are different engagements. Production restricts technique and needs a rollback contact. A mirror only produces useful findings if its configuration and data volume genuinely match. Nobody is named as the authorising party. No provider can start without written authority from whoever owns the systems being tested. Settle this before you send the brief, because it is the item most likely to move a start date. Why the test is happening is not stated. The driver shapes the deliverable. A contract obligation needs something a customer will accept, a pre-release check needs findings a development team can act on this sprint, and a post-incident test needs specific attention on the path that was used. Permitted testing windows are not set. This is a scheduling question that changes what a provider can commit to. Testing restricted to outside business hours is a different piece of work from testing at any time. Third-party hosting consent is not in hand. Anything hosted or managed by someone else needs their written agreement before testing starts. Check every target against who actually runs it. What data sits in the target is not confirmed. It decides what handling terms the engagement letter carries and whether findings can quote records. Answer it before a provider drafts the agreement. TO BE AGREED WITH THE PROVIDER Credentials: Whether the test runs credentialed, who issues the accounts, at which roles, and by when. State it explicitly so unauthenticated quotes are not compared against authenticated ones. Retest terms: Whether verification of fixes is in the price, how long the retest window stays open, and whether the retest produces an updated report you can hand to whoever asked for the test. Escalation contact: A named person reachable during testing, the agreed condition for pausing, and the path for a critical finding that cannot wait for the report. Report format: The deliverable you actually need. An executive summary, a technical annex, a letter a customer will accept, and whether findings have to map to a named framework. This brief describes scope. It carries no budget, no duration and no expectation of findings.
What this does, and what it deliberately does not.
This builder assembles your answers into a scoping document and names the decisions still open. It does not test anything, does not price the work, does not estimate days, and cannot tell you whether a penetration test is the right assessment for what you are worried about. A provider will still ask questions this form does not.
Want the scope read by the people who would run the test?
Australia-wide, from our Brisbane head office. Someone will contact you as soon as possible.