SOC 2 penetration testing: is it required, and what do auditors expect?

SOC 2 penetration testing is an independent, authorised test of the systems in your SOC 2 scope, run to show your auditor and customers that your security controls hold up when someone tries to defeat them. The AICPA's Trust Services Criteria do not name it as mandatory, but most auditors and buyers expect one a year, with every serious fix retested.

That is the short answer to "is SOC 2 penetration testing required?" What follows covers where the expectation comes from, what an auditor asks for, how to scope the test and how often to run it. It ends with the evidence to keep for your SOC 2 audit. Plan around an independent penetration test.

Is a penetration test required for SOC 2?

Not by name. SOC 2 is an attestation report, not a checklist law. A licensed CPA firm examines your controls against the Trust Services Criteria (TSC) published by the AICPA. It then writes an opinion on whether the controls were suitably designed (Type I) or suitably designed and operating over a period of time (Type II). The AICPA frames its SOC suite as assurance reports from CPAs. Nothing in that structure says "you must buy a pentest".

The criteria are written as outcomes. You choose the controls that meet them, and the auditor decides whether the evidence is enough. So the honest answer has two parts:

• Formally: no criterion reads "perform a penetration test". The framework is flexible about how you meet it.
• In practice: several criteria are very hard to evidence for a web application without independent testing, and most auditors, security questionnaires and enterprise buyers treat an annual pentest as the normal answer.

Think of the pentest as optional on paper and expected in the room. Skipping it breaks no rule. It does mean defending a different form of evidence to your auditor, and to each customer who reads your report or sends a security questionnaire.

Why do auditors and buyers expect a pentest?

Because the risk they assess is real and well measured. The 2026 Verizon Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in. IBM's 2026 Cost of a Data Breach report calls the global average breach cost a record high, a 12% increase over last year. CISA's Known Exploited Vulnerabilities catalogue listed 1,734 flaws when we read it on 7 October 2026, each one already used in real attacks.

For a SaaS product the sharpest edge is access control. OWASP's 2025 Top 10 ranks broken access control first and reports that 100% of the applications tested had some form of it, across 40 mapped CWEs and 1,839,701 occurrences in the data. A scanner struggles to judge this category and a tester can prove it. It is also where customer separation succeeds or fails.

Which SOC 2 criteria does a penetration test support?

No single criterion owns penetration testing. It supports a cluster in the Security category (the "common criteria", numbered CC), and the table below covers the main ones. Your auditor will work from the exact wording and points of focus in the 2017 Trust Services Criteria (with revised points of focus, 2022), so read that text too.

CC4.1 and CC7.1 carry most of the weight, and the detail sits in their points of focus. risk3sixty quotes the CC4.1 point as listing "penetration testing" among several kinds of ongoing and separate evaluation, next to independent certifications such as ISO and internal audit assessments. Its quote of the CC7.1 point has the entity running vulnerability scans periodically and after significant change in the environment.

Points of focus guide the auditor and are not a checklist. That is why a pentest is expected rather than required: CC4.1 names it as one option among several. The AICPA's criteria PDF is gated, so we read the wording through that published analysis. Your auditor's copy and mapping govern.

What do SOC 2 auditors expect from a penetration test?

Auditors do not re-run your test. They check three things: a credible test happened, it covered the system in scope, and you dealt with what it found. In practice that becomes six checks.

1. Independence. The tester should not be the team that wrote the code. An outside firm is the usual choice. An internal security team can be acceptable if it is organisationally separate and competent, but expect more questions.
2. Coverage of the system boundary. The test should include the application, APIs and infrastructure inside your SOC 2 system description. A test of the marketing site does not evidence controls on the product.
3. Recent and inside the audit period. For a Type II report, the test date should fall within the period under examination. A report from eighteen months ago invites a question.
4. A defined method. A named approach, such as the OWASP Web Security Testing Guide or NIST SP 800-115, shows the test was planned rather than improvised.
5. Findings with severity and status. Each finding needs a rating, an owner and a state: open, fixed, risk accepted.
6. Proof that fixes were verified. A retest result, dated after the fix, closes the loop. A ticket marked "done" does not.

A short attestation letter suits customers. An auditor wants the full report plus your remediation trail, so keep both.

Is a vulnerability scan enough for SOC 2, or do you need a pentest?

Both help, and they answer different questions. A vulnerability scan is automated, broad and cheap to repeat. It finds known issues, missing patches and common misconfigurations. In a penetration test, a person (or a person-led process) tries to use weaknesses to reach data they should not. That is how you find business logic flaws, chained problems and broken authorisation that no signature can see.

For CC7.1, regular scanning fits, because the criterion is about ongoing detection. For CC4.1, an independent test is the stronger "separate evaluation". Run both: scans on a schedule and on release, and a pentest at least yearly and after major change.

For an application that holds customer data, a scan rarely replaces a pentest in an auditor's eyes, because it cannot show that access rules actually hold. A pentest alone has the opposite gap: it says nothing about the other 364 days. The term pages on DAST, SAST and automated pentesting show how the pieces fit.

How do you scope a SOC 2 penetration test?

Scope decides whether a SOC 2 pentest is useful. Too narrow, and the auditor asks why a system in the description was left out. Work from your SOC 2 system description and write the scope down before the tester starts. The pentest scope and rules of engagement pages cover the mechanics.

What to include

• The production-like application that customers use, tested on a staging copy that mirrors production, or on production under agreed rules.
• Every API the product exposes, including the ones only your mobile app or integrations call. See API pentesting.
• Authentication and session handling: login, password reset, MFA, single sign-on, token lifetime.
• Authorisation and tenant separation, particularly if customers share infrastructure. See tenant isolation.
• Admin and support tooling that can reach customer data.
• Cloud and network exposure of the hosts in the system boundary, when your description includes them.

What to state as out of scope

Say plainly what you did not test and why. Typical exclusions are third-party SaaS you only consume, systems your cloud provider runs under the shared responsibility model, and anything outside the system boundary. Auditors accept a clear exclusion far more readily than a silent gap.

Test accounts and access

Give the tester two or more accounts at each privilege level you have, in at least two separate customer tenants. They can then check what one signed-in account can reach that it should not. Nothing affects the odds of finding real broken access control more than this, and a test run with one login finds very little of it. Also decide whether the test is black-box, grey-box or white-box. Grey-box and white-box testing go deeper in the same time, and our guide to black, grey and white box testing explains the trade-offs.

How often should you run a penetration test for SOC 2?

The TSC set no interval. Common practice is at least once every twelve months, and again after a significant change to the system. For a Type II report, put the test and the retest inside the audit window, not just before or after it.

A significant change is usually a new product area that handles customer data, a rebuilt authentication or authorisation layer, a cloud migration or a new public API.

If you ship weekly, one annual test describes a product that has changed a lot by month nine. Keep the annual independent test and add scheduled testing in your pipeline, as our article on continuous penetration testing explains. The yearly test satisfies the auditor. Continuous testing stops findings piling up between audits.

What evidence should you keep for your SOC 2 audit?

Build the evidence folder while the test runs, not the week before fieldwork. Expect the auditor to ask for the following.

Teams forget the last two items most often. Auditors want proof that management read the report and acted.

Confidentiality of the report itself

A pentest report is a map of your weak points. Keep it restricted, give customers a summary or letter, and share the full report only under NDA.

What should a SOC 2 pentest report contain?

One report serves your auditor and your customers, so it has to read well to both. Check a draft for these parts. Our posts on what belongs in a finding and how to read a penetration test report go deeper.

• Scope and dates that match your SOC 2 system description.
• Method, including which standards the tester followed and what they could and could not test.
• An executive summary a non-specialist can read in two minutes. See executive summary.
• Each finding with evidence: the request, the response, steps to reproduce, and the weakness type mapped to a CWE and, where relevant, the OWASP Top 10.
• Severity kept separate from confidence, so a reader knows how bad it is and how sure the tester is. See severity versus confidence.
• Fix guidance specific enough for an engineer to act on.
• A retest section, or a separate retest report, that records the outcome per finding.

Be wary of reports that list many "possible" issues without proof. They create work for engineers and questions from your auditor. A report built on exploited, reproducible findings is easier to fix and to defend. Our post on exploited, not suspected makes that case in detail.

What should a SOC 2 penetration test actually test?

The SOC 2 criteria care about access, change and detection, and a good web application test lines up with them. Serious findings cluster in a short list of categories.

Application and API tests

Access control and tenant separation

Can one customer's account read or change another customer's records? Can a standard member reach admin functions? These are IDOR and BOLA issues, the object-level form of broken access control, which leads the current OWASP Top 10 (2025 edition). They map to CC6.1 and CC6.3, and for a multi-tenant product they are the OWASP-class finding enterprise buyers worry about most.

Authentication and sessions

Password reset, MFA enrolment and bypass, session handling, token expiry, and account lockout. A weakness here is a route to account takeover.

Injection and input handling

SQL injection, cross-site scripting, server-side request forgery and file upload flaws, tested against the real application and its APIs. The OWASP API Security Top 10 (2023) is the usual reference for the API side.

Business logic

Rules your own product enforces, such as limits, approvals and pricing. A scanner has no way to know that a refund should not exceed the payment, so this needs a tester who has read how your product is meant to work. See business logic flaws.

Configuration and exposure

Debug modes left on, exposed admin panels, permissive cloud storage, weak transport settings and missing security headers. These are the easy wins that also help CC7.1.

What should you do with findings before the audit window closes?

The report starts the evidence trail. Auditors look at what you did next, and a tidy process is easy to describe and to prove.

1. Triage within days. Confirm each finding, set the owner and agree the severity. The finding triage page explains the questions to ask.
2. Set target dates by severity. Most teams write them into policy, for example faster for critical and high findings than for low ones. A written remediation SLA that you then meet is stronger evidence than a vague promise.
3. Fix the root cause. Patching one endpoint while ten like it stay open invites the same finding next year. See root cause.
4. Retest. Have the same exploit re-run against the fixed code and record the result. This is the closed-loop retest and it is what turns "we think it is fixed" into evidence.
5. Record accepted risk. If a finding will not be fixed, write down why, who approved it, the compensating control and the review date.
6. Close the ticket with a link to the retest result.

Try not to leave critical or high findings open when the audit window closes. They do not fail you automatically, but a serious finding with no plan can raise an exception, and exceptions appear in the report your customers read. Our vulnerability remediation process guide covers the full workflow.

When should you test for a Type I or Type II report?

A Type I report looks at whether controls are suitably designed at a single date. A Type II report looks at whether they operated over a period, commonly six or twelve months. The pentest plays a slightly different role in each.

If your first audit is a Type I, run the pentest first and bring the report to the readiness call. If you are heading into Type II, put the test in the first third of the window. That leaves room to fix, retest and, if needed, run a second test after a big release. Our term page on SOC 2 Type II explains the period in more detail.

Who can run a SOC 2 penetration test?

SOC 2 requires no particular certification or firm. Auditors care that the tester is competent, independent and clearly documented. When you shortlist, ask four things. Have they tested applications like yours? Will they give you a sample report? How do they handle retests? Will they answer your auditor's questions? Our guide on how to choose a penetration testing company has a longer list, and choosing a pentest provider gives the short version.

Also ask where your code and data will go. Some teams cannot send source code or customer-like data outside their network, and a few auditors ask about that handling during vendor management. If that is you, look for a provider that can work inside your own network.

How does Cyberlop fit a SOC 2 programme?

Cyberlop finds vulnerabilities in web applications and their APIs using black-box, grey-box and white-box pentesting. It reports only findings it exploited, and each carries the request, the response, a screenshot where a person can see it and, in white-box mode, the line of code. Severity and confidence are kept apart, and findings carry CWE and OWASP references. See what the evidence looks like.

A fix is proven by re-running the exact exploit against the new code, so the retest record is a dated, reproducible result. Cyberlop can also run on a schedule or in CI/CD and gate a build, between the annual tests. If your code must stay in your network, private scanning runs inside it. See how it works. Agencies preparing clients for SOC 2 can run it under their own brand through the agency programme.

It supports your audit evidence and does not replace your auditor's judgement. Whether a given test satisfies a given criterion is for your CPA firm to decide, so share the report and method with them early.

Which mistakes cost teams the most audit time?

• Testing the wrong thing. The pentest covers a brochure site while the product and its APIs sit outside scope.
• Booking too late. The report lands in the final week, with no time to fix or retest.
• Testing with one account. The cross-account flaws that matter most are never reached.
• No retest. The report shows ten findings and nothing shows they were closed.
• Calling a scan a pentest. A scanner printout is described as a penetration test, and the auditor notices.

What does a twelve-month SOC 2 testing plan look like?

1. Month 1. Confirm the system boundary with your auditor. Write the scope, and agree which criteria the test will support.
2. Month 2. Prepare accounts in at least two tenants, a staging copy and the contact for questions. Book the test.
3. Months 2 to 3. Run the test. Triage within days. Fix critical and high findings first.
4. Month 4. Retest. Store the report, remediation log and retest result in the evidence folder.
5. Months 5 to 11. Scan on a schedule and on release. Add pipeline checks for the classes of flaw you found. Retest after any major change.
6. Month 12. Repeat the independent test, compare against last year's findings, and update the risk assessment.

That cycle gives you evidence for CC3.2, CC4.1, CC7.1 and CC8.1, and the evidence improves each year. Our VAPT checklist has the detailed before, during and after steps. If you also work to other standards, one test can often serve several. See our guides on ISO 27001 and PCI DSS penetration testing.