Penetration Testing for SaaS 
How to Buy a Test That Finds Something 

The first penetration test is usually bought because a security questionnaire or a SOC 2 auditor asked for one. With that motivation, the cheapest vendor who can produce a PDF wins. The report lists missing security headers, an outdated TLS cipher, and a verbose error page; the findings are fixed in a day; and the company is exactly as vulnerable as it was before. The difference between that test and one that finds the tenant isolation bug that could have ended the company is decided almost entirely at scoping and vendor selection, before any testing begins.

A scan is not a test

Automated vulnerability scanning finds known CVEs, misconfigurations, and missing hardening. It is cheap, valuable, and should run continuously — but it cannot understand your authorization model. A penetration test is a skilled human trying to make the application do things it should not: read another tenant's data by changing an identifier, escalate from a viewer to an admin through an API call the interface never makes, or abuse a business workflow by refunding twice, applying a discount after checkout, or inviting themselves into another organisation. Broken access control and business logic flaws are the most damaging class of vulnerability in SaaS, sitting at the top of the OWASP API Top 10, and they are precisely the class scanners miss. Enterprise security teams know the difference, and a report consisting of scanner output reads as exactly that.

Scoping a test that matters

• Test authenticated, across every role, in at least two tenants. Provide test accounts for each role in two separate organisations. Unauthenticated-only testing of a SaaS application misses most of the attack surface.
• Test the API directly, not only through the interface. Share the API specification — many of the worst bugs live in endpoints the frontend never calls.
• Name the high-value targets explicitly: tenant isolation, billing, admin and support impersonation tooling, file upload and import, SSO and SCIM flows, webhooks and integrations, and any AI feature that can take actions.
• Include a cloud configuration review where it is in scope: IAM policies, public storage, exposed management endpoints.
• Prefer grey-box to black-box. Give testers architecture documentation and, ideally, code access. A black-box test spends a paid week rediscovering what you could have told them in an hour.
• Test in a production-like environment with a realistic data shape — and never with real customer data.

Choosing a vendor

Ask for a redacted sample report and read it for business logic and authorization findings with clear reproduction steps; a report dominated by scanner-style informational items tells you what you will receive. Ask who will actually perform the test and what experience they have with multi-tenant SaaS, rather than accepting the credentials of the firm's most senior partner. UK buyers in particular often expect recognised accreditations such as CREST, so check what your target customers ask for. Look at the effort: a thorough web application and API test for a growth-stage product is usually measured in one to three tester-weeks, and a quote of two days for a large application is a scan with a report attached. Confirm that a retest of fixed findings is included, and agree how critical findings are escalated during the engagement — a phone call the same day, not a line in the final report three weeks later.

Reading the report and fixing what matters

Severity ratings in a report are the vendor's generic view, so re-rank them in your own context: a medium-rated insecure direct object reference that exposes invoices is your critical. Fix the root cause rather than the instance. An authorization flaw on one endpoint almost always means an authorization pattern problem, so look for the same class across every endpoint and add an automated test that asserts cross-tenant access fails on every route — that test keeps paying long after the report is filed. Track findings in the same backlog as the rest of your work, with remediation targets by severity, because auditors and enterprise buyers ask for evidence of remediation rather than evidence of testing. When buyers request the results, share a summary or attestation letter by default and the full report under NDA, ideally through a trust center rather than by email.

How often, and what sits between tests

Annual testing is the common baseline for SOC 2 and enterprise expectations, with additional targeted tests after significant change — a new authentication system, a new tenancy model, a public API launch. A single annual test is a snapshot, though, and the year between tests needs its own controls: continuous scanning, dependency and supply chain scanning in the pipeline, security-focused code review on authorization paths, and a published vulnerability disclosure policy. A paid bug bounty is valuable once the basics are solid; launched before them, it mostly buys a flood of duplicate reports about the issues you already know you have.

How Infiniti Tech Partners approaches this

We work on both sides of the test. Before it, we do readiness work — fixing the obvious issues so the expensive tester time goes on the deep ones — and help scope the engagement and assess vendors. After it, we remediate findings at the root cause, including building the cross-tenant authorization test suites that stop the same class of bug returning. We run security testing within our own engagements, but where an auditor or enterprise buyer needs independent third-party attestation we coordinate with an independent firm rather than marking our own homework, because that independence is the point of the artefact. We keep a deliberately small number of concurrent engagements and plan the calendar about a quarter out. If a pentest is on your list for an upcoming audit or deal, the weeks before it are where most of the value is decided.