Does SOC 2 require a penetration test?

No. The AICPA Trust Services Criteria never explicitly mandate a penetration test. However, auditors expect evidence of vulnerability identification and control monitoring under CC4.1 and CC7.1, and a penetration test is the most common way to provide it. In practice, most SOC 2 Type II audits request a recent pentest report.

What penetration testing evidence do SOC 2 auditors accept?

Auditors typically accept a third-party pentest report, automated testing results with a documented methodology, vulnerability scan output paired with remediation tickets, and retest confirmations. They look for recency, realistic scope covering systems that hold customer data, and a remediation trail. SOC 2 does not require a specific vendor or assessor certification the way PCI DSS does.

How often should you pentest for SOC 2 Type II?

At least annually, timed so the test falls within or near your observation window. Because a Type II report covers a period of typically 3 to 12 months, continuous scanning between annual tests evidences ongoing vulnerability identification under CC7.1 far better than a single snapshot.

Can automated penetration testing count as SOC 2 evidence?

Yes, auditors accept automated testing results when the methodology is documented and findings show real severity, dates, and remediation. Proof-of-exploit findings are stronger evidence than raw scanner output because they are confirmed rather than probable. Many teams pair automated continuous testing with an annual human-led test.

Does Sekura make me SOC 2 compliant?

No, and no tool can. Sekura produces continuous testing evidence with findings mapped to the Trust Services Criteria, which supports your audit. Compliance itself is a determination made by you and your licensed CPA firm based on the full scope of your controls.

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.

Key facts

No Trust Services Criterion contains a penetration testing mandate. The criteria require evaluations of internal control (CC4.1) and identification of vulnerabilities (CC7.1); pentesting is the accepted way to evidence both.
The points of focus for CC4.1 explicitly list penetration testing among the types of separate evaluations an entity may use.
CC7.1 expects procedures that identify configuration changes introducing new vulnerabilities and susceptibilities to newly discovered ones, which a single annual snapshot cannot evidence on its own.
A SOC 2 Type II report covers an observation window, commonly 3 to 12 months, so testing evidence dated outside that window carries little weight.
Manual pentest engagements run $30,000 to $150,000, which pushes most companies toward one annual test plus continuous automated testing in between.

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:

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.
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.

Is it recent, and does it fall inside or near the observation window?
Is the scope real? A test of one marketing site does not evidence controls over the production platform that holds customer data.
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:

An annual penetration test, ideally with human involvement for business-logic depth.
Continuous automated testing between engagements, producing dated findings and remediation trails across the whole observation window.
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:

Scoping. Which systems sit inside the audit boundary is your decision with your auditor.
Risk assessment. The CC3 series requires an entity-level risk assessment that no scanner performs.
Policy and process evidence. Access reviews, vendor management, change management, incident response.
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.