Skip to content

Industry

In a multi-tenant product, one finding affects every customer.

A SaaS product has one security question that outranks all the others: can one customer reach another customer's data.

Everything else is a normal application finding affecting one tenant. Tenant isolation failure is a single bug affecting your entire book of business at the same time, which is why it is tested first.

Tenant isolation is tested with two tenants

There is no way to test isolation with one account, and no scanner finds it. The test requires two real tenants and then asks, systematically, whether tenant one can reach anything belonging to tenant two.

Change an identifier in a request. Request an object by a known id from the other account's token. Call an endpoint the UI never exposes. Replay a link from one tenant while authenticated as the other. Each of those is a separate check and each has failed in real products.

Role count drives the test, not screen count

Scope is the access control matrix: roles multiplied by resources. A product with five roles and few screens takes longer to test properly than one with many screens and a single role.

Admin impersonation deserves particular attention, since most products build it and few test it. Who can trigger it, is it logged, can the impersonating user do things the impersonated user could not, and does it survive a session change.

Scoping around a weekly release

A test describes your product on the day it was tested. If you ship weekly, an annual test is a snapshot of software that no longer exists, so the useful pattern is a baseline plus targeted tests on change.

  • One scoped test of the authenticated application as a baseline
  • A targeted test whenever the authorization model or tenant model changes
  • A targeted test when a new externally reachable API or integration ships
  • A targeted test when an AI feature gains access to customer data or tools
  • Continuous dependency and configuration scanning in between

The SOC 2 timeline, and the mistake in it

SOC 2 does not require a penetration test. Your auditor usually asks for one because an independent dated report is the evidence they accept fastest for vulnerability identification.

The scheduling mistake is testing too late. For a Type 2, evidence has to fall inside the observation window, and a report delivered the week of the audit documents open findings with no time to close them. Test early enough that the retest also lands inside the window.

Security questionnaires are a sales cost

Once you sell to anything larger than a small business, security review becomes part of the sales cycle. A current test report with a named scope shortens that conversation measurably.

Which is the argument for testing before you need it. The deal that stalls on a questionnaire is more expensive than the test, and the test cannot be produced retroactively.

Questions

What should a SaaS penetration test cover?
Tenant isolation first, then the role and permission matrix, then authentication and session handling, API authorization on every endpoint, and admin or impersonation functionality. Tenant isolation ranks first because a single failure affects every customer at once.
How do you test multi-tenant isolation?
With two real tenants and credentials for each. Testing then systematically attempts to reach tenant two's objects from tenant one: altering identifiers, requesting known ids with the wrong token, calling endpoints the interface does not expose, and replaying links across accounts.
When should a SaaS company get its first penetration test?
Before the first enterprise security questionnaire, and before the SOC 2 observation window opens if an audit is planned. Both are deadlines you cannot meet retroactively.

Next step

Start with a scoping call.

Tell us what you need tested. Before any testing begins, the scope is written down and the agreement and rules of engagement are signed.

Book a scoping call