A pen test is a compliance artefact, not just a security exercise
Most UK SaaS founders commission their first penetration test because a customer asked for it, not because they woke up worried about their threat model. This is rational. Below a certain scale, the real driver of security investment is procurement: an enterprise buyer puts a security review in front of you, and somewhere on that review is a box that says "share your most recent external penetration test report". Without one, the deal stalls.
The goal of this playbook is to help UK SaaS teams get a pen test that serves three masters at once: compliance (ISO 27001, SOC 2, Cyber Essentials Plus), procurement (enterprise customer security reviews), and actual security improvement (fewer incidents, faster incident response). These three goals align most of the time, but not always — and when they diverge, the test scope and the way you respond to findings are what separate a useful engagement from an expensive one.
Scoping to satisfy compliance without over-paying
A well-scoped SaaS test has three zones:
- The authenticated web application — the main product that customers log into. Test it with real credentials, across at least two tenants, with permissions covering normal users and admin users.
- The public marketing site and any pre-login flows — registration, password reset, invite acceptance. These are small surfaces but attract automated attack traffic.
- The API layer — including webhook endpoints, third-party integrations, and any "internal" APIs that are actually reachable from the internet. See our OWASP API Top 10 guide for detail on what API testing should cover.
Scope explicitly excludes: the cloud provider's underlying infrastructure (covered by your provider's own attestations), denial-of-service testing (unless pre-arranged with both provider and tester), and third-party services that you use but do not operate. Leaving these out of scope is standard and auditors accept it, provided you have evidence that the excluded areas are covered by other controls.
Timing the test against your compliance and sales calendar
Penetration tests create a window of fresh assurance. That window closes, depending on who is asking, in 6-12 months. You want the test to land before the period in which the evidence will be used most. Some practical patterns:
- Pre-ISO 27001 stage 2 audit: test 1-2 months before the audit so remediation is complete, findings are closed, and the auditor sees both the report and the evidence of fix.
- Pre-fundraise: test 2-3 months before you go out. Technical due diligence will ask.
- Pre-enterprise push: test at the start of the quarter in which you expect enterprise customers to run security reviews.
- Post-major release: any time you ship something that materially changes the threat model (a new authentication mechanism, tenant model change, new public API surface).
Do not stack these all into one test. Run two tests a year at minimum if you sell to enterprise or operate in a regulated vertical. One annual test is the minimum for companies starting out in lighter-regulated B2B SaaS.
What a useful report looks like
The report your pen testers produce is a deliverable you will hand to customers and auditors. Its quality matters as much as the testing itself. A useful report has:
- An attestation letter — a short signed statement confirming scope, dates, and overall outcome. This is what you share with most procurement reviewers.
- An executive summary — risk heat-map, business-language description of issues, status at handover. This is what you share under NDA with more thorough reviewers.
- A technical body — each finding with CVSS score, reproduction steps, remediation guidance. This is the engineering-facing artefact.
- A retest addendum — after you fix the findings, the tester retests and issues a closure letter stating what has been resolved. Auditors expect this.
At YUPL we produce all four as standard. If your chosen testing partner does not, ask why; it is usually a sign they scope on tester-days rather than outcomes.
Handling findings: what "good" looks like
No SaaS with any complexity receives a clean first report. Critical findings in a mature SaaS are uncommon; high findings are rare on a well-maintained platform but not unheard of; medium and low findings are the bulk of the list. How you respond to them is the thing that auditors, customers, and future-you care about.
A good response process:
- Triage within 3 working days of receiving the report. Critical and high get scheduled into the next sprint; medium findings get tickets; low findings are decided on individually.
- Remediate critical and high within 30 days. Medium within 90. Low within the next quarter, unless you explicitly accept the risk and document why.
- Book a retest once remediation is complete. Retests are typically 25-40% of the original engagement cost.
- Issue the retest closure letter to any customer or auditor who saw the original report.
Aligning with ISO 27001, SOC 2, and Cyber Essentials Plus
Three frameworks cover the majority of UK SaaS compliance pressure. Here is how a penetration test programme maps to each:
ISO 27001:2022. Annex A 8.8 requires management of technical vulnerabilities, and A 8.29 covers security testing in development. An annual external pen test plus ongoing internal scanning typically satisfies both. The testing programme should be documented in your Information Security Management System and reviewed in management review.
SOC 2 Type II. The Trust Services Criteria do not mandate pen testing explicitly, but the Common Criteria around change management (CC8) and monitoring (CC7) are routinely evidenced with pen test reports. US-listed customers ask for SOC 2 more often than UK ones, but it matters for any SaaS targeting the US market.
Cyber Essentials Plus. Annual vulnerability scan and hands-on technical assessment by an accredited body. This is lighter than a full pen test — it focuses on the boundary controls and endpoint hardening rather than application logic. It complements pen testing but does not replace it.
Choosing a partner
For UK SaaS, the signal to look for is CREST accreditation at the firm level and CREST individual certifications (CRT, CCT Web) on the testers who will actually do the work. Ask the firm to confirm the seniority of the individuals who will deliver the engagement — not the firm average, not the partner who signed the sales call.
Ask to see a sample report, redacted. A firm that cannot show you one is either new or not confident enough in their output to share it. Ask how they handle retests: "included" or "at cost" should be in writing. Ask about their remediation advisory — if you get a list of CVSS scores and no guidance, your engineers will burn days on work that the tester could have compressed into a paragraph.
YUPL's penetration testing service is built to this pattern: CREST-accredited firm, named CREST-certified testers, fixed-scope quotes with retest included, and reports written so engineering leaders can action them without a decoder ring. If you are a UK SaaS looking to align your testing programme with ISO 27001, SOC 2, or enterprise procurement requirements, get in touch and we will scope something that actually fits.
About the author. Spencer Schotel is CTO of YUPL, a CREST-accredited UK agency specialising in Laravel engineering and application penetration testing for SaaS and e-commerce clients.