Shipping a sensitive change
Focus on new permissions, customer administration, billing, integrations, or identity flows and the existing features they affect.
For SaaS product and engineering teams
SaaS penetration
SaaS penetration
testing.
SaaS penetration testing focuses on the security boundaries of multi-tenant products: tenant isolation, shared workspaces, SSO, roles, and third-party integrations. Balhence assesses those boundaries with controlled accounts, confirms each reported finding by hand, and provides evidence and practical fixes for engineering, SOC 2 audits, and customer security reviews.
Why now?
SaaS penetration testing for releases and customer reviews
A new SSO feature needs a different look from a first assessment of the whole product. Start with the decision your team needs to make.
A customer needs a report
Check what they expect from the scope, report, and re-test before booking. Their reviewer decides whether the evidence meets the request.
You need a starting point
Assess the connected product and give engineering a list of confirmed issues, priorities, and areas that still need a closer look.
SaaS-specific coverage
What we test in a multi-tenant SaaS product
An export, background job, or admin action still needs to respect the right customer's boundaries. We follow the workflows through those less visible parts.
Tenant isolation
Check records, files, search, exports, shared links, and background jobs using controlled tenants. Where sharing is allowed, we document the exception and test its limits.
Roles and customer administration
Owners, admins, members, and guests need different permissions. We check what happens when someone is invited, moved, given ownership, or removed.
SSO and connected identities
Review how SSO, account linking, recovery, sessions, and provisioning affect membership. We agree on the identity-provider configurations and test accounts first.
Use separate controlled browsers to describe which workspace and account state each session should retain. The session isolation field note illustrates the ownership problem; your SaaS membership rules define the expected result.
Integrations and product state
Check API keys, webhooks, service accounts, billing permissions, approvals, and background work. Third-party platforms stay out of scope without their authorization.
Planning the test
Planning your SaaS penetration testing scope
A short walkthrough of the modules, APIs, roles, and integrations helps us scope the work. For isolation checks, we need two controlled tenants and representative accounts. If your team is in India, use the remote SaaS VAPT brief to plan the testing window, evidence rules and report deadline.
Prepare access
Make the environment representative
Use a stable build, synthetic records, working role-specific accounts, API documentation, and a technical contact. Note differences from production, especially SSO, billing, feature flags, and background processing.
The SaaS pentest readiness checklist helps your team prepare these details.
Agree boundaries
Keep testing controlled
Written authorization defines hosts, roles, safe data, request limits, contacts, and stop conditions. Production testing requires explicit safeguards. Destructive testing, load testing, cloud configuration review, and source review are not included by default.
If the assessment needs to cover IAM permissions, storage access or workload boundaries, agree a separate cloud penetration testing scope alongside the application test. Record the responsibilities and shared findings once across both workstreams.
Need broader coverage? See the full security capability map.
SaaS tenant and membership worksheet
Tenant isolation includes deliberate sharing and changes to membership. Use this synthetic two-tenant example to explain the rules your product should enforce. Seed comparable records in tenants A and B, then provide controlled accounts for the agreed relationships.
| Relationship | Intended boundary | Preparation needed |
|---|---|---|
| Member in A / records in B | No access without an explicit sharing rule | Comparable synthetic files, records, and exports |
| Owner and member in A | Customer administration follows documented role permissions | Both roles and a membership policy |
| Guest / shared item from A | Access is limited to the permitted item and actions | Controlled guest and a documented sharing exception |
| Removed member / previous workspace | Sessions and access change according to the revocation policy | Removal workflow and expected access timing |
Document SSO provisioning, background processing, or feature flags that change these expectations. Carry unavailable relationships into the coverage limits so reviewers can interpret the result. The pentest report guide explains how scope, confirmed findings, and re-test status should appear together.
How SaaS penetration testing works
- Agree the scope, representative tenants and roles, test data, and safety rules.
- Map expected access across workspaces, SSO, APIs, and integrations.
- Assess the agreed controls and confirm findings with evidence.
- Deliver the report, discuss fixes, and complete the agreed re-test.
The report
SaaS pentest reports and remediation evidence
A tester verifies every reported finding. You'll see the evidence, the demonstrated impact, and what we couldn't check. AI assists the work; it doesn't decide whether an issue is confirmed.
The redacted draft-authorization story shows how we explain those distinctions. It's an educational reconstruction, not a client endorsement or confirmation of a deployed fix.
- 01Leadership summaryProduct risks, priorities, scope, and material limitations.
- 02Engineering findingsPrerequisites, evidence, affected roles, business impact, and practical remediation guidance.
- 03Coverage recordIncluded tenants, workflows, interfaces, constraints, and exclusions.
- 04Agreed follow-upA findings walkthrough and bounded re-test when included in the agreement.
Evidence for your customer security review or SOC 2 audit
A reviewer needs to know which tenants, roles, and workflows were tested. We provide the executive summary, technical findings, coverage limits, and an agreed re-test record. For an audit, start with SOC 2 penetration testing and confirm the expected evidence with your auditor.
When the product changes frequently, PTaaS and recurring testing can provide a planned follow-up cadence.
Before you book
SaaS penetration testing FAQ
Agree on these details before reserving engineering time.
Does a SaaS pentest satisfy SOC 2?
A SaaS pentest can support technical evidence for the audit, but it does not establish SOC 2 compliance on its own. Your auditor determines whether your overall controls and evidence meet the criteria. See testing for SOC 2 for scope and timing.
How much does a SaaS penetration test cost?
Roles, tenant relationships, workflow depth, integrations, and environment readiness drive effort more than screen counts. Reporting and re-test requirements also matter. We scope the work before quoting; the pentest pricing guide explains what to compare.
Should the web app and API be tested together?
Usually they share identity and customer data, so connected coverage can be useful. The agreement names what is included. Compare web application testing and API testing when deciding where the boundary belongs.
Can the report support an enterprise customer's review?
It can provide scoped testing evidence, findings, and agreed re-test results. Confirm the recipient's requirements first. A penetration test is not a compliance certification, a guarantee of customer acceptance, or proof that the whole product is vulnerability-free.
How do we plan around releases and fixes?
Share your deadline and planned changes during scoping. We confirm availability after reviewing scope and access. Allow time for reporting, remediation, and any included re-test; new features or material changes may need a revised scope.
Plan your SaaS test
Plan your SaaS penetration testing scope.
A short description, the main roles, and any deadline are enough to start. Leave credentials, tokens, and customer data out of the enquiry.