In board meetings and investor due diligence conversations across the SaaS industry, a dangerous equivalence has taken hold: "We have SOC2 Type 2, so we're secure." Security practitioners wince when they hear it because they know SOC2 Type 2 tells you almost nothing about whether a company can actually withstand an attack. It tells you whether a defined set of controls existed and were operated during an audit window. The distinction is not semantic — it has real consequences for how organizations invest in security and how they respond when something goes wrong.
TL;DR: SOC2 Type 2 audits whether your controls were consistently operating during the audit period. Penetration testing determines whether those controls work against a real attacker. SOC2 builds compliance credibility with customers. Penetration testing provides actual security assurance. You need both, and neither substitutes for the other.
What SOC2 Type 2 Actually Measures
A SOC2 Type 2 audit is an attestation by a licensed CPA firm that your organization's controls related to the chosen Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) were suitably designed and operating effectively over the audit period — typically six to twelve months.
The auditor does this through: reviewing policy documents, examining configuration screenshots, sampling logs to verify controls were followed, interviewing key personnel, and testing a representative sample of control activities. They are looking for consistency and documentation — evidence that you did what you said you would do, that you did it repeatedly, and that you have records proving it.
What the auditor does not do: attempt to exploit your web application, probe your network for vulnerabilities, test whether your MFA can be bypassed, evaluate whether your detection controls would catch a real intrusion, or verify that your incident response plan would work in a real crisis. These are not SOC2 audit activities. They are penetration testing and red team activities.
What Penetration Testing Actually Measures
A penetration test is an authorized simulation of a real attacker's attempt to compromise your environment. A skilled pentester does not review your documentation and accept it at face value — they actively attempt to defeat your security controls using the same techniques a malicious actor would use.
A web application penetration test finds injection vulnerabilities that your WAF didn't block, authentication bypasses that your access control policy didn't prevent, and authorization flaws that your role-based access controls didn't catch. An internal network penetration test finds lateral movement paths that your network segmentation policies didn't create, privilege escalation routes that your Active Directory hardening didn't close, and data access paths that your classification policy didn't account for.
The output is not an attestation — it is a list of findings, each representing a real security gap with demonstrated business impact. The value of a penetration test is proportional to the quality of its scope: the more representative of your actual threat model the scope is, the more useful the findings are.
Side-by-Side Comparison
| Dimension | SOC2 Type 2 Audit | Penetration Test |
|---|---|---|
| What it tests | Whether defined controls were operating during the audit period | Whether controls actually stop or detect attacks |
| Methodology | Document review, sampling, interviews | Active exploitation attempts using attacker techniques |
| Who performs it | Licensed CPA firm | Offensive security professionals |
| Primary output | Attestation report (clean/qualified) | Findings report with severity ratings and proof-of-concept evidence |
| Value to customers | High — compliance signal in vendor reviews | Medium — shows security maturity if shared |
| Value to security team | Low — confirms process not effectiveness | High — identifies real vulnerabilities to fix |
| Typical cadence | Annual (Type 2 covers 6-12 month period) | Annual minimum; continuous for mature programs |
| Can find unpatched CVEs? | No — auditor checks patching policy exists, not whether CVEs are patched | Yes — active scanning and exploitation testing |
| Can find auth bypass? | No — auditor checks MFA policy is documented | Yes — active testing of authentication mechanisms |
The Dangerous Gap
The danger is not that organizations have SOC2 Type 2 — it is that they stop there and believe they have addressed their security obligations. The attacker exploiting your BOLA vulnerability does not check whether you have a SOC2 report before proceeding. The ransomware group using your over-privileged service account to spread laterally does not care that your access control policy documentation is pristine.
Companies with SOC2 Type 2 certifications have been involved in some of the most significant breaches of the past several years. The certification tells customers about your compliance posture, not your security posture. These are genuinely different things, and conflating them creates exactly the false sense of security that allows real vulnerabilities to persist untested.
Why pentest findings actually strengthen your SOC2
There is a complementary relationship between the two: a penetration test that finds vulnerabilities, followed by documented remediation, produces the kind of evidence that SOC2 auditors value most — proof that your detection and response controls actually work, and that when vulnerabilities are identified, they are tracked and resolved. A clean pentest scope with no findings may actually raise auditor questions about whether the scope was adequate. Findings plus remediation evidence is a stronger SOC2 package than a narrow test with no findings.
How to Explain This Distinction to Your Board
The most effective frame is the analogy of fire safety versus fire drills. SOC2 is like a fire inspector confirming that your building has sprinklers, extinguishers, and marked exits — and that those things were in place consistently throughout the year. A penetration test is like actually setting a controlled fire to test whether the sprinklers actually deploy, the extinguishers actually work, and people actually know the exit routes. Both matter. Neither alone is sufficient.
Boards respond well to this framing because it makes clear that compliance and security serve different stakeholders: compliance documentation primarily serves customers and auditors, while security testing primarily serves the organization's actual risk management. Investing in only one of these gives you half the picture.
Have SOC2 but never tested whether it works?
Lorikeet Security's penetration testing complements your SOC2 program by validating that your controls actually stop attacks — not just that they exist on paper. Get findings your auditor and your security team will both value.
