Questions like these are common because SOC 2 and penetration testing sit close together in customer and auditor expectations, even though the framework itself says little about the latter by name. Understanding what auditors actually look for, how to scope the work, and how to prepare evidence saves time and avoids last-minute scrambles. The sections below walk through the relationship in practical terms.
What SOC 2 Is and What Auditors Look For
SOC 2 is an attestation framework developed by the American Institute of Certified Public Accountants. An independent auditor examines a service organization's controls against the Trust Services Criteria and issues a report. The criteria cover security, which is required in every SOC 2 engagement, along with availability, processing integrity, confidentiality, and privacy, which organizations include based on the commitments they make to customers.
Two report types exist. A Type I report describes whether controls were suitably designed at a point in time. A Type II report examines whether controls operated effectively over a period, commonly several months up to a year, and it carries more weight with customers because it shows consistency, not just intent.
Auditors do not run security tests themselves. They evaluate whether the organization has defined controls, whether those controls are implemented, and whether evidence shows that they operated. For security, that includes access management, change management, risk assessment, monitoring, incident response, and vulnerability management. They sample evidence, such as tickets, logs, policies, and reports, and test whether the described process matches reality.
The framework is principles-based, which means it does not prescribe exact technical controls. Organizations define controls appropriate to their environment, and auditors assess them against the criteria. That flexibility is why expectations around testing vary from one auditor and one company to another, and it explains much of the confusion on the subject.
Does SOC 2 Require Penetration Testing?
The short answer is that SOC 2 does not use the words "penetration test" as an explicit mandate, but it expects organizations to identify and manage vulnerabilities, monitor their systems, and evaluate whether controls work. Many auditors treat an independent penetration test as a strong, conventional piece of evidence for those expectations, and many customers ask for one directly.
Within the Trust Services Criteria, several common criteria relate to the topic. Risk assessment criteria call for identifying and analyzing threats and vulnerabilities. Monitoring criteria call for ongoing or periodic evaluations of whether controls are present and functioning. System operations criteria include detecting vulnerabilities and responding to them. A penetration test provides evidence that someone independent tried to break in, what they found, and how the organization responded.
Because of this, SOC 2 penetration testing has become a standard part of most programs, even though it is a practice and not a literal rule. Some auditors will accept other evidence, such as regular vulnerability scanning combined with internal testing, but an external test is easier to explain and widely understood. Organizations should ask their auditor early about expectations, since interpretations differ.
It also helps to separate related activities. Vulnerability scanning is automated and frequent, penetration testing is deeper and more adversarial, and a code review examines source. Each contributes evidence, and a mature program often includes all three. SOC 2 penetration testing, specifically, usually means a documented test performed by a qualified party, with scope, methodology, findings, and remediation tracked.
Scoping the Test
Scope determines whether the test will satisfy the auditor and the customers. Start with the system boundary defined in the SOC 2 report, which describes the services, infrastructure, software, people, and data in scope. A penetration test should cover the components that make up that boundary, especially customer-facing applications, APIs, authentication systems, and the cloud infrastructure that hosts them.
Common elements include the production web application and its APIs, authenticated and unauthenticated testing, role-based access and privilege escalation checks, tenant isolation in multi-tenant systems, external network exposure, and cloud configuration. Internal network testing may be relevant if employees' systems connect to production. Mobile apps, if part of the service, should be considered.
Define rules of engagement in writing. State the target systems, testing windows, methods that are permitted or prohibited, contacts for emergencies, and how data will be handled. Decide whether testing occurs in production or in a staging environment that mirrors it, recognizing that production gives the most realistic results but requires more care.
Independence matters. Auditors and customers generally prefer testers who are not the same people who built or administer the system. Qualifications also count, so document the tester's experience, credentials, and methodology, often based on recognized references such as the OWASP guidance for applications. Timing should align with the audit period, and tests should recur at least annually or after significant changes.
Preparing for the Test and the Audit
Preparation begins long before testers arrive. Keep an up-to-date inventory of systems and data flows, and provide test accounts for each role, with documentation of expected behavior. Make sure logging and monitoring are working, since part of the exercise tests whether the organization notices suspicious activity. Notify relevant teams so that alerts are interpreted correctly.
A short checklist helps teams organize:
- Confirm the auditor's expectations for frequency, independence, and report content
- Align test scope with the system boundary in the SOC 2 description
- Select a qualified, independent tester and agree on rules of engagement
- Prepare test accounts, environments, and documentation
- Schedule remediation capacity so findings can be fixed promptly
- Plan retesting of high and critical findings
- Store the report, evidence, and remediation records where the auditor can access them
During the test, maintain communication with the testers and respond to questions quickly. Track findings in the same system used for other security issues, assign owners and due dates, and note any risk acceptance decisions with approvals. If testers discover critical issues, treat them as incidents and follow the response process.
Afterward, remediate according to documented timelines, and retest to confirm fixes. Auditors often examine whether a test occurred and whether the organization addressed what was found. A clean trail from finding to fix to verification is strong evidence that the control is operating.
Working With Auditors and Keeping Evidence Current
Auditors value clarity and consistency. Present the penetration test report along with a summary of remediation actions, showing how findings were prioritized, fixed, or formally accepted. Be ready to explain the scope, why it matches the system description, and how the tester's independence is established.
Expect questions about gaps. If the test was performed early in the audit period and major changes followed, the auditor may ask how new risks were assessed. Having continuous or periodic testing between annual engagements, plus change management records showing security reviews of significant releases, answers that concern. Some organizations supplement annual tests with ongoing automated testing to cover drift.
Maintain evidence throughout the period, and not just at audit time. Keep dated reports, scoping documents, retest results, tickets, and approvals organized in a shared repository. Compliance platforms can help collect and store this material, but the underlying discipline matters more than any tool.
Finally, treat the audit as a learning cycle. Review auditor feedback, adjust scope and frequency, and align testing with customer demands. Many enterprise buyers request reports from the past twelve months, so keep a schedule that ensures a current report is always available. Preparing consistently turns an annual scramble into a routine.
Final Analysis
SOC 2 does not mandate penetration testing by name, but auditors and customers widely expect it as evidence that an organization tests its defenses, manages vulnerabilities, and fixes what it finds. Treating it as a core part of the program avoids surprises during audits and sales cycles.
Success depends on a few habits: confirming expectations early, scoping tests to the system boundary, choosing qualified independent testers, tracking remediation carefully, and keeping evidence organized. Done well, penetration testing supports both the audit and the security of the product it examines.
A calm, repeatable routine also helps the sales side of the business. When a customer asks for a recent report, the answer is a file that already exists, with scope and remediation records ready to share, rather than a project that begins the moment the request arrives.