Scoping a penetration test properly

The strongest scopes start from an outcome to prevent rather than a list of assets to sweep. Name the things whose compromise would genuinely hurt: the customer database, the payment run, the ability to push code to production, the tenancy boundary between clients in your platform. Then ask the tester to demonstrate whether those outcomes are reachable. That is a different instruction from testing twelve IP addresses, and it produces a different engagement, because the tester prioritises paths that lead somewhere instead of cataloguing everything equally.

Crown-jewel framing also settles scope arguments cleanly. Should the marketing site be in scope? If it shares infrastructure, credentials or a login flow with anything that matters, yes, because attackers use it as a stepping stone. If it is a static page on isolated hosting, it can wait. The objective decides, and the same logic prunes or adds systems without haggling over each hostname.

Decide early whether the test runs against production, a staging copy, or both. Testing staging is safer and is the right call for aggressive test cases against fragile systems, but a staging environment only gives assurance about production to the degree it actually matches: same code, same configuration, same authentication stack, realistic data shapes. Staging that has drifted answers a question nobody asked. Many engagements land on a split, with authenticated application testing in staging plus verification against production for the classes of finding that configuration drift would hide.

Treat every exclusion with suspicion, even the ones you propose yourself. The fragile legacy server everyone is scared to touch is precisely the machine a real attacker will lean on, and excluding it from the test does not exclude it from the breach. Write every exclusion down with a reason and a review date. Mark the third-party boundary honestly too: you can authorise testing of systems you own or control, while platforms you merely subscribe to are covered by the vendor's own terms. The major cloud providers publish standing rules that let customers test their own tenancy, and a scoping call should confirm what those rules allow before anyone touches the environment.

An unauthenticated test of an application answers one narrow question: what can a stranger on the internet do? Almost everything that matters in a modern application sits behind the login, so a scope that withholds credentials buys a perimeter check and calls it an application test. Provide working test accounts for each role the application has, and provide two accounts per role, because proving that user A can read user B's records requires both to exist. For admin tiers, a monitored account in a test tenancy is usually workable where a production admin login is not.

The same principle applies to networks. An internal test that starts from a standard staff account or a device on the office network, often called an assumed-breach starting position, tells you what a phished employee's laptop is worth to an attacker, which is the question most Australian businesses actually need answered. Starting the tester outside with nothing is a legitimate scope as well, but choose it deliberately, knowing it spends much of the window on getting in rather than on what getting in leads to.

Agree when testing happens and who knows about it. Business-hours testing means your team can respond if something breaks; after-hours windows suit fragile systems and noisy test cases. Check the window against change freezes, releases and peak trading before you sign it. Decide explicitly whether your IT or security team is told. An announced test avoids burning incident-response effort on friendly traffic, while an unannounced one doubles as a detection exercise. Both are valid, provided someone senior holds the full picture and can call off a real response.

Rules of engagement put the remaining edges in writing. Settle at least these: denial-of-service testing is excluded unless explicitly agreed, destructive actions and data modification in production are excluded, evidence handling is defined (what gets captured, where any sample data is stored, when it is destroyed), and a named emergency contact exists on both sides. Above all, agree a stop-and-report threshold. If the tester finds something critical and exposed, you want a phone call that day, and the tester needs to know that in advance rather than saving it for the report.

A penetration test report is a snapshot of open paths, and its value is realised when those paths close. Agree before the engagement how fix verification works: whether a retest of remediated findings is included, how long after delivery it can be called on, and whether it produces an updated report you can hand to a customer or auditor. A finding marked fixed by the team that fixed it has not been verified. A finding retested by the person who originally exploited it has, and auditors and enterprise customers increasingly ask for that second kind of assurance.

Settle the report itself at the same time. Ask for reproduction steps detailed enough for your engineers to follow, severity ratings that account for your context rather than a raw scanner score, and an executive summary a non-technical owner can act on. If a sample report is not offered at scoping time, ask for one.

Most disappointing penetration tests were doomed at scoping, and the patterns repeat closely enough to list. If any of these describes the engagement you are about to sign, fix the scope before the start date.

You can judge a provider by their scoping questions before you ever see a report. A call that only asks how many IP addresses and pages you have is pricing a scan. A useful one asks about your business first and your infrastructure second.

Answering those questions well costs you a little preparation and shapes everything the engagement returns. The mechanics that follow, how an objective is decomposed into attack paths and how far each one is safely pushed, are the tester's craft and vary with every environment. The scope is the part you control. Write the objective down, decide the environment and the access honestly, put the rules and the retest in writing, and the same block of skilled hours returns answers you can act on.