SOC 2
SOC 2 penetration testing requirements
SOC 2 programmes are built around trust services criteria and evidence. Penetration testing helps show that security controls are not just documented, but have been challenged against real application, API, cloud and infrastructure risk.
Where penetration testing fits into SOC 2
Penetration testing commonly supports evidence around vulnerability management, change risk, logical access, monitoring and risk assessment. The exact mapping depends on your control set and auditor.
What good SOC 2 evidence looks like
A useful report should be scoped to your service boundaries, show severity and impact, include remediation guidance, and provide retest status for findings that could affect customer data or service availability.
- Application and API coverage for customer-facing workflows
- Cloud review for IAM, storage, logging and network exposure
- Clear finding owners, target dates and remediation status
- Retest output that confirms fixed findings
Why recurring testing helps Type II periods
SOC 2 Type II covers control operation over time. A subscription model can create fresher evidence across product changes, rather than relying on a single annual report that ages quickly.
FAQ
Common questions
Do SOC 2 auditors require penetration testing?
Many auditors expect it for SaaS environments, but the requirement depends on your control design and risk profile. It is commonly used as strong technical assurance evidence.
Should SOC 2 testing cover APIs?
Yes, if APIs handle customer data or privileged workflows. API authorisation and data exposure issues are common SaaS risks.
Can one penetration test support both SOC 2 and ISO 27001?
Often yes, if the scope and report are written clearly enough to support both evidence needs.