Overview
Engagements here cover multi-tenant B2B platforms, internal management and operations tools, developer platforms exposing public APIs, and vertical SaaS products carrying their customers’ regulated data. The buyer is usually a founder or a head of engineering with a signed contract waiting on a security review.
Testing is structured around the tenancy model first. Two separate organisations are provisioned, each with two accounts per role, and every object identifier surfaced anywhere in the product is replayed across that boundary: on read paths, write paths, exports, search, background jobs and webhooks alike. Only after the boundary is mapped does testing move outward to the rest of the surface.
What drives testing in this sector
Buying triggers
- Enterprise sales
- Security questionnaires and vendor reviews stall without a current independent test report. A test is frequently the last blocker on a signed contract.
- SOC 2 and ISO 27001
- Both are effectively table stakes for mid-market and enterprise buyers, and both expect evidence of regular testing.
- Blast radius
- One tenancy flaw exposes every customer simultaneously, which is the worst incident shape in the sector.
Where the engagement concentrates
Cross-tenant isolation
Every object identifier replayed across two separate organisations, on read and write paths alike: including exports, reports, search indexes, background jobs and webhooks.
Role and permission boundaries
Every role tested against every action, with particular attention to the gap between what the interface hides and what the API enforces.
Workspace and member lifecycle
Invitations, ownership transfer, demotion, removal and reactivation, testing whether access ends when the membership does.
SSO and SCIM
SAML assertion handling, signature validation, audience and recipient checks, JIT provisioning, and whether removing a user upstream removes their session downstream.
Subscription and plan enforcement
Feature gating enforced server-side or only in the bundle, seat and quota limits, trial extension, and downgrade paths that leave privileges behind.
API and integration surface
Personal access tokens, OAuth application scopes, webhook signing, and what a third-party integration can reach on the user’s behalf.
Track record
SaaS engagements have included internal management platforms where the critical findings were authentication bypass and access-control flaws reachable by any authenticated user, the pattern that recurs most often in this sector.
200+ projects delivered for 80+ organisations. Internal engagement log
Questions
Our buyers ask for a pentest report. What can we share?
Two documents are produced. The full technical report stays internal. A shareable attestation letter covering scope, dates, methodology, severity counts and remediation status, with no exploitation detail, is written specifically to be sent to customers and prospects under NDA.
How many tenants and roles do you need?
Two separate organisations, each with two accounts per role. Without a genuine second tenant, cross-tenant isolation can only be asserted, never demonstrated, and it is the single most important control on a SaaS platform.
Can you test continuously rather than annually?
Yes. A common arrangement is one full annual engagement plus shorter delta tests after significant releases, which keeps the attestation current without repeating the full scope each time.
How much does a penetration test cost for a SaaS platform?
Cost follows scope: application and API count, how many roles and tenancies exist, and whether cloud configuration is included. Multi-tenant platforms take longer because every role pair has to be tested across every tenancy boundary, and that is where the severe findings are.
What is the most common serious finding in SaaS?
Cross-tenant access. Multi-tenancy is one boundary repeated across every query, and it only takes one query that forgot the tenant filter. A single tenancy flaw exposes every customer simultaneously, which is the failure mode that ends product companies rather than merely embarrassing them.
Do you test our cloud infrastructure as well as the application?
It is scoped explicitly rather than assumed, and including it is usually the right call. The application and the infrastructure fail differently, and the path between the two, an application-reachable metadata endpoint that yields a role, is precisely the space a single-scope test misses.
Can you test before a Series A or enterprise sales push?
Yes, and that timing is common. Early testing costs less than retrofitting authorisation after your first enterprise buyer's security review, and the attestation letter is usually the document that unblocks the deal.
Do you test single sign-on and SCIM provisioning?
Yes. SSO and directory provisioning is where access outlives employment: whether deprovisioning actually revokes sessions, whether a SAML assertion can be replayed or re-signed, and whether SCIM can be made to grant a role the identity provider never sent.