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.

First: read what they actually asked

Before requesting a single quote, go back to the exact wording. Questionnaires vary enormously, and the answer changes what you buy.

• "Do you conduct penetration testing?" — a scoped test of your product, with a report, satisfies this.
• "Provide your most recent penetration test report" — they will read it. It needs to be a real report with methodology, findings and remediation status.
• "Testing by a CREST-accredited provider" — this is a hard filter. It decides your shortlist before anything else. Check for this first, because it is the one requirement you cannot work around.
• "Are you SOC 2 / ISO 27001 certified?" — a different and much longer road. A penetration test is a component of those, not a substitute.

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.

What they are usually asking about

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:

• Authorisation between tenants. If you are multi-tenant SaaS, whether customer A can reach customer B's data is the question that matters most. Make sure it is explicitly in scope.
• Role separation. Whether a standard user can perform administrator actions. Test every role boundary, in both directions.

How fast can this happen?

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.

Production or staging?

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.

What to tell the customer while you wait

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.

What not to buy right now

Under deal pressure it is tempting to buy everything. Resist it.

• Internal network testing — valuable eventually, rarely what a SaaS customer is asking about.
• ISO 27001 certification — if the questionnaire asked about testing, answer that. Certification is a separate, longer programme and will not arrive in time for this deal.
• A retainer — a sensible year-two conversation, not a prerequisite for the first report.
• Mobile testing, unless you ship a mobile app that is genuinely part of what they are buying.

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.

After the deal closes

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.

If the clock is already running

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.