A penetration test is only as useful as the report it produces. The report is what your engineers fix from, what your auditor reads and what your customers ask for. Yet many teams accept whatever arrives, because they don’t know what a good one looks like.

The bar is also rising from outside. PCI DSS v4 requires a defined, documented penetration testing methodology covering the application and network layers, tested from inside and outside the network. In India, CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines, issued in July 2025, expect a formal engagement letter that names the audit type, the systems in scope, the standards applied and the report format. And automated and AI-assisted testing tools have multiplied this year. They can be useful, but the checks below apply however the testing was done.

Seven things to check

1. Scope and dates are explicit

The report should say exactly what was tested, from where, with which accounts and between which dates. It should also say what wasn’t tested and why. A finding-free section of your application means nothing if nobody looked at it.

2. The methodology is named and followed

Look for a reference such as the OWASP Web Security Testing Guide, the OWASP API Security Top 10 or NIST SP 800-115, and evidence that the testing actually followed it. A methodology section copied from a template, with no link to the work done, is a warning sign.

3. Every finding can be reproduced

Each finding needs the request, the response and the steps to trigger it. Your engineers should be able to reproduce it without calling the tester. If they can’t, they can’t confirm the fix either.

4. Severity is explained in context

A CVSS score is a starting point. A good report explains why a finding matters in your environment: who can reach it, what they need first and what they get. Two identical bugs can carry different risk in two applications, and the report should say so.

5. Findings are validated

Every finding should be confirmed by a person. “Potential” and “may be vulnerable” belong in notes, not findings. Informational items such as server banners should be separated so they don’t bury real issues.

6. Remediation fixes the root cause

“Sanitise input” isn’t a fix. A good recommendation names the component, the change and, where possible, the pattern that prevents the whole class of bug, such as an ownership check in a shared data-access layer.

7. There is a retest record

A report should end with the status of each finding after you’ve fixed it: fixed, partly fixed or still open, with the date it was retested. Without that, the report describes a system that no longer exists.

Red flags that you paid for a scan

  • Finding titles or plugin IDs that match a commercial scanner word for word.
  • Dozens of TLS cipher and missing-header findings, and nothing about authentication, authorization or business logic.
  • No requests or responses, only screenshots of a tool’s output.
  • No attack chains. Real testers combine low-severity issues into higher-impact paths.
  • A test window that is clearly too short for the scope.
  • No mention of authorization testing between users or tenants, the most common serious flaw in modern APIs.

Before you buy the next one

  • Ask for a redacted sample report and check it against the seven points above.
  • Agree the scope, accounts and report format in writing before testing starts.
  • Ask who will do the testing and whether they’ll be on the readout call.
  • Confirm a retest is included and what it covers.

Sources

  1. PCI Security Standards Council: PCI DSS v4.0.1 (Requirement 11.4) (opens in a new tab)
  2. AZB & Partners: CERT-In’s new cyber security audit guidelines decoded (Aug 2025) (opens in a new tab)
  3. OWASP Web Security Testing Guide (opens in a new tab)
  4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (opens in a new tab)