Penetration Testing for a SaaS Startup: When to Start and What to Buy
The first test is usually bought because a customer asked. Here is when it is genuinely worth doing sooner, what to spend on it, and what enterprise buyers will ask for next.
Almost every early-stage SaaS company buys its first penetration test for the same reason: a prospect asked for one and the deal is waiting. That is a fine reason, and it usually arrives about a year later than it should have.
The trigger that should come first
Before a customer asks, there is a moment when the honest answer to "could one customer read another customer’s data" stops being obviously yes-we-checked and becomes probably-not. That moment is when multi-tenancy stops being a single organisation identifier on every query and starts being a set of rules in several places.
For most products that is somewhere between the fifth and the fiftieth customer, and it is the point at which a test is worth buying for your own sake rather than for a form. The finding you are looking for is the one where a legitimate user of tenant A can reach something belonging to tenant B, and no scanner will find it because it is a rule from your business rather than a published vulnerability.
When a prospect asks for a pen test report they are rarely interested in the findings. They are asking whether you are the kind of company that has one. That is worth knowing, because it means a small, well-scoped, honest test beats an expensive one you cannot explain.
What to buy first
A grey box test of the application, with two accounts in each role, focused on authorisation and the multi-tenant boundary. Three to five days is a realistic first engagement for most products at this stage.
Do not start with the infrastructure. A managed platform with a handful of services is not where your risk is; your risk is in the code you wrote in a hurry to close the last deal. Infrastructure testing becomes worthwhile when you start running things yourself.
What it will cost, roughly
Day rates in the UK market for application testing generally sit in the several hundreds to low thousands per tester per day. A first application test with reporting included is therefore a low-to-mid four-figure engagement for most early products, and a five-figure quote for a simple application with two roles is either scoped for something larger or aimed at a different buyer.
Budget for the retest at the same time. Fixing what was found and proving it is fixed is the part a customer actually asked about, and buying a test with no retest is buying half of it.
What the enterprise buyer asks for next
Once the first test is done, the questions escalate in a predictable order, and knowing the order lets you prepare rather than scramble.
- An attestation letter rather than the full report, which is easier for you and better for them.
- Evidence that findings were remediated, not just identified.
- Testing frequency, and whether you test after significant change.
- Whether the tester was independent of the development team.
- SOC 2 or ISO 27001, at which point the test becomes one control inside a larger programme.
- Where the findings are stored and who can read them, which is a question far fewer buyers ask than should.
What not to do
Do not run a scanner and call the output a penetration test. The report will be recognisable as tool output to anybody technical on the buyer’s side, and the credibility cost is larger than the saving.
Do not scope the test to exclude the part you are worried about. It is a natural instinct and it converts a useful exercise into an expensive certificate.
Do not sit on the report. A prospect asking follow-up questions three weeks later about findings you have not started is worse than not having tested, because now the gap is documented.
What to have ready, so you are not paying for waiting
At this size the most common waste is access. Two accounts in each role, working, tested from outside your own network, before the start date. If you enforce multi-factor, decide how the tester enrols before the morning it blocks them.
Beyond that: a staging environment that resembles production rather than a hollowed-out copy with the integrations stubbed, one person available for the week who can answer questions, and written authorisation from somebody who can give it. If you are hosted on a platform whose terms require notice before testing, check that in advance rather than on day one.
Where AI fits, and where it does not
Plenty of firms now draft reports with a model, and that is fine when the tester has done the testing and the model has done the typing. It is not fine when the analysis is generated, and the way to tell is to ask what the model was given and what it produced.
The question with commercial weight for you is different: does your data leave the tester’s control to reach that model? For a startup whose whole pitch is that it handles customer data carefully, "our supplier posted a list of our vulnerabilities to a third-party API" is an awkward sentence. Ask, and expect a precise answer.
Make the second one cheaper
Most of the cost of a first test is understanding your system. Keep the scope statement, the account set and the architecture notes from the first engagement and hand them over next time, and the same firm spends the days on testing rather than orientation.
Fix the classes rather than the instances, too. A second report that repeats the first one is the clearest signal available that remediation, not testing, is the thing to spend on.
Pental is the platform testing firms run on rather than a testing firm, so the relevant question for a buyer is where their findings end up: in this case a database the consultancy owns, in their own account, with the AI on their own key. It is worth asking whoever you buy from, and a supplier who cannot answer it precisely has not thought about it.
Pental Is Built by the People Writing This
Engagement management for testing firms, on a database you own, under your brand, with the AI running on your key.