SOC 2 Penetration Testing Guidance

What SOC 2 Type II Auditors Expect From Penetration Testing Evidence

SOC 2 penetration testing is the authorised simulation of attacks against the systems within a SOC 2 audit scope, designed to produce evidence that the security controls supporting the Trust Services Criteria operate effectively across the audit reporting period. An auditor is not interested in a scan output or a list of theoretical weaknesses. The auditor wants dated, scoped, methodology-stated proof that a competent tester actively tried to break the environment and that the organisation responded to what was found.

Trust Services Criteria (TSC) determine which controls the pentest evidence needs to support. The Common Criteria (CC) series is the primary target, particularly CC6 (logical and physical access controls) and CC7 (system operations, including vulnerability detection and response). Where Availability is part of the certified service, A1 criteria also draw on pentest evidence to show that resilience and capacity controls have been tested under realistic attack conditions.

Type I and Type II are not the same exercise wearing a different label. A Type I report assesses whether controls are suitably designed at a single point in time. A Type II report requires evidence that those same controls operated effectively across a defined reporting period, typically six to twelve months. A pentest supports Type I as a design check; for Type II, the auditor needs to see that testing, findings, and remediation actually happened inside the window being audited.

The rule that trips up most first-time Type II candidates is straightforward but frequently ignored: the pentest must occur within the audit reporting window for the evidence to be usable. A test run three months before the reporting period opens tells the auditor nothing about how the environment performed during the period under review. It may still be useful internally, but it carries significantly less weight as Type II evidence, and many auditors will ask for a fresh test dated inside the window.

Scoping the Pentest for SOC 2 Audit Readiness

Scope is the defined set of assets, networks, applications, and infrastructure that support the service under SOC 2 certification. It is not the whole company network by default, and it is not just the marketing website either. Scope should track the actual data flows and systems the certified service depends on, because that is what the auditor will cross-check against the pentest report. Every asset added to scope expands the attack surface the pentest must cover, so the aim is to match that surface to the systems genuinely supporting the certified service, not to test everything indiscriminately or to test only what is cheapest.

Three test types cover most SOC 2 scopes: external testing (internet-facing infrastructure), internal testing (systems and segments reachable once inside the network perimeter), and web application testing (the application logic itself, including authentication and session handling). Most Type II audits expect at least external and web application testing where a customer-facing product exists; internal testing is commonly added where the certified service processes or stores sensitive customer data on internal systems.

Methodology sits on a spectrum from black-box (no prior knowledge of the environment) through grey-box (limited access or credentials, similar to a standard user) to white-box (full access to source code and architecture). Auditors most commonly accept grey-box testing for SOC 2 because it mirrors a realistic attacker with some foothold, such as a compromised user account, without requiring the unrealistic zero-knowledge constraint of a pure black-box engagement.

The scope decision that causes the most damage to Type II evidence is leaving out an asset because it is inconvenient or costly to test. An auditor reviewing the report against the system description can see when a critical processing system, API, or data store has been quietly excluded, and that gap weakens the entire evidence set rather than just the excluded component. Build the scope by asking, for every candidate asset, whether it processes or stores data covered by a relevant TSC criterion, for example CC6.1 (logical access) or CC6.6 (boundary protection). If the answer is yes, it belongs in scope.

• Does this asset handle authentication or session data governed by CC6.1?
• Does this asset sit on the network boundary and fall under CC6.6?
• Does this asset process or store customer data relevant to the certified service?
• Would excluding this asset be visible to an auditor reading the system description?

Timing the Pentest Inside the Type II Audit Window

Best practice places the pentest early to mid-way through the reporting period, not at the end. Testing early leaves room to remediate and re-test findings before the period closes, which is exactly the evidence a Type II auditor is looking for: proof that a control operated, a weakness was found, and the organisation fixed it within the same window.

A practical schedule for a 12-month reporting period looks like this: scope definition in weeks 1-2, test execution in weeks 3-4, remediation of findings in weeks 5-8, re-test of fixed items in weeks 9-10, with the final report and re-test evidence ready well before audit close. This leaves several months of buffer for unexpected delays, staff availability, or a second round of fixes.

Running the test in the final weeks of the reporting period creates what is effectively a compliance time-lag: findings are identified, but there is no time left inside the window to fix them, re-test, and capture that evidence. An auditor is then left with an open finding and no remediation proof, which is a weaker position than a mid-period test with a documented fix. If the reporting period has already started and no test has been run, the correct action is to test immediately, present the results as evidence within the period, and add a short note explaining the timing gap rather than trying to disguise it.

A pentest completed before the reporting period start date does not count as Type II evidence, regardless of how thorough it was. Some organisations reuse a test from months earlier to save cost, but an auditor reviewing dates against the period will discount or reject it outright.

What an Audit-Ready Pentest Report Must Contain

An audit-ready pentest report contains six core sections: executive summary, scope and methodology, findings with risk ratings, CVSS (Common Vulnerability Scoring System) scores, remediation recommendations, and re-test results. Each section serves a different reader inside the audit process, and missing any one of them typically triggers a request for additional evidence from the auditor.

The date-range statement is the detail most vendor reports get wrong. A report is audit-usable when it states, in plain terms, something close to: "Systems in scope were tested between [date] and [date] using grey-box methodology." If the report does not confirm the test dates and those dates do not sit inside the Type II period, the auditor has no basis for accepting it as period evidence, no matter how detailed the findings section is.

"SOC 2 ready" is a phrase used in vendor marketing, not an auditor's determination. A provider can label a report however it likes; the auditor is the final judge of whether the content, dates, and methodology satisfy the criteria in question. Treat the report checklist above as the standard to hold any vendor report against before accepting it.

Remediation Evidence and Re-Testing Before the Audit Closes

Remediation evidence is the documented proof that a finding identified during the pentest has actually been closed, not just marked as fixed in a spreadsheet. Acceptable evidence typically includes a post-fix re-test report from the pentest provider, screenshots showing the vulnerable behaviour no longer occurring, change logs or Jira tickets tracking the fix through deployment, and deployment records confirming the fix reached production.

Re-testing becomes essential for critical and high-severity findings. An auditor reviewing a critical finding expects a formal re-test report confirming closure; a screenshot alone, without an independent re-test, is generally treated as weaker evidence and may not satisfy the criterion on its own.

Some findings will still be open when the reporting period closes, and that is not automatically a failure. The two acceptable paths are a formal, written risk acceptance signed off by management, explaining why the risk is tolerated and for how long, or a documented remediation plan with a firm deadline that falls after the period. Where a finding is fixed after the period end, the fix itself falls outside the audit window; the practical response is to communicate the lag to the auditor directly and document why the timeline slipped rather than leaving it unexplained.

• Re-test report from the original provider, confirming closure with dates.
• Change logs or ticket references (Jira, ServiceNow, or equivalent) tracking the fix from identification to deployment.
• Deployment or release records confirming the fix shipped to the live environment.
• Signed risk acceptance for findings deliberately left open, with a named approver and a review date.

A mixed exit, meaning a set of closed findings alongside a small number of formally accepted risks, is a realistic and defensible outcome. Auditors are generally more reassured by a well-documented remediation lifecycle than by a suspiciously clean report showing zero findings at all.

What Happens When the Pentest Finds a Critical Vulnerability? A Playbook

A critical finding mid-period is not a failed audit, it is a scenario with a defined response sequence. The steps below keep the response structured and produce the evidence an auditor needs to see.

1. Classify and triage. Confirm the actual severity, the business impact, and the specific assets affected before deciding on next steps.
2. Decide fix or accept. If the remaining time in the reporting period allows for remediation, fix it; if not, produce a formal, signed risk acceptance rather than leaving the finding undocumented.
3. Re-test. Use the same provider to verify the fix and produce a fresh, dated re-test report confirming closure.
4. Communicate to the auditor. Document the finding, the response taken, and the evidence gathered; proactive disclosure signals a mature security practice rather than a hidden problem.

A critical finding handled this way is not a pass/fail event for the audit. When it is triaged quickly, remediated or formally accepted, re-tested, and communicated clearly, it demonstrates that the security programme is active and that findings are taken seriously, which is closer to the outcome an auditor is actually looking for than a report with no findings at all.

Choosing Between In-House, Outsourced Specialist, or Compliance Platform Partner

Three routes exist for who actually performs the pentest, and the right choice depends on how much weight the auditor needs to place on independence and report quality. In-house testing is the lowest-cost option but carries the most risk to evidence quality: internal testers may lack the breadth of experience of a dedicated pentest team, reports vary in structure, and independence is harder to demonstrate because the tester and the tested organisation are the same entity.

An outsourced specialist typically produces the strongest evidence because the report is independent, structured around recognised methodology, and written in language an auditor already recognises. A compliance platform partner can be convenient where the pentest sits alongside other audit workflow tools, but the report still has to be checked on its own merits; convenience does not guarantee TSC alignment.

Before committing to any provider, run this three-question scorecard:

• Will you share a redacted sample report before we commit?
• Can you align the test dates to our Type II audit period?
• Do you include re-testing in the quote, or is it billed separately?

When a provider does share a sample report, run a quick three-step check before relying on it: confirm the report maps findings to TSC criteria language rather than generic vulnerability categories, confirm it scores severity using a recognised framework such as CVSS rather than an in-house scale, and confirm the scope and structure of the sample resembles what your own engagement would actually produce. A sample report that fails any of these three checks is a signal to keep looking, regardless of how the provider describes itself.

Questions to Ask Your Auditor Before You Book

Provider selection is only half the decision; the other half is confirming what your specific auditor expects before you commit budget. A short conversation up front avoids commissioning a test that technically works but does not satisfy this particular audit.

• What evidence do you need to see from the pentest, the full report or a specific extract mapped to individual TSC criteria?
• Does the test need to cover every applicable TSC criterion, or are you focused on specific ones for this audit?
• Is there a minimum test date range you require inside the reporting period, or is any date within the window acceptable?
• Would you accept a single mid-period test, or do you expect testing evidence spread across the period?
• How do you want open findings presented, as a signed risk acceptance, a remediation plan with a deadline, or both?

Do not invent a budget expectation before you have a scope. Costs vary widely depending on the number of assets, methodology, and provider, so request a quote against your actual scope rather than a generic figure, and confirm in writing whether re-testing is included or billed separately.

To see how an outsourced specialist structures SOC 2 audit-ready pentest reports, visit our penetration testing services page.

Is Penetration Testing Required for SOC 2?

No, SOC 2 does not formally mandate penetration testing in the AICPA criteria text, but the Common Criteria and related monitoring criteria make it a practical expectation in almost every Type II audit. Criteria such as CC5.1 (control activities), CC7.2 (monitoring for anomalies), and CC7.3 (evaluating and responding to security events) are difficult to evidence convincingly without some form of active security testing, and a pentest is the accepted way to demonstrate that testing. Some audit documentation also groups ongoing system-change monitoring under CT-related controls; where that applies to your certified service, pentest evidence typically supports those criteria too.

A Type II audit submitted without any pentest evidence is unusual and hard for an organisation to defend, because the auditor will ask how the organisation confirmed its controls actually resist attack rather than simply existing on paper. The accurate position is that penetration testing is formally optional but practically expected. Framing it any more strongly than that risks overstating what the standard requires; framing it as unnecessary risks leaving a genuine evidence gap in the audit.

How Often Should You Run a Pentest for SOC 2?

At least once within the Type II reporting period is the minimum baseline for penetration testing under SOC 2. Annual testing is the common rule of thumb, and it works reasonably well for organisations with a stable environment and a twelve-month reporting period.

A single test scheduled right at the start of a twelve-month period leaves the remaining nine to ten months without fresh tested evidence, which is a weaker position than an auditor generally wants to see for a period meant to demonstrate ongoing operating effectiveness. Running the test mid-period, or splitting coverage across two tests within a twelve-month window, gives a more defensible spread of evidence across the reporting period.

Continuous vulnerability scanning or monitoring tools are a useful complement but do not replace a periodic, exploit-based pentest; auditors treat automated scanning and active penetration testing as different forms of evidence supporting different aspects of the control environment, and one is not an acceptable substitute for the other in a Type II submission.

• Run at least one test inside every Type II reporting period, positioned early to mid-period rather than at the very start or very end.
• Re-run the test after any material change: a major feature release, a new infrastructure environment, or a change to how customer data is processed or stored.
• Treat "annual" as a safe default, not a rule the auditor actually cites; the real expectation is evidence of testing that covers the reporting period, however that is achieved.

Frequently Asked Questions