Scope and authorize
We agree the environment, the plan tiers in scope and the test window in writing.
A multi-tenant test built around the question your own customers ask in their security reviews: can anyone using your product reach data that belongs to someone else? We sign up as two tenants and try.
Everything in a standard web application test applies to a SaaS product — and then tenancy sits underneath all of it. Isolation has to hold in the database, in the cache, in background jobs, in file storage, in exports and in every integration you offer.
We test with two live tenants side by side, which is the only way to prove separation rather than assume it. The report is written so you can hand it straight to a customer or an auditor.
Typically one to three weeks, depending on role matrix, integrations and plan tiers.
We agree the environment, the plan tiers in scope and the test window in writing.
We work from two separate tenants with the full role matrix in each, so isolation is tested rather than assumed.
Identifiers, tokens, exports, uploads, integrations and background jobs are all tested for leakage between tenants.
We check whether paid features, quotas and seat limits hold when the client stops cooperating.
You get a report suitable for customer security reviews, a readout and a retest of your fixes.
Real examples of what this engagement uncovers — anonymized, and never every time. What matters is that you find out before somebody else does.
A tenant identifier accepted from the client and trusted by the server
Exports, reports or search indexes that were never scoped to one tenant
SSO configurations that let an attacker-controlled domain assert your users
De-provisioned users keeping access through an old token or API key
Plan limits enforced only in the interface
These programs call for this test, or their assessors and your customers expect it. If one of them is on your desk, readiness and testing come from the same team.
For multi-tenant platforms, customers want proof that one tenant can’t reach another tenant’s data — the question behind most Confidentiality commitments.
SOC 2 readinessApplication and interface security controls, and cross-tenant data access in particular, are what buyers reading your STAR entry most want to see evidenced.
CSA STAR readinessControl CA-8 requires penetration testing at Moderate and High, and FedRAMP’s penetration test guidance includes tenant-to-tenant and tenant-to-management attack vectors. Testing early shows what a 3PAO’s test is likely to find.
FedRAMP readinessNIST SP 800-53 control CA-8 calls for penetration testing at the higher baselines, and state buyers routinely ask for a recent test of the service itself, including tenant isolation.
GovRAMP & TX-RAMP readinessArticle 25 lists penetration testing among the tests a financial entity’s resilience program covers, and customers relying on your platform for an important function will ask to see recent results.
DORA readinessAgencies weighing your report want confidence that the service itself resists attack, and the ISM’s software development guidelines expect applications to be security tested.
IRAP readinessGives your customers’ third-party risk teams the independent test evidence and summary letter they ask for when they review you as a vendor.
Vendor & third-party risk readinessMissing something on this list? Bring it to the call — we scope around what you have.
Find and prove the weaknesses in your web applications before attackers do.
Read moreKeep the APIs that connect your products, partners and data from becoming the way in.
Read moreKeep your iOS and Android apps — and the services behind them — out of attackers’ hands.
Read moreMake sure your desktop apps, thick clients, browser extensions and agents don’t open a back door.
Read moreNot sure where to start? One of our testers reviews your internet-facing footprint and sends you a short summary of what an attacker would see — free. Nothing you don’t own is ever touched, and there’s no sales sequence.
Free. No obligation.