A Customer Wants Proof of a Penetration Test. Here Is What They Will Accept

Direct answer: Most buyers accept an attestation letter from the testing firm, stating scope, dates, methodology and that findings were remediated. They do not need the full technical report, and sending it is usually a mistake because it hands a third party a list of your weaknesses.

The three things they are checking

Whether the test was done by somebody independent, whether the scope covered the system they are buying, and whether you fixed what was found. A report that covers your marketing site when they are buying your API satisfies none of it, even though it is technically a penetration test.

Recency matters too. Twelve months is the usual expectation, and many enterprise reviewers will not accept anything older without an explanation.

Why the attestation letter is the right artefact

The full report contains reproduction steps for anything not yet fixed. Circulating that through a buyer's procurement inbox, where it gets forwarded and stored, is a real risk with no upside. A good testing firm will issue a summary letter designed for exactly this, and buyers are used to receiving one.

If a buyer insists on the full report, redact the reproduction detail for open findings, or share it under NDA through a controlled channel. Pushing back here is normal and does not read as evasive when you offer the attestation instead.

If you have never had a test done

Say so, and give a date. "Our first external test is scheduled for November with remediation to follow" is a workable answer. What does not work is a vulnerability scan presented as a penetration test. Reviewers can tell, because scanner output looks like scanner output, and being caught inflating this is worse than admitting the gap.

A scan is automated and finds known issues. A test is a person chaining findings together and proving what an attacker could actually reach. Both are useful. They are not interchangeable, and the questionnaire is asking for the second one.

Scoping it so it satisfies the buyer and the auditor

If SOC 2 or ISO 27001 is anywhere on your roadmap, scope the test so its report doubles as audit evidence. That means covering the production system in the audit boundary, timing it inside the observation window, and having the findings tracked to closure somewhere an auditor can see. Done properly you buy one test and satisfy two requirements.

That is how we scope compliance penetration testing, and prices are published on the pricing page so you can budget before booking a call.

What a usable attestation letter actually contains

Buyers vary in what they accept, but the letters that clear procurement without a follow-up email all carry the same content. The testing firm's name and a statement that it is independent of the organisation being tested. The dates the testing was carried out, not the date the letter was written, because a reviewer checking recency needs the fieldwork window. A description of the scope specific enough to be recognisable: the production application, the API, named environments, whether authenticated roles were included. The methodology, usually a reference to OWASP testing guidance or PTES rather than a paragraph of prose. A count of findings by severity. A statement on remediation status, ideally distinguishing between findings closed and verified closed. A named signatory with a role.

Letters that fail are usually vague in one specific way. They say "a penetration test was performed on the client's systems" with no scope at all, which forces the reviewer to ask the question the letter was meant to answer. If your testing firm issues one of those, ask them to rewrite it. Any firm that does this regularly has a better template and will produce it on request.

Remediated, closed, and verified closed

These three words get used interchangeably by vendors and they mean different things to a reviewer who has been burned before. Remediated is a claim by you. Closed is a claim by you that the testing firm has recorded. Verified closed means the tester went back and confirmed the issue no longer reproduces. Only the third one is evidence.

This is the single most common gap we see when reviewing another firm's report during a readiness engagement. Findings marked resolved in a tracking spreadsheet, no retest, and a letter that says findings were addressed. An auditor testing a vulnerability management control will ask for the retest artefact, and a sharp enterprise reviewer will ask the same question in different words: how do you know the fix worked. Book the retest at the same time you book the test, and check whether it is included in the fee or billed separately. A retest that costs almost as much as the original engagement is a sign the quote was structured to look cheap.

Scope wording that matches what the buyer is buying

Write the scope statement in the language your customer uses about your product, then check it against the technical scope your tester worked to. The two drift apart more often than people expect. Your tester's scope document may list hostnames and IP ranges. Your buyer thinks in terms of "the platform my data will sit in". If the report covers app.yourproduct.com and the buyer is integrating against api.yourproduct.com which runs on separate infrastructure, the letter is accurate and useless.

Three scope decisions carry most of the weight. Whether authenticated testing was performed, and against which roles, because an unauthenticated external test of a login page tells nobody anything about your multi-tenant isolation. Whether the API was tested directly rather than only through the web client, which matters if your customers integrate programmatically. Whether tenant isolation was specifically probed, meaning the tester held credentials in two tenants and tried to cross the boundary. For a B2B SaaS product, that last one is the finding class buyers care about most and the one a cheap external scan will never touch.

What the test costs and what moves the number

Testing is priced in days, and the day count is driven by attack surface rather than company size. Our penetration testing starts from $1,000 and scales with what has to be covered. The drivers, in rough order of impact: the number of distinct applications, the number of user roles and permission tiers that need separate authenticated passes, API endpoint count and whether the API is documented, whether a mobile client is in scope, whether cloud configuration review is bundled in, whether internal network testing is included, and whether a retest is part of the engagement or a separate purchase.

Two things reliably inflate a quote for no benefit. Asking for both external network testing and application testing when you run entirely on managed cloud services, because the external network layer is a handful of load balancer addresses and there is very little to find. And asking for a full internal network engagement when your team is remote, your laptops are managed, and there is no office network to attack. Spend those days on the application and on the cloud configuration instead, which is where the findings that actually threaten your customers live.

Timing it against a live deal

Reputable firms are booked out. Two to four weeks of lead time is normal, testing runs one to two weeks depending on scope, the draft report lands roughly a week after fieldwork ends, and remediation plus retest adds another two to four weeks. Work backwards from that and you are six to ten weeks from signing the engagement letter to holding a clean attestation. If the deal closes in three weeks, no amount of money compresses this honestly.

What works when the timeline is that tight is telling the buyer the truth with dates attached. A signed engagement letter with a scheduled start date, sent to the reviewer, moves more deals than a rushed test does. Reviewers are usually willing to close with a contractual commitment to deliver the attestation by a date, and many will accept that in a security addendum. What they will not accept is discovering later that the commitment was made with nothing booked.

When the test comes back badly in the middle of a deal

It happens, and it is survivable if you get ahead of it. Assume the report contains a critical or high finding, because first tests usually do. The order of operations is: understand the finding properly, confirm whether it was exploitable in production or only in a staging path, fix it, get the retest, and then decide what to tell the buyer.

What you do not do is delay the letter and hope. Reviewers track dates. If you told them testing was happening in September and the letter arrives in December with no explanation, the gap itself becomes the question. A short factual note works well: testing identified issues at high severity, they were remediated within a stated number of days, and the retest confirming closure is attached. That reads as a functioning security programme. Enterprises are not looking for companies that have never had a finding, because those companies have either not been tested properly or are not telling the truth.

The paperwork to keep beside the report

Auditors and mature buyers will occasionally ask for artefacts around the test rather than the test itself. Keep the rules of engagement, which set out what the tester was permitted to do and when. Keep the authorisation letter, which matters if testing touched infrastructure hosted by a cloud provider with its own testing policy. Keep the scope document that the tester worked to. Keep the tickets raised for each finding, with the identifiers, so the path from finding to fix to retest is traceable in a system rather than in somebody's memory.

That last one converts a test into vulnerability management evidence. During a SOC 2 or ISO 27001 audit, the control being tested is usually not "you had a penetration test" but "you identify, prioritise and remediate vulnerabilities on a defined timescale". A report with no tickets behind it satisfies the first phrasing and fails the second. If you are running toward a certification, our compliance work treats the test findings as inputs to that control rather than as a standalone document.

Decoding the question when it arrives in a questionnaire

Standard questionnaires phrase this in ways worth translating. A SIG question asking whether independent testing is performed at least annually and after significant change is asking two things, and the second half is the one people fail. Significant change means a new major feature, a new authentication flow, a new region, an architecture migration. If your last test predates your move to a new identity provider, answer honestly and note the next test date.

CAIQ-style questions about tenant isolation testing are asking specifically about the cross-tenant scenario described above. Questions about whether findings are tracked to closure with defined timescales are asking for your remediation policy, so have one that states target windows by severity and reflects what you actually do. A policy promising critical fixes in 24 hours, contradicted by a ticket showing nine days, is worse than a policy promising seven days and meeting it.

What to ask of your own vendors

The same reasoning runs in the other direction and it costs you nothing to apply it. When you assess a subprocessor, ask for their attestation letter rather than their full report, for exactly the reasons you decline to send yours. Check the same four points: independence, scope relevance to the service you consume, date, and remediation status. If a critical vendor cannot produce a letter, that is a risk register entry with an owner and a review date rather than a reason to panic.

Doing this properly also improves your own answers. Buyers increasingly ask how you assess the security of your vendors, and a vendor file containing dated attestation letters is a far better answer than a policy paragraph describing a process nobody has run.

When you should not buy a penetration test from us

If you have no production system yet, a test buys you a document about code that will not exist in three months. Spend the money on getting authentication and tenant isolation designed properly and test once there is something real to attack.

If the buyer's questionnaire genuinely asks for vulnerability scanning rather than penetration testing, and some do, then a scanner you run yourself and act on is the correct and much cheaper answer. Read the question rather than assuming the expensive interpretation.

If your entire attack surface is a marketing site on a hosted platform, with the actual product still in private beta behind a single customer, the honest advice is to wait. Similarly, if your last test was eight months ago, nothing significant has changed architecturally, and a buyer is asking now, send the existing letter rather than buying a new test to make a good impression.

And if what you actually need is somebody to keep finding and fixing issues continuously rather than a point-in-time engagement, a single test is the wrong purchase. That is a retainer conversation, and it is a different budget line with a different rhythm. We would rather tell you that before you buy the wrong thing than after.

Building the test into a repeatable annual rhythm

The companies that stop finding this stressful are the ones that put the test on a fixed calendar slot and treat the attestation letter as a renewable asset. Pick a month, ideally one that sits comfortably inside your audit observation window if you have one, and book the same slot every year. Keep the scope document under version control so each year's scope is a diff against the last rather than a fresh argument. Send the tester a short change summary before they start, covering new features, new authentication paths and new infrastructure, which improves the quality of the test and reduces the days spent on discovery.

Store the current letter somewhere your sales team can reach without asking engineering. Most of the friction in this whole process is not technical. It is a salesperson waiting three days for someone to find a PDF, while a reviewer's clock runs. Across the 20+ penetration tests we have run, the clients who handle buyer requests smoothly are consistently the ones who solved that retrieval problem, not the ones with the cleanest reports.

How to tell a serious testing firm from a scan reseller

The market has a wide quality range and the letters look similar at the top. A few questions sort it quickly, and you can ask all of them on a first call. Ask for a redacted sample report and read the findings: real testing produces findings with business context, chained steps, and impact described in terms of your data, while resold scanning produces a wall of TLS configuration notes and missing header warnings. Ask who is doing the work and what they have published or disclosed, because named researchers with a public track record are checkable. Ask how many days are allocated and how they are split between discovery and exploitation, since a two day engagement across four applications is a scan with a cover page.

Ask what happens if they find something critical mid-engagement, and listen for a defined notification path rather than "it will be in the report". Ask whether the retest is included. Ask what they will need from you, because a firm that wants test accounts in multiple roles, API documentation and an architecture walkthrough is planning to test properly, while one that only wants a URL is not.

We publish our own basis for this rather than describing it in adjectives: five CVEs to date, one of them scored CVSS 9.1 and used in Mirai botnet activity, and 20+ penetration tests delivered. Whatever firm you choose, ask for the equivalent. The answer takes them thirty seconds if it exists.