The penetration test report a US buyer expects — and what Indian vendors usually send

Somewhere in every enterprise vendor review is a row asking for a recent penetration test. It is one of the few questions where the answer is a document rather than a statement, which means it is one of the few where you can fail on sight.

What the buyer is actually checking

Not the findings. Reviewers are largely indifferent to what your report found, and a report with zero findings makes them more suspicious, not less. What they check, in roughly this order:

• The date. Within twelve months is the usual bar, and older than that often reads as no report at all.
• The scope. Which systems were tested, and does that scope include the product they are about to buy? A test scoped to your marketing site does not cover your API.
• Who performed it. An independent party, named, with something to lose. A self-assessment is not a penetration test regardless of how thorough it was.
• Whether findings were remediated. An open critical from eight months ago is worse than the same critical found last week, because it says something about your process rather than your code.
• Retest evidence. Did anybody confirm the fixes actually worked, or does the report simply end?

That last item is where most reports quietly disappoint. A finding marked "remediated" on the vendor's say-so is an assertion. A finding marked remediated with a retest date and a result is evidence, and reviewers can tell the difference at a glance.

What Indian vendors usually send instead

Three substitutes come up again and again, and all three are read as a no:

• A vulnerability scan exported to PDF. Scanners and penetration tests answer different questions — one lists what might be wrong, the other establishes what an attacker could actually do. Reviewers know the difference between a scanner's output and a tester's narrative.
• A certificate from a testing body with no report attached. The certificate asserts a test happened; the buyer's security team needs to see scope and findings to know whether it covered anything relevant.
• A report scoped to the corporate website when the product is an API. Common, understandable, and immediately disqualifying for the thing being purchased.

The fourth substitute is silence plus a promise, which works far better than founders expect. "We do not have one; we have booked a test for March covering the production API" is a manageable risk. An irrelevant PDF is an unmanageable one, because now the reviewer is also wondering whether you understood the question.

What a usable report contains

Whoever produces it, the artefact a security reviewer can accept has a predictable shape: an executive summary a non-specialist can read, an explicit scope statement naming the systems and the dates, a methodology note, each finding with severity, evidence of exploitation, and a remediation recommendation, and a retest section confirming what was fixed and when. A named human signs it.

That structure is not a formality. Every element maps to a question the reviewer has to answer for their own risk register, and a report missing one of them sends them back to you with follow-up questions — which is another week of deal time.

Cadence beats recency theatre

The annual test exists because that is how the consulting engagement was priced, not because attackers work to an annual cycle. A report dated eleven months ago technically clears the bar while describing a system that has since shipped two hundred releases.

If you can test continuously and produce the artefact on demand, the twelve-month question stops being a deadline you scramble against. That is the argument for testing being part of your pipeline rather than a purchase you make each spring — and it is a materially better answer to give a buyer than a PDF that happens to be in date.