We have already covered why a pentest matters for SOC 2. This article answers the follow-up question teams ask once they agree: how do we actually run one so that it satisfies the auditor, and what do we do with the report afterwards? The focus here is execution and evidence, not the argument for doing it.
Where penetration testing fits in SOC 2
The Trust Services Criteria never use the phrase “penetration test” as a mandatory step. Instead, several criteria call for ongoing evaluation and vulnerability management:
- CC4.1: the entity selects, develops and performs ongoing and separate evaluations to confirm controls are present and functioning. An independent test is a classic “separate evaluation.”
- CC7.1: detection and monitoring procedures to identify vulnerabilities and configuration changes.
- CC3.2 and CC3.3: identifying and assessing risks, including threats that could affect system security.
- CC8.1: changes are authorized, tested and approved, which links to testing of new releases.
Because the criteria are outcome-based, a penetration test is one accepted way to evidence them, and in practice the most common. If you say in your policies that you perform annual penetration tests, the auditor will test that statement. Verify the criteria wording on the AICPA SOC suite page.
Vulnerability scan vs penetration test
| Aspect | Vulnerability scan | Penetration test |
|---|---|---|
| Method | Automated tool checks for known weaknesses | Human testers attempt to exploit weaknesses and chain findings |
| Frequency | Often weekly, monthly or continuous | Typically annual and after major changes |
| Output | List of potential vulnerabilities | Validated findings with impact, evidence and recommendations |
| Depth | Broad | Targeted and deep |
| Role in SOC 2 | Supports CC7.1 ongoing detection | Supports CC4.1 independent evaluation and risk assurance |
You generally need both. A scan program shows continuous hygiene, while a pentest shows an expert attempted to break in and what happened.
Step-by-step: running a pentest that satisfies the auditor
1. Decide the scope
Align the test scope with your SOC 2 system boundary. Include internet-facing applications and APIs, authentication and authorization flows, cloud infrastructure in scope, and any internal network access paths that matter. Out-of-scope items should be intentional and documented. Our guide on defining SOC 2 scope helps here.
2. Choose the test type
- Web application and API testing for SaaS products.
- External network testing of public attack surface.
- Internal network or cloud configuration review if relevant.
- Authenticated testing with multiple user roles to check access boundaries and tenant isolation, which many B2B customers care about.
3. Pick an independent tester
Independence matters. The test should be performed by people who did not build or administer the system, either an external firm or a qualified internal team separate from development. Many enterprise buyers specifically want an external report. Check certifications and experience, and ask for a sample report format. Note that a penetration testing firm is not your SOC 2 auditor, and the two roles should not be confused. If you want the roles explained, see how to choose the right SOC 2 auditor.
4. Agree the rules of engagement
Define the test window, source IP addresses, testing environment (production or a production-like staging copy), emergency contacts, prohibited actions such as denial-of-service, and how sensitive data will be handled. Written authorization protects both sides, and it is also useful audit evidence.
5. Time the test inside your observation period
For a Type II examination, schedule the test so that findings can be remediated and retested before the period ends. A test completed on the last day leaves no time to show remediation. See the observation period explainer for how the window works.
6. Manage findings like any other risk
Log every finding in your ticketing system with severity, owner and due date aligned with your vulnerability management policy. Fix critical and high issues first. Where a fix is not possible, document a risk acceptance approved by management along with any compensating control.
7. Retest
Ask the tester to confirm that critical and high findings are resolved, and obtain a retest letter or updated report. Auditors give weight to closed-loop evidence.
The evidence package
| Artifact | Why the auditor wants it |
|---|---|
| Signed statement of work or authorization letter | Shows scope and independence |
| Final penetration test report with date, methodology and tester details | Proves the test occurred within the period |
| Executive summary or attestation letter | Shareable with customers without exposing details |
| Remediation tickets linked to each finding | Shows follow-through |
| Retest report or confirmation | Confirms issues were fixed |
| Risk acceptance records | Documents decisions on unresolved items |
| Vulnerability management policy | Defines timelines the findings are measured against |
Common pentest mistakes in SOC 2 programs
- Scope mismatch. Testing a marketing site while the production API goes untested.
- Treating a scan as a pentest. An automated scan export does not satisfy buyers who ask for a manual test.
- No remediation evidence. A report with open critical issues and no tickets invites questions.
- Testing too early or too late. A test months before the period leaves a gap, and one at the end leaves no time to fix.
- Policy says semiannual, reality says once. Auditors test against your documented frequency.
- Overpromising to customers. Sharing the full report without a confidentiality agreement may expose vulnerabilities. Share a summary letter instead, as discussed in sharing SOC 2 reports safely.
Sharing the results with customers
Enterprise security questionnaires often ask whether you perform annual third-party penetration tests and whether critical findings were remediated. A concise summary letter from the tester, plus your own statement of remediation status, answers most requests. Offer the full report only under NDA and only when necessary. This also reduces repeated questionnaire effort.
What this means for your business
A penetration test is one of the highest-value, lowest-regret items on a SOC 2 roadmap. It satisfies customers, informs your risk assessment, and gives the auditor concrete evidence. Plan its timing around the audit, keep a clean remediation trail, and budget for a retest.
We offer a combined option on the SOC 2 and pentest bundle page, and our SOC 2 readiness work can help you scope the test against your system boundary. As always, the SOC 2 opinion is issued by an independent CPA firm; testing and readiness support do not replace it.
Preparing your team and reading the report
A pentest produces the most value when engineering treats it as a collaboration rather than a grading exercise.
Before the test
- Provide test accounts for each user role and documentation of intended behaviour.
- Tell the on-call team and any managed security provider the test window so alerts are not mistaken for a real attack, while still noting whether your detection worked.
- Back up the environment and agree a contact for urgent issues.
After the test
- Triage findings within days, not weeks, and assign each one an owner.
- Separate real exploitable issues from informational notes, and challenge findings you believe are inaccurate with evidence.
- Map severity to your vulnerability policy deadlines.
- Retest critical and high issues and keep the confirmation.
What good looks like to an auditor
A dated report within the period, a scope that matches your system boundary, tickets for every meaningful finding, closure evidence and a note on any accepted risk with approval. That chain is the whole story. If you want to understand how the test fits within broader readiness work, our article on gap analysis from the auditor’s side of the table is a good companion.
Frequently asked questions
Is a penetration test mandatory for SOC 2?
Not explicitly. The criteria do not name it as a requirement. However, auditors and customers commonly expect one as evidence of security evaluation and vulnerability management, so most companies include it.
How often should we run a pentest for SOC 2?
Annually is the usual baseline, and after major architecture or application changes. Whatever your policy states is what the auditor will test.
Can our internal team do the pentest?
Possibly, if the testers are qualified and independent of the system’s development and operation. Many buyers prefer an external firm, so check customer expectations before deciding.
Do we need to fix every finding before the audit ends?
Not necessarily. You need to triage findings, remediate according to policy timelines and document risk acceptance for items you choose not to fix. Critical and high issues should be addressed and retested.
Does the pentest firm count as our auditor?
No. The penetration tester provides technical assurance. The SOC 2 opinion comes from an independent licensed CPA firm.
Should the test be in production or staging?
Either can work if the environment is representative. Production testing finds real configuration issues but needs careful rules of engagement. Many teams use a production-like staging environment for deeper tests plus limited production checks.
Conclusion
Treat the pentest as a project with a clear scope, an independent tester, a schedule that fits your observation period and a documented path from finding to fix to retest. That discipline turns a technical exercise into audit-ready evidence and a stronger story for every customer who asks about your security.
