Penetration Testing Scoping Questionnaire: Free Template

A scoping questionnaire exists to answer one question before you quote: how big is this piece of work, really? The useful questions are the ones whose answers move the estimate, and most of those depend on the kind of test. A web application and an internal network are sized by completely different things.

This guide gives the questions that matter, grouped by test type, with a note on why each one changes the number. At the end there is a table that turns answers into rough day counts, and a free Word template you can send or fill in yourself. The reasoning behind the whole approach is in scoping a penetration test without guessing.

How to use it

Complete the “every engagement” questions for all work, then only the sections that match the test types in scope. Treat the day ranges at the end as a starting point for a conversation, never as a quote: they assume grey box testing with accounts and documentation supplied, and reporting adds to every figure. The answers become the scope of an engagement you run in Pental.

Every engagement

These set the objective, the window, the environment and the constraints, whatever the test type.

• What do you want to learn? A compliance tick and a genuine attempt to find what is broken are different engagements, and they are scoped differently.
• Is there a compliance driver? PCI DSS, ISO 27001, SOC 2, DORA or a client’s own security questionnaire each bring requirements that shape coverage and the report.
• Production or a staging copy? If staging, how does it differ? Different data, stubbed integrations and a firewall that is on in one and off in the other all change what the test means.
• Black box, grey box or white box? Grey box finds more per day, because the days go on testing rather than rediscovering the architecture. Most buyers who ask for black box are paying for reconnaissance they already have the answers to.
• Who can sign the authorisation, and do you own every target? This decides whether the test can start on time, and whether third-party permissions are needed. It feeds the authorisation letter.

Web application

Roles and distinct functions drive the days, not page count. An application with forty pages and six real workflows is smaller than it looks.

• How many distinct user roles? Every extra role multiplies the authorisation work, because each pair of roles is a boundary someone has to attempt to cross. One role is a fraction of the work of four.
• Does it change state or only read? Something that moves money, provisions access or calls other systems is slower to test than a read-only screen, and usually where the findings are.
• Is it multi-tenant? If one customer’s data must stay invisible to another, that boundary is the most valuable thing to test and the first thing lost when a scope is compressed.
• Bespoke or framework authentication? A familiar library is understood in an hour. A hand-rolled session mechanism is where the days go.
• How many distinct functions, not pages? Count real workflows and input surfaces, because that is what the testing days are spent on.

API

An API without a specification is slower, because the surface has to be discovered before it can be tested.

• How many endpoints, and is there a current specification? A specification turns discovery into testing. Its absence adds time, because the surface has to be mapped before it can be assessed.
• REST, GraphQL, SOAP or gRPC? The style changes the technique and the tooling.
• Are role and tenant boundaries enforced at the API itself? An API that trusts the interface in front of it is a common and serious finding, and testing for it takes accounts.
• Is the API in scope separately from any interface in front of it? It should be: the interface is not the API.

External and internal infrastructure

Infrastructure scales with the number of live hosts and services rather than with complexity, so an accurate count matters more than a description.

• How many external addresses or ranges, and how many are live? External testing is sized by what actually answers from the internet, not by the size of the range.
• How many distinct exposed services? Each is a thing to test.
• Is there an Active Directory, and how big? Domains, forests and trusts change internal work substantially. An internal test with Active Directory is a different engagement from one without.
• Assumed breach or from nothing? A supplied foothold spends the days on what an attacker does after a breach rather than on getting in.
• On-site or over a supplied device or VPN? This affects logistics and elapsed time more than effort, but it still has to be planned.

Cloud

A cloud configuration review is sized by the number of accounts, subscriptions or projects and the services in use, and the provider’s own policy sets what is permitted before anything starts.

• Which providers, and how many accounts, subscriptions or projects? This is the main driver of effort.
• Configuration review, penetration test, or both? A read-access review of the configuration and an authenticated test are different pieces of work, scoped and priced differently.
• Which major services are in use? The service list decides what the review covers.
• Have you checked the provider’s current testing policy? Some activity needs notification, and some is prohibited. See cloud penetration testing rules.

Mobile

Each platform is a separate piece of work, and the back-end behind the app is usually where the findings are.

• Which platforms, iOS, Android or both? Two platforms is close to two pieces of work.
• Will you provide builds and test accounts? Their absence adds time at the start.
• Is the back-end API in scope as well as the app? It should be scoped alongside the app, because the app is a client for it.
• Does the app handle payments, health or other sensitive data? This raises both the coverage and the care required.

Turning answers into days

The figures below are rules of thumb from practice, for sizing a conversation, not a quote. They assume grey box testing with accounts and documentation supplied. Black box adds time for discovery, and the depth behind these ranges is in how long a penetration test takes.

Reporting typically adds between a fifth and a third of the testing effort, and a retest, where included, is usually one to two days. Scheduling, access and review add elapsed time that is not testing effort, so a five-day test is rarely five days end to end.

The template

The Word template below is the whole questionnaire: the “every engagement” section, a section per test type with the questions above, and the day-count table, with placeholders for answers and short guidance notes you delete. Use it to size work before it reaches a statement of work.

Download the template (Word, 41 KB)