That is exactly the engagement this page describes: a focused, evidence-producing penetration test scoped to satisfy a SOC 2 examination, delivered with a report your auditor will accept without a follow-up call asking what methodology was used.
Type to search across the blog, guides, tools, and services.
A SOC 2 report tells your customers that an independent party has examined how you protect their data. Your auditor assesses the controls, but the security testing behind the CC4 monitoring criteria and the CC7 vulnerability-management criteria has to come from somewhere, and increasingly auditors expect that to be an independent penetration test performed by someone who does not build or run the system.
That is exactly the engagement this page describes: a focused, evidence-producing penetration test scoped to satisfy a SOC 2 examination, delivered with a report your auditor will accept without a follow-up call asking what methodology was used.
SOC 2 is not prescriptive the way PCI DSS is. It does not contain a line that says run a penetration test every twelve months. Instead it asks, through the Common Criteria, whether you identify vulnerabilities and act on them. In practice almost every auditor treats an annual independent penetration test as the cleanest way to evidence CC7.1 and CC4.1, which is why buyers increasingly ask for it during vendor security reviews.
The teams that stumble here are usually not insecure. They scanned their app with an automated tool, pasted the output into the audit, and were told it was not enough, because a scanner cannot find business-logic flaws, broken access control between tenants, or an authorization gap in an API. An independent tester working through your application by hand is what turns we ran a scan into an independent expert tested this, and here is the signed report.
There is also a commercial reason that matters more than the audit itself. Your enterprise prospects will ask for the report during procurement. A clear, professional report shortens their security review and removes a blocker to closing the deal, so the test often pays for itself the first time it unsticks a contract.
The most important test for a SaaS platform: can a user in one tenant reach data belonging to another by changing an identifier, a token, or a request path? We test authenticated as multiple accounts and attempt horizontal and vertical privilege escalation across every object type.
Password reset flows, session fixation, token handling, multi-factor bypasses, and the logic around invitation and account-recovery links, all of which map directly to the security and confidentiality criteria.
Modern SaaS is an API with a UI attached. We test the API directly, checking that every endpoint enforces authorization server-side and never trusts a client-supplied role, tenant id, or object reference.
The OWASP-aligned core: SQL injection, command injection, template injection, and cross-site scripting, plus exposed admin interfaces, verbose errors, and secrets leaked in client-side code.
You receive a report written for two readers at once: your auditor, who needs methodology and evidence, and your engineering team, who needs to fix things. It contains:
An endpoint returns a record by id without checking that the record belongs to the caller's tenant, so changing the id returns another customer's data. Invisible to scanners, catastrophic in a SOC 2 context.
The frontend hides admin features, but the API accepts a role value from the client, so a normal user can call the admin endpoint directly.
Login, password reset, and one-time-code endpoints that accept unlimited attempts, enabling credential stuffing and code brute-forcing.
API keys or internal endpoints shipped inside the JavaScript bundle, recoverable by anyone who opens developer tools.
SOC 2 does not explicitly mandate one the way PCI DSS does. However, most auditors treat an independent annual penetration test as the standard way to evidence the vulnerability-management and monitoring criteria (CC7 and CC4), and enterprise customers usually ask to see the report during procurement. In practice it is expected.
A scan is automated and finds known, signature-based issues. A penetration test is performed by a person who manually finds what scanners cannot: broken access control between tenants, business-logic flaws, and authorization gaps in your API. A scan alone is often rejected as insufficient.
For a typical single SaaS application, testing takes about one to two weeks depending on size and number of user roles, followed by the report. We agree scope and timeline in a short scoping call first, so there are no surprises for your audit deadline.
Yes. It names the methodology, rates findings by severity with reproduction steps, and maps each to the relevant Trust Services Criteria, which is exactly what auditors need. The retest gives you a clean final version showing findings resolved.
Yes, retesting is included. Once your team remediates, we verify the fixes and issue an updated report, so the version you hand your auditor and customers shows the issues resolved rather than open.
Book a free 30-minute scoping call. We agree the scope, timeline, and a fixed price up front — no obligation, and no surprises for your deadline.