SOC 2 penetration testing
Penetration testing for SOC 2
SOC 2 does not name penetration testing as a requirement. Auditors ask for it anyway, and the report is judged on scope, independence and whether the findings were closed.
The context
Why this is different
The AICPA Trust Services Criteria do not contain the phrase penetration testing. What they contain is CC7.1, which requires procedures to detect and monitor for vulnerabilities and configuration changes, and CC4.1, which requires ongoing or separate evaluations of whether controls are operating. Auditors read those as expecting independent technical testing, and in practice nearly all of them ask for it.
That framing matters because it tells you what the auditor is actually assessing. They are not reading your findings for technical interest. They are checking that the testing was independent, that its scope covered the system described in your report, that findings were tracked to closure, and that the whole thing happened inside a defensible timeframe.
Which is why timing catches teams out more than scope does. A test performed after your Type II observation window has closed provides no evidence that vulnerability management operated during the window. A report full of open criticals is worse than no report, because it demonstrates that your remediation process does not work.
What we look for
The failure classes that actually show up.
Testing after the observation window
Type II tests whether controls operated over a period. Evidence dated after that period ends does not demonstrate operation during it. Testing should sit inside the window with enough runway to remediate and retest before it closes.
Findings left open at audit time
An auditor seeing unresolved high or critical findings will ask about your remediation process, and the answer is now visibly weak. Closure evidence matters more to the opinion than the original finding count.
Test scope narrower than the system description
Your system description defines the boundary being audited. If it includes the API and the admin console but the test covered only the customer-facing web app, there is a gap the auditor will identify.
Testing performed by the people who built it
Internal testing has value and does not satisfy the independence expectation on its own. The tester should not be the person responsible for the controls being tested.
No verification that fixes worked
A remediation log saying an issue was fixed is weaker evidence than a retest report confirming it. This is the single cheapest improvement most teams can make to their evidence pack.
One test, then nothing
CC7.1 implies an ongoing process. A single test with no defined cadence and no policy stating the frequency reads as a one-off exercise rather than an operating control.
Reference
Where penetration testing evidence maps
| Criterion | What it asks | What the report supplies |
|---|---|---|
| CC4.1 | Ongoing or separate evaluations of control operation | Independent assessment performed within the period, with dates |
| CC7.1 | Detection and monitoring of vulnerabilities and misconfiguration | Findings, severity rationale and the testing methodology used |
| CC7.2 | Monitoring for anomalies indicating malicious acts | Detection coverage observed during testing, and gaps where activity went unnoticed |
| CC8.1 | Change management, including security testing of changes | Testing tied to a release, and the defined cadence in your policy |
| CC9.1 | Risk mitigation activities | Remediation record and retest evidence showing findings closed |
How we test it
The engagement.
- 01
Align scope with the system description
We read your draft system description first and scope the test to match it. If the two disagree, the gap is a finding for your auditor rather than for us, and it is cheaper to discover now.
- 02
Schedule against the observation window
Testing placed early enough in the window to remediate and retest inside it. For a first Type II we usually recommend the first third of the period.
- 03
Test the application and its infrastructure
Application, API and authentication surfaces, plus the cloud configuration supporting them. Auditors regard infrastructure as in scope when your system description says it is.
- 04
Report in a form an auditor can use
Explicit scope statement, dates, methodology, independence declaration, severity rationale and a findings table with unique identifiers your remediation log can reference.
- 05
Track remediation to closure
We supply the findings register in a form you can maintain, with status and owner columns, because the tracking record is itself audit evidence.
- 06
Retest and reissue
Once fixes are deployed we retest each finding and reissue the report with verified status. That reissued report is what you hand the auditor.
What you get
Deliverables
- From
- $4,500
- Typical duration
- 1 to 3 weeks
- Findings report with explicit scope, dates and methodology statement
- Independence declaration suitable for inclusion in your evidence pack
- Mapping of findings and testing activity to the Common Criteria
- Findings register with identifiers, owners and status for your remediation log
- Retest report confirming closure, included in the price
- Customer-shareable attestation letter
- Crosswalk to ISO 27001 Annex A 8.8 and 8.29 if you are pursuing both
Questions
The ones engineers ask.
Not by the letter of the Trust Services Criteria. In practice auditors expect independent technical testing to evidence CC7.1 and CC4.1, and we have not seen a Type II proceed comfortably without it. Ask your auditor directly during scoping; they will tell you what they expect to see.
Early. You need time to remediate and retest before the window closes, and a finding closed within the period is far better evidence than one closed after it. For a three month window that means the first few weeks, not the last.
Scanning helps evidence continuous monitoring and most auditors want to see it. It is generally not accepted as a substitute for independent testing, because it demonstrates tooling rather than assessment. Run both; they answer different questions.
No. One properly scoped test serves both, provided the scope covers what each framework considers in scope. We produce the report once and map it to the Common Criteria and to Annex A 8.8 and 8.29.
Fix it and document the timeline honestly. Auditors respond considerably better to a serious finding identified, tracked and closed than to an absence of findings, which mostly suggests the testing was shallow.
Know exactly what an auditor, and an attacker, would find.
Tell us what you need certified or tested. We will scope it properly, quote a fixed price, and tell you honestly if the timeline you have in mind is realistic.
No sales sequence. A scoping call and a written proposal cost nothing.