A clean penetration test report does not mean a system is secure. It means a particular set of people, with a particular amount of time and access, did not find a serious problem in the parts they were asked to look at. That is useful information, provided nobody reads more into it.

What a test can and cannot show

A good test shows that specific weaknesses are exploitable, what an attacker could reach through them, and how individually minor flaws combine. No scanner output gives you that kind of evidence, and a demonstrated path to customer data tends to settle arguments about priorities.

A test can't prove the absence of vulnerabilities. It is a snapshot, so the next release can invalidate it. Testers usually have days, whereas a motivated attacker has no such limit. Most tests also won't tell you whether your team would notice an intrusion, or how well your people would respond. If those are your questions, you want a red team exercise or a tabletop instead.

Choose the type by the question

  • Vulnerability scan: automated and broad, good for finding known issues regularly. Useful, but not a penetration test.
  • External network test: what can someone on the internet reach and exploit?
  • Internal test: what happens after one laptop or account is compromised?
  • Web application or API test: can a user reach another customer's data or escalate privileges? This relies heavily on human understanding of business logic.
  • Cloud configuration review: are identity policies, storage and network settings exposing more than intended?
  • Social engineering: do your staff and processes hold up against phishing or pretext calls?
  • Red team: an objective-based simulation that also tests detection and response. It suits organisations that have already fixed the basics.

Knowledge level matters too. Black-box testing, where testers start with nothing, sounds realistic but spends paid hours on discovery that an attacker would get for free over time. For most applications, we think grey-box testing with credentials for each role and access to documentation is the better use of the budget.

Scoping is most of the value

Begin the conversation with what you are afraid of, not with a list of IP addresses. "Could one tenant read another tenant's invoices?" produces a better test than "test the portal". Before work starts, agree on:

  • What is in scope and, just as explicitly, what is out and why.
  • Written authorisation from someone entitled to give it, including the owners of any third-party or hosted systems involved.
  • Whether testing runs against production or a representative staging environment. Staging is safer, but only informative if it matches production.
  • Test accounts for every role, ideally across two tenants.
  • Rules of engagement: testing windows, off-limits techniques, emergency contacts, and what happens if testers find evidence of a real compromise.
  • Which standard they work from. The OWASP Web Security Testing Guide is a reasonable reference for web applications.

Reading the report

Start with the coverage section, not the findings. What was tested, for how long, and what could not be tested? A short findings list from a three-day test of a large platform says little.

Treat severity scores as input rather than as your priority order. CVSS rates the technical severity of a vulnerability, and its base score knows nothing about your business. A medium finding on an internet-facing payment flow may matter more than a high on an isolated test server.

Then look for patterns. Five separate injection findings are one finding about how your team handles input. Missing authorisation checks on three endpoints suggest a framework-level gap, and the fix belongs there. Be wary of reports that are largely reformatted scanner output with no evidence of manual work, no reproduction steps and no attack chains.

Retesting closes the loop

Assign every finding an owner and a due date before the report goes into a folder. Fix root causes where you can, then ask the testers to verify the fixes. A retest confirms that a specific issue has been resolved. It doesn't re-examine the whole system, so a retest letter shouldn't be presented to customers as a fresh clean bill of health. Book it when you book the original test, so the deadline exists from the start.

Test again when something significant changes, such as a new authentication flow or a platform migration, rather than purely by the calendar.

What to do this week

  1. Find your most recent report and count the findings still open.
  2. Read its scope section and list what has shipped since then.
  3. Write down the two or three outcomes you most want to rule out. That is the opening of your next scope.