Penetration testing for startups: when the first pentest stops being optional

For most startups, the first pentest is not a security decision. It is a sales decision someone else made.

No European law tells a forty-person SaaS company to commission a penetration test by Friday. What happens instead is quieter: a bank, an insurer or a hospital group sends a security questionnaire, and one line asks for the date and summary of your last independent test. If the answer is "never", the deal waits. This piece explains where that line comes from, and how to buy the first test so it answers the question rather than just ticking it.

The requirement arrives through your customers

The pressure comes from the rules your buyers live under. The NIS2 Directive, Article 21(2)(d), lists supply chain security, "including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers", among the measures essential and important entities must take. Article 21(3) then asks them to weigh each supplier's vulnerabilities and the overall quality of its cybersecurity practices, including secure development. A startup that sells into a NIS2 entity is exactly that supplier.

Financial customers go further. Under DORA (Regulation (EU) 2022/2554), Article 30 sets out what contracts with ICT providers must contain. For services supporting critical or important functions, the Noerr analysis of DORA testing notes that financial entities must contractually require providers "to participate and fully cooperate in the financial entity's TLPT", the threat-led test that selected firms must run on live production at least every three years. If your product ends up in that scope, your security gets tested whether you planned for it or not. Better to have found the problems first. The detail of those rules is in our guide to DORA penetration testing requirements.

The buyers have a reason to ask. Verizon's 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled to 30%, and that exploitation of vulnerabilities now accounts for 20% of breaches as an initial access step. From a CISO's side of the table, a young supplier with no test record is a measurable risk.

SOC 2 and ISO 27001 ask for evidence, not a ritual

The second trigger is the first certification. SOC 2 is often the first one a startup selling to larger companies goes after, and its text is less prescriptive than people assume. In a piece republished by the Cloud Security Alliance, CPA Mike DeKock writes that there are "no explicit requirements for penetration testing" in a SOC 2 report, while calling a test "highly advisable" and pointing to criterion CC4.1, which asks the company to perform "ongoing and/or separate evaluations" of whether its controls work.

That framing is useful. The auditor is not looking for a pentest certificate. They want evidence that someone independent tried to break the controls you describe, and that what they found was fixed. A report with ten findings and ten closed tickets says more than a clean report from a test too shallow to find anything.

The first pentest is not there to prove you are secure. It is there to prove you know where you are not, and that you closed it.

What a first test should cover

Startups tend to make one of two mistakes with the first test: buying a scan sold as a pentest, or buying a two-week engagement scoped so wide that the report arrives after the deal has closed. The difference between automated and manual testing matters here, because the flaws that hurt a young SaaS product are usually in its business logic: one customer reading another customer's data, a role that can do more than it should, an API that trusts what the browser sends.

Regulators are also getting precise about what "tested" means. ENISA's NIS2 technical implementation guidance, published on 26 June 2025, gives examples of the evidence it expects for each measure for digital infrastructure, ICT service management and digital provider entities. Those are your customers' auditors' reference points, and in time they become yours.

Five steps for the first pentest

1. Start from the questionnaire. Ask your largest prospect which framework they assess suppliers against, and scope the test to answer that, not to cover everything.
2. Test the flows that carry customer data. Sign-up, login, roles, tenant separation, payments and the public API come before the marketing site.
3. Ask for proof, not a list. Each finding should show how it was exploited, so your engineers can reproduce it and your buyer can trust it.
4. Close the loop in writing. Keep the report, the tickets and the retest result together. That bundle is the evidence an auditor and a customer actually read.
5. Plan the second test now. A single annual test ages as fast as your release cycle. Read why the annual pentest breaks for SaaS before you budget for one, and see what a pentest costs in Europe.

Two questions to take to any provider on Monday: will this report answer my customer's questionnaire line by line, and can you retest the fixes before my next renewal?

I'm building Fleuret around exactly this gap: human-grade testing that a young company can afford to repeat. See Fleuret in action.

Sources

• Directive (EU) 2022/2555 (NIS2), Article 21, EUR-Lex, 2022-12-27
• Regulation (EU) 2022/2554 (DORA), Article 30, EUR-Lex, 2022-12-27
• Hacking by regulation: threat-led penetration testing under DORA, Noerr, 2025-07-04
• 2025 Data Breach Investigations Report, Verizon, 2025-04-23
• SOC 2 Reports and Penetration Tests, Mike DeKock (MJD Advisors), Cloud Security Alliance, 2024-02-02
• NIS2 Technical Implementation Guidance, ENISA, 2025-06-26