Penetration Test Scoping Generator
Answer a short questionnaire and generate a complete penetration test scope and RFP you can hand to vendors. Choose your target types, a black, grey or white-box methodology, the environment and compliance driver, set the rules of engagement, and pick the questions to ask each software penetration testing provider. A one-click AWS preset fills in cloud-specific scope. Copy or download the result as Markdown — everything runs in your browser and nothing is uploaded.
Assembled entirely in your browser — nothing is uploaded. The questionnaire and the generated document never leave your device; the tool makes no network calls and holds no credentials.
What this tool is
- A free, in-browser generator that turns a short questionnaire into a complete penetration test scope and RFP you can copy or download as Markdown.
- Pick target types (web app, API, external and internal network, AWS cloud, mobile, wireless, social engineering), a black/grey/white-box methodology, environments, and the compliance driver (PCI DSS, SOC 2, ISO 27001 or none).
- Captures the rules of engagement that protect you: testing window, rate limits, prohibited actions, out-of-band handling of critical findings, and an authorisation sign-off block.
- Includes the questions worth asking a software penetration testing vendor — methodology, tester certifications (OSCP, CREST), retest policy, report format and data handling — so you can compare bids fairly.
- An AWS preset pre-fills cloud-specific scope (IAM, S3, security groups and an assumed-breach test). Everything runs client-side; nothing you type is ever uploaded.
What a penetration test scope is
A penetration test scope is the written agreement of exactly what a tester may and may not touch. It names the systems that are in scope — specific URLs, hostnames, IP ranges, application identifiers or cloud accounts — and makes clear that everything else is out of scope. It fixes the methodology, the environment, the testing window, the rate limits and the prohibited actions, and it records who authorised the work. Everything downstream — the price, the depth of testing, the usefulness of the report and whether it stands up as compliance evidence — flows from this document. A penetration test RFP (request for proposal) is the same scope packaged with the questions you want each provider to answer, so you can compare bids on equal terms.
Why scoping decides cost and quality
Pen testing is priced by effort, so the scope is the biggest lever on both what you pay and what you get back. A vague scope forces providers to pad estimates against the unknown, yields quotes you cannot compare, and tends to produce a shallow test that misses the systems you most cared about. A precise scope lets testers spend their hours on depth instead of guessing at boundaries, lets you line up quotes like for like, and makes the final report map directly onto the decisions and audits it needs to support.
Black, grey and white box
- Black box. No prior knowledge, no credentials, no docs — a tester starting where an external attacker would. Most realistic for perimeter exposure, but the least efficient use of a fixed budget because so much time goes on reconnaissance.
- Grey box. Limited information plus standard user credentials — the view of a compromised account or a malicious insider. The common balance of realism and coverage, and the right default for most application and cloud work.
- White box. Full information — architecture, source where relevant, admin access. Maximises depth and coverage per hour; best when you want a thorough review of one specific application rather than a realistic attack simulation.
Rules of engagement
The rules of engagement are the operational guardrails that keep a test safe and lawful. They set the authorised testing window and time zone, the rate and intensity limits that protect production stability, and the explicitly prohibited actions — denial-of-service, destroying or exfiltrating real data, physical intrusion, or pivoting to anything outside scope. They name the points of contact and an out-of-band channel for urgent issues, define how a critical, actively-exploitable finding is escalated immediately rather than held for the report, and require a written authorisation sign-off from the owner of the assets being tested.
Use with care: the document this tool produces is a template, not legal or contractual advice. Review it with qualified counsel and your chosen tester, and obtain written authorisation from the owner of every in-scope asset, before any testing begins. Never test systems you do not own or operate without explicit, documented permission.
Frequently asked questions
What is a penetration test scope?
A penetration test scope is the written definition of exactly what a tester may and may not do: which systems are in scope (specific URLs, hostnames, IP ranges, apps or cloud accounts), which are explicitly out of scope, the methodology (black, grey or white box), the environment (production, staging or development), the testing window and rate limits, the prohibited actions, and how findings are reported and the engagement is authorised. A clear scope is what turns an informal "have a look at our app" into a safe, repeatable engagement whose results you can act on and defend to an auditor.
Why does scoping decide the cost and quality of a pen test?
Penetration testing is sold by effort — testing days plus reporting — so the scope is the single biggest driver of both price and value. A scope that is too vague forces providers to pad their estimates against uncertainty, produces bids you cannot compare, and often leads to a shallow test that misses the systems you actually cared about. A scope that is precise about targets, methodology, credentials and objectives lets testers spend their hours on depth rather than discovery, lets you compare quotes like for like, and makes the final report map cleanly onto decisions and compliance evidence. Getting the scope right before you talk to vendors is the highest-leverage thing a buyer can do.
What is the difference between black box, grey box and white box testing?
They describe how much the tester knows at the start. Black box means no prior knowledge, no credentials and no documentation — it simulates an external attacker starting from zero and is the most realistic for perimeter exposure, but the least efficient use of a fixed budget because time is spent on reconnaissance. Grey box gives the tester limited information and standard user-level credentials, simulating a compromised account or malicious insider; it is the usual balance of realism and coverage for most engagements. White box provides full information — architecture, source code where relevant and administrative access — which maximises depth and coverage per hour and suits a thorough review of a specific application. Many engagements combine them: black box against the perimeter, grey or white box against the application behind it.
What are rules of engagement, and why do they matter?
Rules of engagement are the operational guardrails that keep a test safe and lawful: the authorised testing window and time zone, rate and intensity limits that protect production stability, explicitly prohibited actions (such as denial-of-service, destroying or exfiltrating real data, physical intrusion, or pivoting outside scope), the communication channels and points of contact, how sensitive findings are escalated out-of-band, and a written authorisation sign-off from the owner of the assets being tested. They matter because unauthorised testing can be unlawful and because a test without guardrails can cause an outage or data loss — the rules of engagement are what let both sides proceed with confidence.
How should AWS or cloud penetration testing be scoped differently?
Cloud testing is less about breaking a network perimeter and more about configuration and identity. For AWS, a good scope names the account IDs and regions, and focuses on IAM roles and policies (over-permissive trust, privilege escalation paths), resource exposure (public S3 buckets, open security groups, internet-facing load balancers) and an assumed-breach scenario where the tester is given a set of standard credentials or a compromised workload and asked how far they can get. You should also confirm what your cloud provider permits — most now allow customer-driven testing of your own resources without prior approval, but certain disruptive tests and provider-managed services remain off-limits. This tool’s AWS preset pre-fills those cloud-specific scope items so you can start from a sensible baseline.