Penetration Testing for SOC 2: What Auditors Expect

Penetration testing for SOC 2 is not strictly mandated by the AICPA Trust Services Criteria, but auditors expect vulnerability management evidence and commonly request a penetration test under CC4.1 and CC7.1. Most SOC 2 Type II audits ask for a recent pentest report plus proof of ongoing scanning. The strongest pattern is an annual test combined with continuous testing between engagements.

What SOC 2 actually requires

SOC 2 is an attestation against the AICPA Trust Services Criteria, not a checklist with a pentest line item.

Two criteria drive the expectation in practice:

1. CC4.1: the entity selects, develops, and performs ongoing and separate evaluations to ascertain whether the components of internal control are present and functioning. Its points of focus name penetration testing as one such evaluation.
2. CC7.1: the entity uses detection and monitoring procedures to identify changes to configurations that result in new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.

Neither says you must buy a pentest. Both are hard to evidence without one. The auditor is assessing whether your controls operate, and a penetration test is the most direct proof that your vulnerability identification control actually works.

Penetration testing for SOC 2: what auditors accept

Auditors ask three questions about your testing evidence.

1. Is it recent, and does it fall inside or near the observation window?
2. Is the scope real? A test of one marketing site does not evidence controls over the production platform that holds customer data.
3. Did you remediate? Findings with no remediation trail are worse than no test, because they document a control that identified issues nobody acted on.

Accepted evidence typically includes a third-party pentest report, automated testing results with a documented methodology, vulnerability scan output tied to remediation tickets, and retest confirmations. SOC 2 does not require a specific vendor or assessor certification, unlike PCI DSS. Our penetration testing guide explains how these engagements are structured and reported.

The strong pattern: annual pentest plus continuous testing

One annual test satisfies the letter of most auditor requests. It evidences CC7.1 poorly, because CC7.1 is about ongoing identification, not snapshots.

The pattern that holds up in audits:

1. An annual penetration test, ideally with human involvement for business-logic depth.
2. Continuous automated testing between engagements, producing dated findings and remediation trails across the whole observation window.
3. Findings mapped to the Trust Services Criteria, so each piece of evidence answers a specific criterion instead of arriving as an unstructured PDF.

Proof-of-exploit findings shorten audit prep for a simple reason: there is nothing to argue about. A finding with a working exploit, a CVSS v3.1 score, a timestamp, and a mapped criterion is evidence an auditor can file. A list of 400 scanner possibles is a triage project that lands on your team two weeks before fieldwork. Continuous penetration testing generates the dated trail across your entire window.

What still needs you and your auditor

No tool makes you SOC 2 compliant, and you should distrust any vendor claiming otherwise.

Still on your side of the table:

1. Scoping. Which systems sit inside the audit boundary is your decision with your auditor.
2. Risk assessment. The CC3 series requires an entity-level risk assessment that no scanner performs.
3. Policy and process evidence. Access reviews, vendor management, change management, incident response.
4. The audit itself. A licensed CPA firm performs the examination and issues the report.

Testing evidence is one input among many. It is often the most painful input to produce, which is why automating it matters, but it remains an input.

Where Sekura fits

Sekura produces the testing evidence layer. Every scan runs a 7-phase multi-agent pipeline, and every reported finding carries a deterministic proof-of-exploit, a CVSS v3.1 score, and SARIF output. Findings map to SOC 2 among 14 supported frameworks, including ISO 27001, PCI DSS, HIPAA, and NIST 800-53. Scans run in your own GitHub Actions runner or behind your firewall, which keeps evidence generation inside your environment.

What Sekura does not do: scope your audit, perform your risk assessment, write your policies, or attest to anything. Compliance is a determination made by you and your CPA firm. We make vulnerability management evidence continuous, dated, and mapped to criteria, and that is the honest limit of the claim. The full pipeline is described on product.

I think the companies that treat SOC 2 evidence as a byproduct of real security testing, rather than a scramble before the window closes, end up with better audits and better security at the same time.