How to scope a penetration test

A customer's vendor review usually wants to know whether its data can be reached by other customers or from the internet. An ECC control wants evidence that your systems are tested periodically and that findings are fixed. A new release wants to know whether the new feature opened a hole. Each question points to a different test, a different target list and a different depth. When the provider suggests adding or removing something, check it against your one sentence.

If your question is "which known vulnerabilities do we have", you need a vulnerability scan, not a penetration test. If it is "would we notice a real attacker", you need a red team exercise from a specialist team, which is a different exercise from the one this guide scopes, and you probably need to fix the basics first. The guide on scans and tests covers the difference.

Exclusions need reasons because they end up in the report. A payment page hosted by your payment provider is theirs, not yours. A legacy server that falls over under load might be excluded from active testing and noted in the report instead.

One rule decides a lot here: you can only authorise testing of systems you control. A software service you subscribe to belongs to its vendor. Your hosting provider's terms may require notice before testing, or restrict some kinds of test. Check both before the scope is final, not on day one of the test.

Black box sounds realistic, but a real attacker has months and your tester has days. Much of a short black box test is spent finding the login page. Grey box puts the testing days into finding flaws rather than into reconnaissance a real attacker would do anyway. White box finds the most, and it is the right choice for high-risk applications.

For any application with more than one customer or more than one role, one line in the scope matters more than any other: two accounts for each role, in two separate customer accounts. That is how a tester checks whether one customer can see another's data, and whether an ordinary user can do what only an administrator should. Without the second account, that flaw is very hard to find.

Have the accounts created and tested before the window opens. A test that loses its first day waiting for credentials has lost a fifth of a five-day test.

If you copy production data into staging, mask the personal data first. In Saudi Arabia, that data is covered by the PDPL wherever it sits.

Production testing needs a window outside business hours, confirmed backups, a named person on call, and a stop condition written into the rules. The lighter production check exists to confirm the two environments match.

Each rule below answers a question someone will ask at three in the morning if it was left unwritten.

Two proposals for the same scope at very different prices usually differ in days, and fewer days means less of your application actually tested.

Be wary of a large application quoted at a small, fixed number of days. The gap is often filled by an automated scanner.

The scope as tested should include anything that could not be tested and why. Each severity should name its scoring method, for example CVSS, with its version.

Ask for a redacted sample report and compare it with that list. The guide on what a good report contains gives twelve lines to hold it against.

You need it too, if something goes wrong at three in the morning and someone asks who allowed it.

Objective: confirm that a customer cannot reach another customer's data in the portal or its API, and that neither can be compromised from the internet. Targets: the customer portal at portal.example.com and its API at api.example.com/v2, documented in the attached specification. Starting point: grey box, with two customer users and one customer administrator in each of two test tenants, and one internal support account. Environment: staging, running the current production release, refreshed from production with personal data masked. Window: Sunday to Thursday, 22:00 to 04:00 Riyadh time, over two weeks. Excluded: the payment page hosted by the payment provider, and denial-of-service testing. Critical findings: by phone to the IT manager the same day.