The usual sequence goes like this. A large customer wants to buy. Their procurement or security team sends a questionnaire. Somewhere around question forty it asks whether you carry out regular penetration testing and whether you can provide a recent report.
You cannot. The deal is now waiting on you.
If that is where you are, here is what to do — and what not to waste money on while the clock runs.
Before requesting a single quote, go back to the exact wording. Questionnaires vary enormously, and the answer changes what you buy.
Reading the question properly saves weeks. Plenty of startups buy an infrastructure test when the customer was asking about the application, and end up buying twice.
For a software company, it is almost always the product — the application the customer will be putting their data into. Not your corporate laptops, not your office network.
That means a web application penetration test, from £1,000, is usually the correct purchase. Scope it around the application, its authentication, its user roles, and the API behind it if you have one.
Two things reviewers look for beyond the test itself:
Faster than most people expect, if you prepare properly.
Scoping is a conversation, not a project — we need to know how many applications, how many user roles, whether there is an API, and which environment to test. Testing itself typically runs over several days. The report follows shortly after.
The part that takes longest is usually not the test. It is you fixing what it finds, and then getting a retest so the report shows issues resolved rather than open. Budget time for that, because handing a customer a report full of unresolved highs is worse than handing them nothing.
What genuinely speeds things up: having test credentials ready for every user role before day one, knowing which environment is being tested, and having a developer available to answer questions during testing rather than a week later.
Startups usually ask this, and it matters more here than elsewhere because your staging environment is often genuinely different from production.
Test production if you can, during agreed hours, with your team aware. It is the environment the customer is asking about. If you must test staging, confirm it runs the same code, the same configuration and the same authentication as production — otherwise you will produce a report that does not describe the thing being bought.
You do not have to say "no". Most security reviewers accept a credible plan, and saying so early is better than going quiet.
A response along the lines of: "Penetration testing is scheduled for [dates] with [provider], covering our production application including authentication and tenant isolation. We will share the report, including remediation status, by [date]."
That is a substantially better answer than silence, and it often keeps the process moving in parallel rather than blocking it.
Under deal pressure it is tempting to buy everything. Resist it.
One thing worth adding cheaply: a cloud configuration review if your product runs on AWS or Azure. Security reviewers increasingly ask about cloud posture directly, and misconfigured identity and access is the most common serious finding we see in cloud environments.
The next customer will ask the same question, and they will ask how recent the report is. Annual testing is the expected cadence, with vulnerability scanning in between so newly disclosed issues surface in weeks rather than at the next review.
Test again after significant architectural change too — a new authentication provider, a major API version, a move between cloud platforms. Those are exactly the changes that introduce the issues a year-old report cannot speak to.
Send us the questionnaire wording and a description of your product and we will tell you what needs testing to answer it, how long it takes, and what it costs. If the honest answer is that the requirement needs an accredited provider we cannot satisfy, we will tell you that immediately rather than after you have paid us.