SOC 2 Penetration Testing: What Auditors Expect

• Offensium Vault
• November 14, 2026
• No Comments

For SaaS companies selling to enterprise customers, especially in the US, a SOC 2 report is often the price of entry. One of the most common questions during preparation is whether SOC 2 penetration testing is required, and what the auditor actually needs to see. The answer has nuances that are worth understanding before you plan your test.

This guide explains where penetration testing fits in SOC 2, which Trust Services Criteria it supports, how to time and scope it, and how to turn the results into audit-ready evidence.

A Quick Overview of SOC 2

SOC 2 is an attestation framework developed by the AICPA. An independent CPA firm assesses a service organisation’s controls against the Trust Services Criteria, covering security (the common criteria) and, optionally, availability, processing integrity, confidentiality and privacy.

• SOC 2 Type I evaluates whether controls are suitably designed at a point in time.
• SOC 2 Type II evaluates whether controls operated effectively over a period, usually several months to a year.

Is Penetration Testing Required for SOC 2?

Strictly speaking, SOC 2 does not contain a rule that says “perform a penetration test”. The criteria are principles, and organisations choose controls to meet them. In practice, however, penetration testing is expected by most auditors and customers because it is the clearest evidence that your security controls hold up against a realistic attacker.

The points of focus for monitoring activities (CC4.1) specifically mention penetration testing as a type of separate evaluation. Together with vulnerability management and change management criteria, this makes an annual penetration test a standard part of most SOC 2 programmes.

Trust Services Criteria Supported by Penetration Testing

Scoping a SOC 2 Penetration Test

Scope should match the system described in your SOC 2 report. For most SaaS companies this includes:

• The customer-facing web application, including all user roles and tenants. Multi-tenant isolation is a critical area to test.
• Public and internal APIs, including API security testing against the OWASP API Top 10.
• Mobile apps, if they are part of the service.
• Cloud infrastructure and external network perimeter, including a cloud security review of AWS, Azure or Google Cloud.

Timing Your Test

• Type I: test before the point-in-time assessment so findings can be fixed and the report shows a clean or improving state.
• Type II: make sure the test and remediation fall within the audit observation period.
• After major changes: test significant new features or infrastructure changes, not only once a year.

Turning Results Into SOC 2 Evidence

1. Keep the full penetration test report with scope, methodology, dates and findings.
2. Log each finding in your ticketing system with severity, owner and due date.
3. Fix issues within the timelines defined in your vulnerability management policy.
4. Retest to confirm fixes and keep the retest report.
5. Record and approve any accepted risks with justification.
6. Share a summary or attestation letter with customers on request.

An open critical finding without a remediation plan can raise questions from your auditor, so retesting is an important part of the process. Our vulnerability management service can help keep remediation on track between tests.

SOC 2 Penetration Testing Checklist

1. Confirm the system boundary in your SOC 2 scope.
2. Choose an independent, qualified testing provider and sign an NDA.
3. Test the web app, APIs, mobile apps and cloud infrastructure in scope.
4. Include tenant isolation and role-based access testing.
5. Schedule the test within your audit period.
6. Track, fix and retest all findings.
7. Document risk acceptance where needed.
8. Repeat at least annually and after major changes.

Already working towards ISO 27001 as well? See our guide to ISO 27001 penetration testing requirements; one well-planned test can often support both.

Frequently Asked Questions

Is penetration testing required for SOC 2?

The Trust Services Criteria do not make penetration testing a strict requirement. However, the points of focus for monitoring activities (CC4.1) mention penetration testing as a type of evaluation, and most auditors and enterprise customers expect an annual penetration test as evidence that controls work in practice.

How often should a SaaS company run a SOC 2 penetration test?

Most SaaS companies test at least once a year, timed so the report falls within the SOC 2 audit period, and again after significant changes to the product or infrastructure. Many also run automated vulnerability scans continuously between manual tests.

Can an Indian security firm perform penetration testing for a SOC 2 audit?

Yes. SOC 2 reports are issued by licensed CPA firms, but the penetration test itself can be performed by any qualified, independent testing provider. What matters to the auditor is a clear scope, a credible methodology, a detailed report and evidence of remediation.

Conclusion

SOC 2 penetration testing may not be written as a strict rule, but it is expected by auditors and enterprise buyers alike. A test that matches your SOC 2 system scope, falls within the audit period and is followed by documented remediation and retesting gives you strong evidence and real security.

Preparing for SOC 2? Offensium Vault provides manual, evidence-based penetration testing with clear reports and retesting. Contact our team or explore all our cybersecurity services.