Overview
The evidence artefact your auditor expects under CC4.1 and CC7.1, produced in the shape they already accept.
Framework reference
- Framework
- AICPA SOC 2, Trust Services Criteria
- Relevant criteria
- CC4.1 monitoring of controls, CC7.1 vulnerability detection, CC7.2 monitoring for anomalies
- Type I vs Type II
- Type I tests design at a point in time; Type II tests operating effectiveness over a period, typically 3 to 12 months
- Timing
- Before the observation window opens, so remediation lands inside the period
- Deliverable
- Technical report, auditor summary and signed retest attestation
- Cadence
- Annual, aligned to the audit period
What the framework requires
CC4.1 requires ongoing evaluation of whether controls are present and functioning. A penetration test evaluates them adversarially, which is stronger evidence than a self-assessment.
CC7.1 requires detection of configuration changes and vulnerabilities. Testing demonstrates that detection works in practice: including, usefully, which of your attacks nobody noticed.
For a Type II, timing matters more than anything else. Testing early in the observation window means findings are remediated and re-verified inside the period, instead of sitting open in the auditor’s sample.
What the engagement delivers
Trust Services Criteria mapping
Findings tagged to the specific criteria they touch, so your auditor can file the evidence without asking for a walkthrough.
Timed for the window
Scheduling planned around your observation period, so remediation and retest both fall inside it.
Retest attestation
A signed letter recording findings raised, remediated and verified, in the form auditors and customers both accept.
Customer-shareable summary
A redacted summary you can send to prospects under NDA during security review, without exposing exploitation detail.
Detection feedback
A record of which testing activity your monitoring caught and which it missed, which is directly useful evidence for CC7.2.
Questionnaire support
Answers to the recurring security-questionnaire items about testing scope, frequency, methodology and tester qualification.
Questions
Do we need a penetration test for SOC 2?
It is not explicitly required by the Trust Services Criteria, but in practice most auditors request one as evidence under CC4.1 and CC7.1, and most enterprise buyers ask whether you have had one. Arriving without one usually means answering the same question repeatedly for the next twelve months.
When in the SOC 2 process should we test?
Before the observation window opens for a Type II. That way any finding is remediated and re-verified inside the period, and the auditor sees a closed loop rather than an open item. Testing late in the window is the most common avoidable problem in a first SOC 2.
Can the report be shared with our auditor and customers?
Yes. Three documents are produced: the full technical report for your engineers, an auditor-facing summary, and a redacted attestation letter suitable for sharing with customers under NDA.
Does the scope need to match our SOC 2 system boundary?
It should. Where the test scope and the system description diverge, auditors raise the gap. The system boundary is reviewed during scoping so the two documents agree.
How much does SOC 2 penetration testing cost?
Cost follows scope rather than the audit. Trust Services Criteria mapping is included in the report. A fixed quote follows a short scoping call, and testing before your observation window opens is usually cheaper than remediating inside it.
Which Trust Services Criteria does testing evidence?
Primarily CC4.1 on monitoring of controls, CC7.1 on vulnerability detection and CC7.2 on monitoring for anomalies. Findings are tagged to the specific criteria they touch so your auditor can file the evidence without asking for a walkthrough.
Do we need testing for Type I as well as Type II?
Type I tests design at a point in time, so testing is useful but not always expected. Type II tests operating effectiveness over a period, and that is where testing timing matters: run it before the window opens so remediation lands inside the period rather than in the auditor's exception list.
Can you test against a SaaS product built on someone else's platform?
Yes, within what your provider's acceptable use policy permits. Your workloads, configuration and application are in scope; their underlying platform is not. The report states that boundary explicitly so your auditor knows what was and was not covered.