The confusion comes from three different things getting lumped together: what SOC 2 requires, what your auditor or customers expect, and what your own risk assessment says you should do. Mixing them up leads to over-promising in control descriptions or skipping a test that a buyer will demand anyway.
This guide covers the relevant Trust Services Criteria, Type I versus Type II, scope and timing, audit evidence, remediation, and when to check with your CPA firm.
Key Takeaways
- SOC 2 is principles-based and prescribes no identical test, method, or schedule.
- A scoped penetration test can support evidence across several criteria.
- Vulnerability scans are not automatically equivalent to penetration tests.
- Auditors look at scope, independence, remediation, and retesting, not just the report.
- Confirm scope, timing, and evidence with your auditor before testing starts.
What Do SOC 2 Requirements Actually Say About Penetration Testing?
SOC 2 is an attestation examination governed by the AICPA. It evaluates controls against the Trust Services Criteria, not a fixed checklist of tools. The applicable criteria are the 2017 Trust Services Criteria (with revised points of focus, 2022). The AICPA states that use of the criteria "does not require an assessment of whether each point of focus is addressed."
The difference between a requirement and an expected control activity
The criteria set objectives. Your organization picks control activities based on its risk assessment, system, customer commitments, and environment.
CC4.1 reads: "The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning."
One point of focus says those evaluations "may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments."
Penetration testing is one listed example, not a mandate. Another point of focus says management varies the scope and frequency of separate evaluations depending on risk.
When penetration testing becomes practically important
Even without an express requirement, testing often becomes expected:
- Auditors ask how you validate technical controls, especially for internet-facing apps, APIs, cloud infrastructure, and sensitive customer data.
- Enterprise security questionnaires and procurement reviews ask for a recent report before signing.
- Cyber insurers may want evidence of testing. Chubb, for example, partnered with NetSPI in 2023 to offer policyholders penetration testing at preferred pricing.
As IS Partners puts it, SOC 2 does not explicitly require penetration testing, but it is highly recommended for the Security category.
Alternatives and documented rationale
Other evaluations can complement or sometimes stand in for a test:
- Vulnerability scanning
- Secure code review and DAST
- Internal control testing
- Red-team exercises
- Mature bug bounty programs
Each answers a different question. Don't assume any of them is automatically equivalent. Choose through a documented risk assessment, then discuss it with your auditor.
Is SOC 2 legally required?
Generally no. SOC 2 is a voluntary attestation. But customer contracts, procurement rules, industry obligations, or applicable regulations can make it necessary for your organization. This is general information, not legal advice. Confirm your obligations with qualified legal, compliance, and audit professionals.
How Penetration Testing Supports the Trust Services Criteria
A penetration test is an authorized, controlled simulation of realistic attacks. NIST describes it as security testing where assessors mimic real-world attacks to find ways around an application's, system's, or network's security features.
A policy review checks paperwork. A vulnerability scan identifies known weaknesses. A penetration test shows whether those weaknesses can actually be exploited.
Security and monitoring evidence
A properly scoped test can support the Security category by probing:
- Authentication and session handling
- Authorization and privilege escalation
- Exposed services and APIs
- Cloud configuration, including identity and access controls
- Application security and logic flaws
Tie the evidence to CC4.1 (evaluating controls) and CC7.1 (detecting new vulnerabilities) only where your actual controls support it. CC7.1 specifically mentions vulnerability scans, so don't present a pen test as a substitute for that control. Check current AICPA wording rather than relying on a generic mapping.
Evidence for other Trust Services Criteria
- Availability: supported when testing addresses resilience weaknesses within approved rules of engagement. Unsafe denial-of-service testing is not automatically appropriate.
- Confidentiality and Processing Integrity: supported when testing covers unauthorized data access, tenant isolation, input validation, transaction manipulation, and business-logic flaws.
- Privacy: conditional. A test gives technical evidence, but it doesn't replace privacy governance, notices, data-use procedures, or legal compliance.
SOC 2 Type I versus Type II
Type I assesses whether controls are suitably designed as of a specified date. Type II also evaluates operating effectiveness over a period. Cherry Bekaert notes the AICPA sets no minimum Type II period, though the shortest it typically sees is three months.
- Type I evidence centers on scope, methodology, and the remediation process.
- Type II evidence must show testing and remediation happened consistently, matching your stated policy and cadence.
Don't promise a testing frequency in your control description that you can't reliably deliver. Written policy, actual testing, and audit-period evidence must line up.
What penetration testing cannot prove
A test won't guarantee a clean report, prove every vulnerability was found, or replace access reviews, monitoring, incident response, secure development, or vendor risk management. Its value comes from realistic technical validation paired with traceable management action.
How to Scope and Schedule a SOC 2 Penetration Test
Start with your SOC 2 system description, in-scope criteria, data flows, customer commitments, and risk assessment. Avoid a generic testing package.
Define the technical scope
Include what carries real risk, where relevant:
- Production applications, web apps, mobile apps, and APIs
- Administrative interfaces and authentication and authorization workflows
- Cloud resources, identity providers, and databases
- Internal systems that offer an indirect path to customer data
Test the real attack surface. If your customer risk sits in authenticated SaaS functionality or APIs, a test of the marketing site and external perimeter misses the point. Manual testing finds logic flaws scanners can't, such as cross-customer record access or missing authorization checks on APIs.
Choose an appropriate testing perspective
OWASP distinguishes black box (no inner knowledge), gray box (partial knowledge), and white box (internal knowledge, including source code).
- Black box is the most realistic but least efficient.
- Gray box, with credentials, reaches authenticated risks faster.
- White box digs deepest into architecture and business logic.
A risk-based mix usually fits best. Explain your choice in terms of your objectives and what your auditor expects.
Establish safe rules of engagement
NIST points to authorized targets, exclusions, approved techniques, schedule, contacts, stop procedures, and data handling. Put these in writing:
- Written authorization and approved assets
- Testing windows and prohibited actions
- Emergency contacts and escalation for critical findings
- Production-versus-staging decisions
- Data handling
Document exclusions with a rationale and check them against your SOC 2 boundary, so they don't become unexplained evidence gaps.
Decide when to test
SOC 2 sets no universal frequency. Annual testing is common and good practice, not an AICPA mandate. (PCI DSS requires 12-month testing, but that's PCI, not SOC 2.)
Also test after major events:
- Major releases or new APIs
- Cloud migrations or architecture changes
- Authentication or authorization changes
- Acquisitions or significant incidents
- New sensitive-data workflows
Test early enough to remediate and retest before fieldwork, particularly for Type II.
Select an independent testing partner
Look for:
- Application, cloud, infrastructure, and compliance experience
- Documented methodology and competent testers (for example, OSCP certification)
- Independence from system development and operations
- Secure evidence handling and clear severity ratings
- Executive and technical reports, plus retesting support
Ask your CPA firm what qualifications, attestation letters, or independence evidence it expects.
What Auditors Expect From the Penetration Testing Evidence
An auditor may ask for:
- Approved scope and system boundary mapping
- Statement of work, rules of engagement, and testing dates
- Methodology and provider qualifications
- Final report and findings register
- Remediation tickets, risk acceptances, and management review
- Retest results
The chain matters: risk identified, finding validated, owner assigned, fix made, fix retested, final status documented. As Linford describes, owners should be assigned and mitigation tracked in ticketing systems.
Unresolved findings don't automatically sink a report. Schellman notes that an exception doesn't automatically produce a qualified opinion.
Still, each material issue needs a remediation plan, a compensating control, or a formally approved risk acceptance backed by severity and impact analysis. Late remediation of critical and high-risk vulnerabilities is one of the most commonly reported SOC 2 exceptions.
Common evidence gaps to avoid
- Narrow or stale scope
- Testing only a low-risk environment
- Excluding APIs or authenticated workflows without explanation
- Treating scanner output as a penetration test
- Undocumented tester independence
- Findings tracked outside the remediation workflow
Before the audit, verify that report dates, assets, findings, tickets, retests, risk decisions, and control descriptions all agree.
Where DeepSeas can support the process
DeepSeas offers practitioner-led offensive security and GRC support that ties controlled attack simulations to SOC 2 scope, remediation tracking, and audit readiness. Application testing includes reproduction steps for developers, a summary for the customer or auditor, and retesting after remediation.
Specialists include ISO Lead Auditor-certified personnel, and the firm brings roughly 30 years of cyber defense experience. Confirm scope, deliverables, and auditor acceptance for each engagement.
Conclusion
SOC 2 doesn't universally mandate penetration testing. But a well-scoped test is often a strong, commercially important way to show technical controls work.
Your next steps:
- Review your system boundary and risk assessment.
- Consult your CPA firm.
- Pick a defensible scope and qualified provider.
- Test early enough to remediate and retest.
- Keep a complete evidence trail.
Frequently Asked Questions
What is the average cost of a pen test?
It varies with scope, live hosts, authenticated access, application and API complexity, timeline, and retesting. Schellman's cost guide lists these drivers. Get scoped quotes rather than relying on a generic range.
What is a pen test in cybersecurity?
An authorized simulated attack that tests whether vulnerabilities can be exploited and what impact follows. Unlike an automated scan, it validates real attack paths.
Does SOC 2 require penetration testing?
Not as one universal test. Auditors, customers, and risk owners may still expect recent, appropriately scoped evidence.
Is penetration testing required for ISO 27001?
Not explicitly. Annex A controls 8.8 and 8.29 cover vulnerability management and security testing without prescribing pen tests. Applicability follows your risk treatment, so verify with your auditor.
How hard is it to get SOC 2?
It depends on maturity, system complexity, chosen criteria, evidence readiness, and Type I versus II. Cherry Bekaert cites 1-6 months for remediation alone. Pen testing is one part of the program.
Is SOC 2 legally required?
Generally not in the United States. A customer contract, procurement rule, insurer, or regulation can make it a practical requirement. Confirm with qualified legal counsel.
