SOC 2 Type II is not a checklist. It’s an audit of whether your controls actually operate as described — over a period of time (usually 12 months). That distinction matters enormously for how you approach penetration testing evidence.
This article focuses on the two trust service criteria most directly relevant to security testing: CC7 (System Operations) and CC9 (Risk Mitigation). We’ll cover exactly what auditors look for, what evidence satisfies each control, and what common mistakes teams make that lead to findings or qualified opinions.
This article reflects general auditor expectations based on AICPA guidance. Your specific auditor may have additional or different requirements. Use this as orientation, not as a substitute for working directly with your auditor or a qualified GRC consultant.
What CC7 actually requires
CC7.1 requires that you monitor system components for vulnerabilities and anomalies. The key word is monitor — not just test once. Auditors are looking for evidence that vulnerability management is an ongoing process, not a point-in-time exercise.
For penetration testing specifically, CC7.1 typically requires:
- Evidence that vulnerability scanning or penetration testing was performed during the audit period
- Dates and scope of each test
- The findings produced — not just “no critical findings” but the actual output
- Evidence that findings were tracked and remediated (or risk-accepted with documentation)
The “single annual pentest” mistake
Many teams hire an external firm for one annual penetration test, hand the report to auditors, and consider the control covered. Auditors are increasingly pushing back on this. A single test at the start of a 12-month audit period says nothing about what happened to your security posture in months 2–12.
The more defensible approach is regular automated scanning (monthly or quarterly) with an annual manual assessment by an external firm. The automated scans provide continuous evidence across the audit period; the manual assessment provides depth.
What CC9 actually requires
CC9.2 requires that you identify, assess, and manage risks from vendors and business partners — but its broader application covers risk identification across the system. For security testing, this means you need to show that you:
- Have a process for identifying new risks (e.g. from new feature deployments)
- Assess identified risks against a defined risk tolerance
- Have evidence that high-risk items were escalated and addressed
Not every vulnerability needs to be fixed. But every unfixed vulnerability above a certain severity threshold needs a documented risk acceptance decision — who approved it, why, and when it will be reviewed. Auditors are comfortable with risk acceptance; they are not comfortable with silence.
The evidence package auditors actually want
Based on common audit requests, here is what a well-structured penetration testing evidence package looks like for CC7/CC9:
| Evidence item | Covers | Satisfied by PenScan? |
|---|---|---|
| Scan dates and scope for each test | CC7.1 | ✓ Scan history with timestamps |
| Findings report with severity classification | CC7.1 | ✓ CVSS-scored vulnerability report |
| Remediation status per finding | CC7.1, CC9.2 | ✓ Finding status tracking |
| Re-scan evidence confirming fixes | CC7.1 | ✓ Re-scan + finding resolution log |
| OWASP Top 10 coverage mapping | CC7.1 | ✓ Per-finding OWASP category |
| Scope authorization documentation | CC9.2 | ✓ DNS verification audit log |
| Risk acceptance for open findings | CC9.2 | Manual — requires internal sign-off |
| Annual manual assessment by external firm | CC7.1 | Supplement — not replaced by PenScan |
How to structure your evidence for auditors
Don’t hand auditors a raw vulnerability report and hope for the best. Structure your evidence package in the order they’ll review it:
1. Testing calendar
A simple table showing every scan performed in the audit period: date, target, scope, and a link or reference to the report. This immediately shows that monitoring is ongoing.
2. Findings and remediation log
For every finding of Medium severity or above: the finding name, CVSS score, detection date, remediation action taken, and re-verification date. If a finding was risk-accepted rather than fixed, include the risk acceptance record.
3. Authorization evidence
Show that every scan was authorized. PenScan’s DNS TXT verification log provides this automatically — each verified target has a timestamped authorization record.
4. Scope definition
Document which systems were in scope for testing and which were excluded, with a rationale for any exclusions. Auditors want to see that your scope covers production systems handling customer data.
Common audit findings related to security testing
- Gap: Testing performed only once during the audit period — Fix: run monthly automated scans throughout the year.
- Gap: No evidence of remediation tracking — Fix: use PenScan’s finding status to mark items as resolved and show the re-scan result.
- Gap: Findings not mapped to a severity framework — Fix: PenScan reports include CVSS scores for every finding.
- Gap: No authorization documentation for test scope — Fix: PenScan’s DNS verification creates this automatically.
- Gap: Risk-accepted findings with no approval record — Fix: document every risk acceptance with approver, rationale, and review date in your GRC tool.
The bottom line
SOC 2 Type II auditors are not looking for perfection. They are looking for a demonstrated, documented, ongoing process. Monthly automated scanning with remediation tracking — supplemented by an annual manual assessment — satisfies CC7.1 and CC9.2 for the vast majority of SaaS companies.
The key is that your evidence covers the full audit period, not just the month before your audit.