How to write a penetration test scope

Quotes that differ by a factor of five usually differ because each firm guessed at a different engagement. Write the scope once, send the same document to everyone, and the spread collapses to something you can actually compare.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

A usable penetration test scope fits on two pages and answers eight questions: what the assets are, how many user roles exist, which environment gets tested, who the tester is allowed to be, when testing may happen, what is explicitly out, what you get at the end, and who to phone at two in the morning. Firms quote from those eight facts. If you supply them, three quotes for the same work land within about 30 percent of each other. If you supply a domain name and the sentence "we need a pentest for SOC 2", the same three firms will quote $4,000, $14,000 and $31,000 CAD, and none of them is wrong. They have each priced a different engagement.

The scoping questionnaire writes the document for you. This page is the reasoning behind it, for the person who would rather write their own.

The eight facts a firm quotes from

Naming the assets without inflating the count

Buyers overstate scope more often than they understate it, usually by listing every hostname their DNS provider knows about. Testers price distinct attack surfaces, not hostnames. Forty subdomains that all terminate on one load balancer in front of one application are one application. Two applications that share a login but have separate authorization models are two.

What actually counts as one thing

One web application

One codebase, one authorization model, one set of roles. Marketing sites and documentation portals are not applications for this purpose and should be listed separately if you want them looked at.

One API

One specification. If the mobile app and the web front end call the same endpoints, that is one API and the mobile client is a second surface, not a second backend. This is set out on API penetration testing.

One network range

Priced in live hosts, not in addresses. A /24 with nine machines on it is nine hosts. Say the live count and offer to be corrected.

One cloud account

A configuration review of an AWS or Azure tenant is scoped by account and service count, not by instance count, and is a different engagement from network testing. See cloud penetration testing.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

Counting roles, which is the number people forget

Role count drives more of an application engagement than asset count does. A tester with one set of credentials can find injection and misconfiguration. A tester with credentials for an administrator, a regular user in tenant A and a regular user in tenant B can find the class of flaw that ends companies: one customer reading another customer's data.

Write down every distinct permission level, including the ones you do not think of as roles: a read-only auditor account, a support account your own staff use to impersonate customers, an API key with different scopes from the interactive session, an unauthenticated public endpoint. Then supply two accounts at each level, because testing whether user A can reach user B's records requires both A and B to exist before the engagement starts. Creating them mid-test costs half a day, usually your engineer's.

Production or staging

Test staging if, and only if, staging is a real mirror: same authentication provider, same authorization logic, same data model, same integrations even if they point at sandboxes. Most staging environments fail at least one of those, and a report about an application nobody uses is worth nothing.

If staging is not a mirror, test production and manage the risk in writing. Agree a request rate ceiling, name the accounts the tester will use so your detection team can tell testing from an incident, take a backup before the window opens, and put a phone number in the document. Serious firms expect this and will supply the wording.

1. Decide which environment answers the question you are paying to answer.
2. Write down what differs between staging and production, honestly. If the list is long, staging is not a mirror.
3. If production, agree rate limits, a rollback contact and a stop word in the statement of work rather than over email.
4. Tell your monitoring vendor and your cloud provider before the window, not during it.
5. Log the tester source addresses so findings can be reconstructed later.

Exclusions that save money, and exclusions that ruin the test

Some exclusions are sensible cost control. Others remove the reason you bought the test, and they tend to be written by whoever is most nervous about downtime.

Say what you want at the end, in the scope

Report writing is a fifth to a third of an engagement, so deliverables belong in the scope rather than in a conversation afterwards. Name the artifacts you need and the date each is due. At minimum: a technical report with reproduction steps, an executive summary written for someone who is not technical, and a severity rating per finding with the method stated. If a customer or an auditor is the reason for the test, you also want an attestation letter. That is the document you can share without handing a prospect a list of your open weaknesses.

Put the retest terms in the same paragraph. Ask whether verification of your fixes is included, and if so how long the window is. Thirty to ninety days is the common range, and the difference decides whether your engineering team has to reprioritise. Retest and remediation verification covers what a good verification pass contains, and the retest planner works out your last safe ship date.

Sending it out

Send the identical document to three firms. Ask each for a price, a tester day count, and the seniority of the people who will do the work. The day count is the only line that converts directly into effort, so it is what makes quotes comparable. A $9,000 CAD quote at five days and a $9,000 CAD quote at two days are not the same offer, and the second one is planning to spend three of those days running tools.

Give a deadline of a week and say you are comparing three. Firms behave differently when they know it, and the ones that come back with questions about your roles and your tenancy model are worth shortlisting. The rest of the shortlist method is on penetration testing companies in Canada, and the questions to put to each firm are on questions to ask a penetration testing vendor.

If the numbers still come back far apart, that is information rather than noise. A firm prices what it cannot see, so the size of the spread is roughly a measurement of what your document left open. Why two firms quote different numbers breaks one down into tester days and shows which lines the scope closes.

Common questions