Pentest scope builder

Write the scope before you book the pentest.

Answer seven short sections and get a scope document any testing firm can quote and work from: what is in scope, the accounts testers need, the rules the test must check, the limits and the sign-off.

Your answers stay in this browser. Nothing is sent to MATT or anyone else, and the document is yours to edit.

01

The product and why you are testing

A tester prices and plans around the reason for the test, so name it first.

Why are you testing now?
02

What is in scope

List every surface a customer or an attacker can reach. The most common scope gap is an API left out because the web app was tested.

Surfaces to test
03

Users, roles and data

Authorisation flaws, one user reaching another user’s data, need at least two accounts per role. Testers can only find what their accounts let them try.

Who shares the product?
How do people sign in?
Sensitive data the product holds
04

How it is tested

More access means less time spent guessing and more time spent on the flaws that matter.

What do testers start with?
Where does testing run?
05

Rules the test must check

A scope says where to look. A rule says what must be true when the testers are done. Pick the ones your product depends on; each links to the attack pattern that breaks it.

06

Limits

Written limits protect your customers and the testers. Anything missing from this list is open to dispute later.

Out of scope
07

Reporting and timeline

Agree what the report contains before testing starts, so it serves the engineers who fix and the people who asked for it.

When must a critical finding be reported?
What the report must contain
FAQ

Questions about scoping a pentest

What should a penetration test scope include?

The reason for the test, every surface in scope (web app, API, mobile apps, AI features, cloud), the user roles and test accounts, how much access the testers get, what is out of scope, the rules of engagement, what the report must contain and who signs it off. A scope that leaves any of these open gets priced on guesses.

Does SOC 2 require a penetration test?

The Trust Services Criteria leave the method to the company. A point of focus under CC4.1 names penetration testing among the evaluations management can use, and many auditors and enterprise customers expect a recent report. The binding commitment is the testing frequency written into your own control description, so agree it with your auditor.

How many test accounts does a tester need?

At least two for every role. In a multi-tenant product, create every role in two separate customer organisations, because broken object level authorisation, one account reaching another’s data, is the first risk on the OWASP API Security Top 10.

Should we test staging or production?

Staging is safer when it truly mirrors production; differences in code, configuration or data hide real flaws. Production testing finds what customers are exposed to, so it needs tighter limits: test accounts only, no load testing and no destructive actions.

Do we need our cloud provider’s permission?

AWS, Microsoft and Google let customers test their own resources without prior approval, within published policies that prohibit denial-of-service and flooding tests. Services you use but do not own need their owners’ written authorisation.

How often should we test?

PCI DSS sets at least every 12 months and after significant changes; SOC 2 follows whatever your control description says. A product that ships every week changes faster than any yearly cycle, which is why the rules in section 5 are worth re-checking on every release.

What happens to my answers?

Nothing leaves your browser. The page keeps your draft on this device so you can come back to it, and the Start again button clears it.

ExploitOps discovery call

Understand where your security loop breaks.

A 15-minute call with a MATT co-founder to understand your product and whether an ExploitOps Review is worth doing. If there is a real need, we scope one with the research team.