SOC 2
Penetration test vs vulnerability scan for SOC 2
SOC 2 does not say “penetration test” anywhere. Auditors still expect one. Here is why, and how to satisfy the criteria without over-buying.
Certifyi compliance team · Updated September 2026
Short answer. A vulnerability scan is an automated check of systems against a database of known weaknesses, run frequently and cheaply. A penetration test is a manual, goal-driven attempt by a skilled tester to exploit weaknesses, run less often at higher cost. SOC 2 does not mandate either by name, but the Trust Services Criteria (CC7.1 on vulnerability identification and CC4.1 on evaluating controls) mean auditors expect regular scanning plus at least an annual penetration test of the in-scope environment, with findings tracked to remediation.
What each one is
| Vulnerability scan | Penetration test | |
|---|---|---|
| Method | Automated tool matches versions and configurations against known CVEs | Human tester chains weaknesses to reach a goal, such as customer data or admin access |
| Depth | Broad, shallow; many false positives | Narrow, deep; validated findings with proof |
| Frequency | Weekly to monthly, and after changes | Annually and after significant architecture changes |
| Output | List of findings by severity | Report with methodology, findings, exploitation evidence, remediation advice and a retest |
| Who | Internal team with scanner or cloud-native tooling | Independent firm or qualified internal red team |
Which criteria they evidence
- CC7.1: the entity uses detection and monitoring procedures to identify changes to configurations that introduce vulnerabilities and susceptibilities to newly discovered vulnerabilities. Scanning is the primary evidence.
- CC4.1: management evaluates whether controls are present and functioning. An independent penetration test is a strong evaluation.
- CC7.2 and CC7.4: anomalies detected and incidents responded to; test findings feed the remediation and incident processes.
- CC8.1: changes are authorised, tested and approved; testing after major changes ties in here.
Scoping a first penetration test
Scope the test to the system described in your SOC 2 report: the production application, its APIs, the cloud environment that hosts it and the identity layer. Tell the tester which of black-box, grey-box or authenticated testing you want; authenticated testing with two roles finds the access-control bugs auditors care about. Ask for a retest of critical and high findings included in the fee, and a report that shows methodology and evidence, because the auditor will read it.
What the auditor actually checks
Auditors look for four things: that the scans ran on the stated schedule (evidence: scanner reports over the period), that findings were triaged with an owner and a due date, that critical and high items were fixed within your own policy timelines, and that the penetration test covered the in-scope system and its findings were closed or accepted with documented rationale. A test report with open criticals and no remediation trail is worse than no test.
Cost and how to keep it sensible
Pen test fees are driven by scope and days, not company size: a single web application with an API and one cloud account is a small engagement, a multi-tenant platform with mobile apps and several environments is not. Bundle the test with your audit calendar so the retest lands before the observation period ends. In Certifyi, scanner integrations feed the vulnerability management module automatically, the pen test report and remediation trail sit against CC7.1 and CC4.1 as hashed evidence, and the auditor reads them in the workspace.
Pen tests and scans, answered
Is a penetration test mandatory for SOC 2?
Not by the letter of the criteria, but nearly every auditor expects an annual test as evidence for CC4.1 and CC7.1, and enterprise customers ask for the executive summary during due diligence.
Can our own engineers do the penetration test?
Yes if they are qualified and independent of the system they test, but an external firm carries more weight with auditors and customers, especially for a first report.
How quickly must findings be fixed?
Your own policy sets the timelines and the auditor tests against them. Common targets are 15 to 30 days for critical, 30 to 60 for high, 90 for medium.
Do we need to share the full report with customers?
No. Share an executive summary or attestation letter; the full report contains exploitation detail. A Trust Center is the usual place to publish the summary.
Get audit-ready in 8 to 12 weeks
Certifyi pairs the platform with a named compliance lead who implements with your team, priced on scope and due at audit sign-off.