Penetration testing for SaaS companies
Before a larger customer signs, their security team asks for your latest penetration test report. Your SOC 2 auditor will want one too. We test your product the way a customer trying to reach another customer's data would, and write the report both of them are looking for.
What we test in a SaaS product
Scanners find missing headers and old libraries. The flaws that end up in a breach notice are usually about who can see what, so that is where we spend most of the testing days.
| Area | What we try to break |
|---|---|
| Tenant isolation | Whether one customer can read or change another customer's data through IDs in the API, exports, search, file links or shared caches. We test with accounts in two separate tenants. |
| Roles and permissions | Every role you have, including invited users, read-only seats and admins, checked against every action the API allows, including the ones your interface hides. |
| Authentication | Login, MFA, password reset, session handling, API keys, OAuth and SSO set-up, and what happens when a user is removed from an account. |
| APIs and integrations | REST and GraphQL endpoints, webhooks, file imports and URL fetchers, tested for broken authorization, data exposure and server-side request forgery. |
| Plans and billing logic | Whether plan limits and paid features are enforced on the server, or can be unlocked by changing a request. |
| External attack surface | Forgotten subdomains, exposed admin panels and staging environments, and open services around your product. |
A report your SOC 2 auditor will accept
SOC 2 does not name penetration testing as a requirement. In practice auditors expect it: the Trust Services Criteria list penetration testing among the evaluations that show your controls work (CC4.1), and vulnerability management sits under CC7.1. Most auditors want to see one test a year.
For a Type II report, test inside your observation period and fix what we find before it ends. A retest gives you the evidence that the fixes worked. See testing for compliance for how SOC 2 compares with ISO 27001 and PCI DSS.
What the report gives you
- The scope, testing dates and method, stated clearly
- Every finding confirmed by a tester, with a severity and a fix
- An executive summary you can share with customers
- A detailed section your developers can work from
- An updated report after the retest, showing what is resolved
Related reading
SaaS testing questions
Do we need a penetration test for SOC 2?
SOC 2 does not require one by name, but most auditors expect an annual penetration test as evidence for the monitoring and vulnerability management criteria. Customers reviewing your SOC 2 report will usually ask for the pentest report too.
When should we test in our audit cycle?
Inside your observation period, early enough to fix the findings and retest before the period ends. For a first Type I report, test before the audit date so the report reflects the fixed system.
Should you test production or staging?
Staging, where we can work freely without affecting customers, as long as it runs the same code and configuration as production. We still check the production attack surface from outside.
What do you need from us to start?
Accounts for every role, ideally in two separate tenants so we can test the boundary between customers, plus API documentation or a collection if you have one.
How long does it take?
Most single SaaS products take one to two weeks of testing, depending on roles, features and integrations. Testing can start within 48 hours of a signed scope.
Start your security assessment.
Tell us about your application, architecture or compliance requirements. Our team will scope a penetration test around them.