Planning and scoping a penetration test

Why planning matters

Testing without a clear plan risks three things: testing systems you are not allowed to touch, breaking something important, and producing results that do not answer the client's real question. Pre-engagement planning prevents all three. It is also where the legal protection for both sides is created.

Objectives and scope

Start with objectives. "Test our network" is vague. "Find out whether an attacker with a stolen staff laptop could reach payroll data" is testable. Objectives drive everything else.

The scope lists exactly what may be tested: IP ranges, hostnames, application URLs, user roles, physical locations and people. Equally important are the exclusions, such as a fragile production database or a partner's systems. Confirm ownership of every IP address and domain, because a typing mistake in a range could put someone else's network in scope.

Third parties need special attention. Cloud and hosting providers have their own testing policies, and a shared hosting platform or SaaS product usually cannot be tested without the provider's agreement.

Rules of engagement and contacts

Agree named contacts on both sides with phone numbers available during testing hours, and a clear stop procedure: anyone on the client side can halt testing if something goes wrong.

Paperwork and preparation

• Contract or statement of work (SOW): deliverables, dates, cost and liability.
• Non-disclosure agreement (NDA): protects the client's information.
• Authorisation letter: signed by someone with authority over the systems, naming the scope and dates. Testers keep a copy during the test, especially for physical work.
• Data protection terms: how any personal data seen during testing is handled and deleted.

Practical preparation includes creating test accounts, deciding whether tester IP addresses will be allow-listed in security tools (which affects realism), taking backups of systems in scope, and informing the SOC or managed service provider if the client wants them to know.

Tip: keep a one-page summary of scope, contacts and rules beside you while testing. When in doubt about whether something is in scope, ask before acting.

Real-world example: scoping a test for a law firm

A fictional law firm asks for "a pen test of everything". In the scoping call, the testing company narrows this down. The objective is to see whether an outsider could reach client files. The scope becomes the firm's public IP range, its client portal and a test account in its Microsoft 365 tenant; the hosted phone system is excluded because the provider has not given permission. Rules of engagement ban denial of service and limit password guessing to avoid lockouts. Testing runs on two weekday evenings, with the IT manager's mobile number as the emergency contact. Everything is written into a signed authorisation letter before work starts.