Start with the question you need answered
Before listing targets, decide what you need to learn. The question shapes which systems are tested, how deep testing goes, and what the report should emphasize.
If a requirement drives the test, read it closely. PCI DSS, for example, calls for internal and external penetration testing at least once every 12 months and after significant changes, following a defined methodology.
- Can someone on the internet reach sensitive data through our customer-facing application?
- Does our API stop one customer from reading another customer's data?
- If an attacker gains a foothold on one internal laptop, how far could they move?
- Does a customer contract or a framework require a test, and what exactly does it require?
Get written authorization from people who can give it
Testing systems without permission can break the law and your contracts, even with good intentions. Authorization must come in writing from someone with authority over each system in scope.
- A signed authorization that names the systems, the testing team, and the testing period.
- Approval from the owner of each target, including business units that run their own systems.
- A check of your cloud and hosting providers' testing policies, and permission from any third party that operates a system you want tested.
- Confirmation that test accounts, test data, and any access granted are approved for use.
Name the targets and the exclusions
A precise target list prevents both gaps and accidents. Vague scopes, such as “the website” or “the cloud environment,” lead to disagreements later about what was covered.
- Specific URLs, API base paths and documentation, IP ranges, or cloud accounts.
- The environment to test, and whether it matches production closely enough for the results to hold.
- The user roles to test, with a test account for each, so authorization flaws can be found.
- Anything explicitly out of scope, such as third-party payment pages, fragile legacy systems, or social engineering.
- How test data, and any sensitive data encountered during testing, will be handled and deleted.
Agree on windows, rules of engagement, and stop conditions
Rules of engagement turn the scope into operating instructions. Agree on them in writing before testing starts.
- Testing windows, including time zones and blackout periods such as a product launch.
- Techniques that are allowed and techniques that are off-limits, for example denial-of-service attempts or password spraying against production accounts.
- Who to notify internally, including any team or provider that watches your alerts, so real incidents aren't mistaken for testing.
- Emergency contacts on both sides who can be reached during every testing window.
- Stop conditions: service instability, signs that someone else has already compromised a system, or exposure of sensitive data beyond what the test needs.
- How critical findings are reported during the test instead of waiting for the final report.
What a report you can act on contains
The report is the product. It should let leaders make decisions and let engineers reproduce and fix each issue without a follow-up meeting.
A list of scanner output with generic advice is not a penetration test report. Ask to see a redacted sample report before you sign.
- An executive summary in plain language: overall exposure, the most important risks, and what to do first.
- For each finding: the affected asset, clear reproduction steps, evidence, a risk rating with its reasoning, and specific remediation guidance.
- Attack chains that show how lower-severity issues combine into a larger risk.
- The methodology, the exact scope tested, the test dates, and anything that was planned but not tested, with the reason.
Plan the retest before testing begins
A fix isn't finished until it is verified. Agree up front on whether a retest is included, what it covers, and how long you have to remediate before it happens.
A retest confirms that the original findings were fixed without introducing new problems. The updated report should show the status of each finding, so you can share accurate results with customers or auditors.
Common scoping mistakes
Each of these is cheap to prevent during scoping and expensive to discover in the final report.
- Testing a staging environment that differs from production in ways that matter.
- Supplying only one user role, which hides authorization flaws.
- Setting a testing window that is too short for the size of the scope.
- Forgetting to tell the people who watch your alerts, which wastes effort on both sides.
- Treating an automated vulnerability scan as a penetration test.