Penetration testing: what a good scope, report and retest look like

A penetration test is an authorised, time-boxed attempt to find and demonstrate security weaknesses the way an attacker would. Done well, it gives you evidence of real risk and a clear path to fix it. Done badly, it produces a long PDF of scanner output that nobody acts on. The difference is mostly decided before testing starts and after the report lands.

Start with written authorisation

Testing without permission can be an offence under Australian law, even with good intentions. Before any testing, the client should confirm in writing that they own or control the targets and authorise the test. Where systems are hosted by a third party, check the provider's testing policy. Major cloud providers publish rules on what customers may test and what is prohibited, such as denial-of-service testing.

What a good scope includes

• Objectives: what you want to learn, for example whether one customer can access another customer's data.
• Targets: exact URLs, API base paths, IP ranges, mobile app builds or cloud accounts.
• Exclusions: systems that must not be touched, and techniques that are off-limits.
• Test accounts: at least two accounts per role, across two tenants if the product is multi-tenant.
• Approach: black box, grey box or white box, and whether source code or architecture diagrams are provided.
• Testing windows, rate limits and an emergency contact on both sides.
• Data handling: how screenshots and extracted data are stored and when they are destroyed.

What happens during testing

Good testers combine automated tooling with manual work. Manual testing is where business logic issues, broken access control and chained vulnerabilities are found. Frameworks such as the OWASP Web Security Testing Guide and the Application Security Verification Standard help ensure coverage. Expect the tester to tell you immediately if they find a critical issue rather than waiting for the report.

What a useful report contains

• An executive summary in plain language: overall risk, the most serious issues, and what to prioritise.
• Scope and methodology, including what was not tested and any limitations.
• Each finding with a severity rating and its basis, such as CVSS plus business context.
• Clear reproduction steps and evidence so your engineers can confirm the issue.
• Practical remediation advice specific to your stack, not generic best practice.
• Positive observations: controls that held up are useful evidence too.

Severity needs context

A CVSS score describes technical severity. It does not know that a particular endpoint exposes payroll data. Good reports explain the business impact and adjust priority accordingly, and say so transparently.

The retest is where value is realised

A report only reduces risk once findings are fixed. A retest confirms that fixes work and haven't introduced new issues. Agree in the scope how long the retest window lasts and what it covers. Track each finding as a ticket with an owner and due date, and close it only when the retest confirms the fix.

What a test cannot tell you

A penetration test is a snapshot within a limited time and scope. A clean report does not mean a system is secure, only that the tester did not find significant issues within those limits. Combine periodic testing with secure development practices, dependency management and monitoring, and retest after major changes.