A customer asks for a pentest report. Now what?

Why the customer asks

The customer isn't asking out of curiosity. In almost every case they have to demonstrate something themselves, to a regulator, an auditor or their own board. You are a link in their story.

The result: a customer can't simply accept "we take security seriously". They need something they can put in their own file. You can read exactly how that supply-chain requirement works under NIS2 in NIS2 and your supply chain.

What the customer wants to see in the report

Not every report convinces. Security teams look at a handful of fixed points.

• Recent. In practice most customers apply a twelve-month window. If your product has changed significantly since then, even a six-month-old report carries less weight.
• Independent. Carried out by an external party, not by your own developers. Nobody is convinced by people assessing their own work.
• About the right product. The scope has to cover the service the customer buys. A report on your marketing website says nothing about your customer portal.
• Manual, not a scan. An export from a vulnerability scanner is not a pentest report. A security team sees the difference at a glance.
• With resolved findings. The customer doesn't expect nothing to have been found. They want to see that critical and high findings have been fixed, preferably confirmed by a retest.
• Genuine. A PDF can be altered in a few minutes. That is why every Resync report is digitally signed, so your customer can check for themselves that it is authentic and unaltered. You can read how that works in is a penetration test report genuine?

Already have a report? What you do and don't share

A complete pentest report describes step by step how an attacker could have got in. Even when everything has been fixed, that remains sensitive information about your architecture, your integrations and the places where things went wrong before. So you don't just send it as an attachment.

Is your report more than a year old, or does it not cover the product the customer is buying? Then say so honestly, and say when the next report will be ready. Presenting an old report as current will come out sooner or later, and then it costs you more trust than the gap itself.

No report yet? How to keep the deal warm

Not having a report is no reason to lose a deal. Not having an answer is. Five steps that work in practice:

1. Be honest. "We haven't had an external pentest done yet" is a better answer than a vague story. Security teams ask follow-up questions, and an evasive answer will come out anyway.
2. Name a date. Schedule the test and let the customer know when it takes place and when you expect the report. For many procurement teams, a confirmed schedule with an independent party is enough to continue the process.
3. Choose the scope that matters to this customer. Test the product this customer is going to use, including the APIs and the roles their staff will get. The rest can come later.
4. Plan time for remediation before the deadline. The report you want to share is the report with resolved findings. So work backwards: test, fix, retest. From intake to report, a multi-day pentest typically takes one to three weeks. The retest follows as soon as you have patched.
5. Meanwhile, fill in the rest of the questionnaire. Policies, access management with multi-factor authentication, the incident process and backups are things you can answer right now. The pentest report then fills the section on technical evidence.

If the deadline is short and the application is straightforward, a one-day Security Quick Scan of the highest-risk parts can be an honest interim answer. Do say that it is a short test. Whether a customer accepts that varies from customer to customer. You can read how to prepare the test so that no day is lost in preparing for a pentest.

Turn it into a selling point

If you expect the question, you gain time. In a procurement process, the supplier that stands out is the one that answers the security question in a single email, with the summary and the retest statement attached.

• Say it up front. State in your sales material or on your website that an independent pentest takes place every year, and that the summary is available on request.
• Test before the rush. Schedule the pentest before an important sales period or a big tender, not after.
• Keep the rhythm. At least once a year and after every significant change. You can read where that rule of thumb comes from in how often you should run a penetration test.

Conclusion

A customer who asks for a pentest report is asking for proof they can show someone themselves. If you have a recent report, share the summary and the retest statement, and the full report only under NDA. If you don't, be honest, name a date and test the product the customer is going to use, with time for remediation before the deadline. That way the question that seemed to be slowing the deal down becomes a moment where you show that you take security seriously, with proof instead of words.