SOC 2 Type I vs Type II: How Penetration Testing Fits Into Your Audit

TL;DR: SOC 2 does not explicitly mandate penetration testing, but pentest evidence maps directly to Trust Service Criteria CC6.1, CC7.1, CC7.2, and CC8.1 -- and auditors increasingly expect it. For Type I, a single point-in-time pentest demonstrates control design. For Type II, you need to prove those controls worked consistently over a 6-12 month period. Continuous automated pentesting generates the ongoing evidence that Type II demands, turning what used to be a scramble before audit season into a year-round, audit-ready posture.

If your SaaS company is pursuing SOC 2 compliance -- or renewing an existing report -- penetration testing is one of the highest-leverage activities you can invest in. Not because the AICPA explicitly requires it. But because of what it proves: that your security controls actually work, not just that they exist on paper.

The distinction matters enormously when you understand the difference between Type I and Type II, and when you see how auditors actually evaluate evidence during the examination.

Understanding SOC 2 Type I vs Type II

SOC 2 is a framework developed by the American Institute of Certified Public Accountants (AICPA) for evaluating an organization's controls relevant to security, availability, processing integrity, confidentiality, and privacy. These are the five Trust Service Categories, and most SaaS organizations scope their audit to at least Security (the "Common Criteria") and one or two additional categories.

Type I evaluates whether your controls are suitably designed at a specific point in time. Think of it as a snapshot. The auditor examines your control descriptions, reviews your policies, and assesses whether the controls you have in place are reasonably designed to meet the Trust Service Criteria. If you say you perform vulnerability assessments, the auditor checks that you have a process for doing so. Type I does not test whether those controls consistently function over time.

Type II evaluates whether those same controls operated effectively over a defined period, typically six to twelve months. This is where the real rigor lies. The auditor does not just ask whether you have a vulnerability assessment process -- they want evidence that the process ran as described, repeatedly, throughout the observation window. They sample evidence. They look for gaps. They want to see that your controls did not just exist on Day 1 but continued to operate on Day 47, Day 153, and Day 302.

This distinction is critical because most enterprise buyers and procurement teams require Type II reports from their vendors. Type I is often treated as a stepping stone -- useful for demonstrating commitment to compliance, but insufficient for satisfying vendor risk management requirements at organizations that handle sensitive data.

The Trust Service Criteria That Pentesting Addresses

Penetration testing does not map to a single SOC 2 criterion. It provides evidence across multiple Common Criteria controls, which is why auditors find it so valuable.

CC6.1 -- Logical and Physical Access Controls. This criterion requires organizations to implement logical access security measures to protect against unauthorized access. Penetration testing directly validates these controls by attempting to bypass authentication mechanisms, escalate privileges, and access systems or data without authorization. A pentest report that documents failed attempts to bypass your access controls is strong evidence that CC6.1 controls are functioning. Conversely, a pentest that successfully bypasses access controls tells you -- and your auditor -- exactly where remediation is needed.

CC7.1 -- System Monitoring. Organizations must detect anomalies and events that could indicate security incidents. Penetration testing exercises your monitoring and detection capabilities in a realistic way. If your pentest generates attack traffic and your SIEM or monitoring stack fails to alert on it, that is a finding -- not against the pentest, but against your monitoring controls. If your SOC detects and responds to the pentest activity, that is evidence that CC7.1 is working.

CC7.2 -- Anomaly and Event Detection and Response. Closely related to CC7.1, this criterion focuses on evaluating detected events to determine whether they constitute incidents. Pentesting generates the kind of events that your incident response process should detect, classify, and respond to. The combination of pentest activity logs and incident response records creates a powerful evidence trail.

CC8.1 -- Change Management. This criterion requires that changes to infrastructure and software are authorized, tested, and approved. Penetration testing after significant changes validates that the change management process did not introduce exploitable vulnerabilities. When you can show that a pentest was performed after each major release and that the results informed go/no-go decisions, you are providing direct evidence of CC8.1 control effectiveness.

Why Auditors Expect Pentest Evidence

Walk into a SOC 2 Type II readiness assessment without any penetration testing evidence and watch the auditor's reaction. While they will not cite a specific AICPA requirement that mandates pentesting, they will note the absence.

The reason is practical. SOC 2 auditors are evaluating whether your controls are effective -- not just whether they exist. Vulnerability scans tell you what might be vulnerable. Penetration testing tells you what is actually exploitable. That distinction matters to auditors because the Trust Service Criteria are fundamentally about risk mitigation, and you cannot demonstrate risk mitigation without testing whether your defenses hold up under realistic attack conditions.

Most CPA firms that perform SOC 2 examinations have developed supplementary guidance for their engagement teams that lists penetration testing as expected evidence for CC6.1 and CC7.1. Some firms include it in their standard request lists alongside items like access reviews, change management logs, and incident response records. Others will not ask for it by name but will probe during walkthroughs to understand how you validate that access controls and monitoring are actually working -- and pentesting is the most credible answer to that question.

The trend is accelerating. As the threat landscape evolves and high-profile breaches continue to make headlines, auditors are raising the bar on what constitutes sufficient evidence. Penetration testing is quickly moving from "nice to have" to "expected" in SOC 2 engagements.

The Type II Problem: Operating Effectiveness Over Time

Here is where most organizations struggle. A single annual penetration test might satisfy a Type I engagement, where the auditor only needs to see that controls are designed appropriately at a point in time. For Type II, the standard is higher: the auditor needs evidence that controls operated effectively throughout the observation period.

Consider what this means in practice. Your SOC 2 Type II observation period runs from January 1 through December 31. You perform a penetration test in March. The auditor reviews your evidence in January of the following year. What evidence do you have that your access controls, monitoring, and change management processes were effective from April through December? The March pentest covers the state of your environment at one moment. It says nothing about the deployments you shipped in June, the infrastructure changes you made in September, or the new API endpoints you exposed in November.

This is the "operating effectiveness over time" problem, and it is the single biggest gap that organizations face in SOC 2 Type II audits related to security testing. Auditors are trained to look for this gap. During the examination, they will ask: "You performed a pentest in Q1 -- how do you know your controls continued to operate effectively in Q2, Q3, and Q4?"

The traditional answers are weak. "We didn't make significant changes" is unverifiable and usually untrue for any active SaaS product. "We run vulnerability scans monthly" is better but does not demonstrate exploitation testing. "We have continuous monitoring" addresses CC7.1 but not the proactive testing component.

Continuous Automated Pentesting as Ongoing Evidence

The solution is to match your testing cadence to your audit observation period. If your Type II window is twelve months, you need pentesting evidence distributed across those twelve months. Continuous automated pentesting makes this economically and operationally feasible.

With a platform like ThreatExploit, you can run automated penetration tests on a monthly, biweekly, or even weekly cadence. Each test produces a timestamped report documenting what was tested, what was found, and what was exploitable. Over the course of a twelve-month observation period, you accumulate a body of evidence that tells a compelling story: your security controls were tested regularly, findings were identified and remediated promptly, and your security posture was validated consistently.

This evidence directly addresses the auditor's core concern. Instead of a single report from March, you present twelve reports -- one from each month -- showing that controls operated effectively throughout the period. The auditor can sample any month and find evidence. They can see the remediation timeline for findings. They can observe whether the same vulnerabilities recur (indicating control gaps) or are resolved and stay resolved (indicating effective controls).

The cost difference is substantial. Running twelve manual pentests per year would be prohibitively expensive for most organizations. Automated pentesting runs at a fraction of the cost, making continuous testing practical even for startups and mid-market SaaS companies that are pursuing SOC 2 for the first time.

Formatting Pentest Reports for SOC 2 Auditors

Not all pentest reports are equally useful to auditors. A report that lists vulnerabilities by CVSS score is helpful for your engineering team but may not map cleanly to the evidence your auditor needs. To maximize the value of your pentest evidence for SOC 2, structure your reports with the audit in mind.

Map findings to Trust Service Criteria. Each finding should reference the relevant Common Criteria control. An authentication bypass finding maps to CC6.1. A finding that your monitoring failed to detect attack traffic maps to CC7.1. This mapping saves the auditor time and demonstrates that you understand how pentesting relates to your SOC 2 scope.

Document scope and methodology. Auditors want to know what was tested and how. A report that says "we tested the application" is less useful than one that documents the specific systems, endpoints, and attack vectors in scope. Include the testing methodology -- was it black box, gray box, or white box? What tools were used? What was the testing timeframe?

Include negative findings. A finding that says "authentication controls were tested using X, Y, and Z techniques and no bypasses were identified" is valuable evidence for CC6.1. Many pentest reports focus exclusively on positive findings (vulnerabilities discovered) and omit the negative findings (controls that held). For SOC 2 purposes, both are important.

Show remediation status. For Type II, the auditor wants to see the lifecycle: vulnerability identified, remediated, and verified. Reports that include remediation verification -- a retest confirming the fix -- are significantly stronger than reports that end at the finding stage. Continuous testing naturally creates this lifecycle because the next test cycle validates whether previous findings were addressed.

Provide executive summaries. Your auditor is not a penetration tester. Include an executive summary that translates technical findings into control effectiveness language. Instead of "SQL injection in login form parameter," write "Access control weakness identified in authentication mechanism (CC6.1) -- remediated and verified in subsequent test."

Building a Year-Round Audit-Ready Posture

The organizations that find SOC 2 Type II audits painful are the ones that treat compliance as a project. They scramble to gather evidence, discover gaps in documentation, and rush to perform security testing in the weeks before the auditor arrives. The organizations that find audits routine are the ones that treat compliance as a continuous process.

Continuous automated pentesting is a key enabler of this shift. When testing runs automatically on a regular cadence, evidence accumulates without manual effort. Reports are generated and archived. Findings are tracked and remediated. By the time the auditor requests evidence, it already exists -- organized, timestamped, and mapped to the relevant criteria.

For SaaS security teams, this approach has a secondary benefit: it improves actual security, not just audit readiness. The vulnerabilities caught by continuous testing are real exploitable weaknesses in your product. Fixing them protects your customers. The overlap between "audit-ready" and "actually secure" becomes nearly complete, which is the entire point of SOC 2 in the first place.

Start by mapping your current testing cadence to your Type II observation period. Identify the gaps -- the months where you have no testing evidence. Then implement automated pentesting to fill those gaps. Within one audit cycle, you will have transformed your SOC 2 evidence package from a point-in-time snapshot into a continuous record of control effectiveness.