SOC 2 Penetration Testing: What Auditors Expect and How to Scope It (2026)

SOC 2 does not name penetration testing as a requirement, and almost every SOC 2 Type 2 report is backed by one anyway. That gap between what the framework says and what happens in the audit room is where most scoping mistakes are made, and it is expensive: teams buy the wrong test, run it at the wrong time, and arrive at fieldwork with a report that does not evidence the thing the auditor is actually examining.

This guide covers the intersection precisely. What the AICPA Trust Services Criteria actually say about testing, where a pentest lands in the Common Criteria, how to scope it against your system description, when to run it inside a Type 2 observation period, what a retest artefact needs to contain, and how to decide between a one-time engagement and continuous coverage.

The clause-level forensics across several frameworks at once live in our companion post on pentest evidence auditors accept across SOC 2, ISO 27001, PCI DSS and CMMC. This page is the SOC 2 operating manual.

SOC 2 pentest requirements: what is mandated and what is expected

A SOC 2 report is an attestation examination performed by a CPA firm against criteria published by the AICPA. The criteria live in TSP section 100, the 2017 Trust Services Criteria with Revised Points of Focus 2022. The examination itself runs under the AICPA attestation standards, where SSAE No. 21 superseded AT-C section 205 for practitioners' reports dated on or after 15 June 2022.

Three facts about that criteria document decide everything downstream.

Penetration testing is named once, and not as a requirement. The phrase appears a single time in the whole Trust Services Criteria, inside a point of focus under CC4.1 that lists evaluation types management "may include". There is no pentest criterion, no pentest control number, and no mandated frequency. Searches for "annual", "quarterly" and "at least once" across the criteria return nothing.

Points of focus are illustrative, not binding. TSP section 100 states that use of the trust services criteria does not require an assessment of whether each point of focus is addressed, and allows management to customise or substitute them. When the AICPA revised the document in 2022, it updated the points of focus and the description criteria implementation guidance, not the criteria themselves. EY's summary of that revision makes the same point.

CC7.1 is not the pentest criterion. It is routinely cited as one. CC7.1 covers detection of configuration changes that introduce new vulnerabilities and susceptibility to newly discovered ones, and its point of focus is labelled "Conducts Vulnerability Scans". If you hand an auditor a pentest report against a CC7.1 request, expect them to come back asking for scan output.

So the honest framing is this. SOC 2 does not require penetration testing. CC4.1 requires you to select, develop and perform ongoing or separate evaluations that determine whether the components of internal control are present and functioning, and a penetration test is the separate evaluation most service organisations pick, because it is the one their customers and prospects ask about in security reviews. Auditors expect testing evidence because you almost certainly told them you would produce it.

The sentence that creates your only binding pentest obligation

There are 33 common criteria across CC1 to CC9 for the Security category, and none of them tells you how often to test. Your control description does. That sentence, written by you, sits in the system description that the service auditor examines, and it becomes the standard you are measured against for the whole period.

This is the single highest-leverage hour in a SOC 2 programme, and it is usually spent copying language out of a template.

Two rules follow from that table.

Promise the cadence you can hold, not the cadence that sounds impressive. "Annually and after significant changes" reads well in a sales questionnaire and is the most common source of SOC 2 pentest exceptions we see, because nobody maintains the reconciliation between the change log and the testing schedule.

Every adjective is a test. Independent, qualified, third-party, comprehensive, full-scope: each one gives the auditor something extra to verify. Write only the adjectives you can evidence.

Mapping a penetration test to the Common Criteria

A pentest is not a single-criterion artefact. Scoped properly, it corroborates several criteria, and knowing which ones it does not touch stops you from over-claiming in the system description.

The practical takeaway: a pentest is strongest under CC4.1 and CC4.2, useful as corroboration under CC6 and CC8, and actively misleading if you offer it in place of scanning under CC7.1.

How to scope a SOC 2 penetration test

The governing rule is simple and almost always the thing that goes wrong. The boundary of the test should match the boundary of the system in your SOC 2 system description. If your description says the system includes the customer-facing web application, its APIs, the supporting cloud infrastructure and the internal administrative tooling, a test that covers only the unauthenticated public web app leaves three quarters of the described system unevidenced.

Work through it in this order.

1. Pull the system description first. Scope the test to the description, not to what is convenient to test. Where the two differ, either widen the test or narrow the description before the period opens.

2. Include authenticated testing across every role. The unauthenticated perimeter is the smallest part of the risk. Broken authorisation between tenants, roles and object identifiers is where real SOC 2 relevant exposure lives, and it is invisible to an unauthenticated scan.

3. Include the API surface explicitly. Modern products are mostly API. If the test scope says "web application" and your auditor's request says "the system", the API gap will surface during fieldwork.

4. Decide on the infrastructure layer deliberately. Cloud configuration, identity attack paths and segmentation between production and corporate networks are usually inside the described system. For the AWS specifics, including which services can be tested without prior approval, see our guide to scoping a cloud pentest for SOC 2 Type II on AWS. For Microsoft estates, our Azure and Entra ID scoping guide covers the identity layer.

5. Write detection objectives in, or accept you cannot claim CC6.8 and CC7.2. If the engagement is fully allow-listed and the security team is told the dates, the test proves nothing about detection. That is a legitimate choice. Just do not claim the criteria it did not exercise.

6. Name the environment. Testing a staging clone is defensible if the description explains it and the clone is configuration-identical. Testing staging while the description promises production testing is an exception waiting to happen.

For the general mechanics of turning this into a statement of work, our guide on how to scope a penetration test covers rules of engagement, credentials, and the questions a provider should be asking you.

SOC 2 Type 1 vs Type 2 pentest: what actually changes

The difference is not the test. It is what the report has to prove.

A Type 1 opines on whether controls are suitably designed and implemented as of a specified date. A Type 2 opines on whether those controls were suitably designed and operated effectively throughout a specified period.

Observation periods of three to twelve months are market practice rather than a standard. Neither TSP section 100 nor the description criteria prescribe a period length. Most first-year Type 2 reports use three to six months and then move to twelve.

Timing: where the test goes in the audit window

For a twelve-month Type 2, testing in months four to five is the sweet spot. It is far enough in that the control is demonstrably operating within the period, and early enough that remediation, retest and ticket closure all land inside the window with room before fieldwork.

The three timing errors that cost the most:

Testing too late. A test in month eleven produces findings you cannot remediate and retest before the period closes. The auditor sees open criticals with no closure evidence, which is a CC4.2 problem rather than a CC4.1 one.

Testing too early, or before the period. A test completed two weeks before the period opened evidences the previous period, not this one. If you are moving from a Type 1 to a Type 2, check the dates carefully: the Type 1 as-of date is usually the day before the Type 2 period begins, so the test that supported your Type 1 will not support your Type 2.

Leaving no gap before fieldwork. Give yourself 30 to 60 days between the retest and the start of fieldwork. Remediation tickets need to be closed, risk acceptance memos signed, and the evidence package assembled. Fieldwork is not the time to be chasing a developer for a closure comment.

One more timing point that catches multi-year programmes: if you run a single annual test on a fixed calendar date and your observation period shifts, you can end up with two tests in one period and none in the next. Anchor the test schedule to the period, not to the calendar.

Retesting and the CC4.2 loop

Commissioning a test and filing the report is worse than not commissioning one. CC4.2 requires that deficiencies are evaluated, communicated to those responsible for corrective action, and tracked to resolution. The moment you elect a penetration test as your CC4.1 evaluation, its findings enter that loop.

There is no rule that every critical must be closed. Untracked findings, not the existence of findings, are the audit problem. A finding that is triaged, assigned, risk-accepted by a named owner with a documented rationale, and reviewed, is perfectly defensible. A finding sitting in a PDF with no ticket is not.

A retest artefact that survives fieldwork contains:

• The original finding identifier, severity and date, so it reconciles against the initial report

• The date of the retest and the environment it ran against

• The verification result per finding: fixed, partially fixed, not fixed, or risk accepted

• The name of the tester who verified it

• For risk-accepted items, a reference to the memo and the approver

Get the retest written into the engagement up front rather than bought as an add-on later. A provider who prices remediation verification separately, and slowly, will become the reason your evidence package is late.

One test a year, or continuous testing

A Type 2 asks whether the control operated throughout the period. The number of times it ran is the population the auditor samples. Run once, and the population is one, which means a single missed or late cycle is a 100 percent exception rate on that control. Run continuously, and one slipped cycle is a minor exception against a healthy population.

A one-time annual engagement fits when the product surface is stable, releases are infrequent, the observation period is short, and the control description promises annual testing and nothing more. It is the cheaper option and it is entirely legitimate.

Continuous testing or PTaaS fits when you ship weekly, when the control description mentions significant changes, when you are carrying a multi-framework programme, or when customer security reviews keep asking for recent evidence. It also solves the reconciliation problem: if testing runs continuously, "after significant changes" is satisfied structurally rather than by manual scheduling.

Our explainer on continuous PTaaS covers how the delivery model differs from a project engagement, and the budget case for continuous penetration testing works through the numbers against an annual engagement.

Whichever you pick, the rule from the control description section still governs: write the cadence you can hold, then hold it.

What penetration testing for SOC 2 compliance costs in 2026

Scope drives price far more than the framework does. A SOC 2 test is not a distinct product with a premium attached; it is a test scoped to your described system, delivered with evidence an auditor can read.

From our 2026 penetration testing cost guide, aggregated across published vendor pricing and industry cost guides:

Most first-time SOC 2 programmes land in the web application and API bands. Add cloud scope when the described system includes the infrastructure layer, which for a SaaS product it usually does.

Three costs buyers forget to budget: remediation retesting, a second test if the observation period shifts, and engineering time to fix what is found. That last one is normally the largest line item and never appears in a vendor quote. Continuous engagement pricing works differently again, since it is a subscription rather than a project. Current Stingrai package pricing is published on our pricing page, where the autonomous and hybrid programmes are listed as monthly subscriptions on twelve-month engagements.

For a wider vendor-by-vendor view of the compliance testing market, see our compliance and regulation pentesting services guide.

The evidence pack to hand your auditor

Assemble this before fieldwork opens, not during it.

1. The engagement letter or statement of work, dated, showing the control was authorised and the engagement falls inside the period

2. The scope definition as a distinct artefact, naming systems, environments, roles and exclusions, reconcilable against the system description

3. The methodology, showing the test was structured rather than ad hoc

4. The report, with findings, severities and evidence per finding

5. Remediation tracking, with ticket identifiers, owners, open and close dates

6. Risk acceptance memos for anything not fixed, with a named approver

7. The retest artefact, verifying closure

8. Provider qualification evidence, if your control description asserts a qualified or independent tester

If your control description promises something not on this list, add it. If something on this list is not implied by your control description, it is still worth having, because it answers the follow-up question before it is asked.

Our broader guide on how to prepare for a SOC 2 audit covers everything around this: gap analysis, control implementation, readiness assessment and evidence collection across the full programme.

Mistakes that turn a pentest into an exception

1. Scope narrower than the system description. The most common finding. Reconcile the two before the period opens.

2. Unauthenticated-only testing. Produces a clean-looking report that evidences almost nothing about authorisation controls.

3. Testing outside the period. Dates are the first thing an auditor checks.

4. No retest. Leaves CC4.2 half-evidenced.

5. Claiming detection criteria for an allow-listed test. If nobody was watching, the test proves nothing about monitoring.

6. A control description with adjectives you cannot evidence. Independent, qualified and comprehensive are all assertions the auditor will verify.

7. Offering a pentest where the auditor asked for scan output. CC7.1 wants scanning. Run both.

8. Buying a "SOC 2 pentest" product without checking the scope. Some cheap packages are automated scans with a compliance-branded cover page. Read the methodology.

How to choose a provider

The framework does not impose any qualification bar on the tester. SOC 2 sets no certification, accreditation or independence requirement for penetration testing. Your control description might, and your customers almost certainly will, which is where provider selection actually matters.

Ask for four things:

• A methodology you can read, not a tool list. It should describe how authorisation, business logic and privilege boundaries are tested, since those are the classes that matter most to a SaaS system description.

• Firm-level accreditation or named certifications, if your control description says "qualified". Our guide to CREST-accredited penetration testing companies explains what firm-level accreditation actually verifies and how it differs from individual certifications.

• Retesting included in the engagement, with a committed turnaround.

• Deliverables shaped for an auditor, including a separate scope document and findings written so a non-specialist reviewer can follow the risk.

For a shortlist, our ranking of the best penetration testing companies in 2026 covers the wider market, and our guide on choosing a penetration testing service provider works through the evaluation criteria in more depth.

Where Stingrai fits

Stingrai is a CREST-accredited penetration testing service provider founded in 2021, with teams in Toronto and London, 18 published CVEs and a 5.0 out of 5.0 rating across 19 Clutch reviews. Our team holds OSCE3, OSCP, OSWE, OSEP, CREST CRT, CISSP and CRTO, and presents research at DEFCON and BSIDES.

Our penetration testing supports your SOC 2 compliance programme by producing the artefacts a service auditor asks for: a defined scope of work as a distinct deliverable, a documented methodology, findings mapped to the criteria you are evidencing, and remediation retesting scoped into the engagement rather than sold afterwards. Where a control description promises testing after significant changes, we scope the cadence to match the promise rather than leaving you to reconcile it manually.

Snipe, our autonomous web application testing agent, hunts the complex authorisation, IDOR and business logic flaws that a scanner will never reach, performs white-box review against application source, and can gate pull requests so vulnerable code is caught before it merges. That matters for SOC 2 specifically, because broken authorisation between tenants and roles is the failure mode most likely to turn into a customer-visible incident inside your observation period. Senior testers validate and extend what Snipe finds, and our PTaaS platform keeps evidence flowing across the whole period rather than once a year. Engagement options are on our pricing page.

The wider stakes are worth stating plainly: IBM's 2026 Cost of a Data Breach Report puts the global average breach cost at US$4.99 million, up 12 percent year on year, as reported by Infosecurity Magazine. The report is the compliance artefact. The testing is the point.

Frequently Asked Questions

Does SOC 2 require penetration testing?

No. SOC 2 does not require a penetration test. The phrase "penetration testing" appears exactly once in the entire AICPA Trust Services Criteria, inside a non-binding point of focus under CC4.1 that lists evaluation types management may include. There is no pentest criterion and no mandated frequency. In practice, auditors expect testing evidence because CC4.1 requires you to perform separate evaluations of your controls, and a penetration test is the evaluation most service organisations select and then write into their own control description.

What are the SOC 2 pentest requirements?

There is no framework-imposed requirement. The binding obligation is whatever your control description promises. If it says "annual penetration test by a qualified third party", the auditor tests you against exactly that: one test inside the period, scoped as described, plus evidence the provider was qualified. Before you write that sentence, make sure you can hold the cadence and evidence every adjective in it.

What is a SOC 2 Type 2 pentest and how is it different from Type 1?

The test is the same. What changes is what it has to prove. A Type 1 opines on control design and implementation as of a single date, so an engagement letter, a defined scope and a recent test can support it. A Type 2 opines on operating effectiveness across a period, so the test, the remediation and the retest all have to fall inside that period. A test dated before the period opened or after it closed does not evidence the period.

When should we run the penetration test for a SOC 2 Type 2 audit?

Months four to five of a twelve-month observation period. That places the test clearly inside the window, leaves time for remediation and a retest before the period closes, and gives you 30 to 60 days between the retest and the start of fieldwork to close tickets and assemble the evidence package. Anchor the schedule to the observation period rather than to a fixed calendar date.

What penetration test evidence does a SOC 2 auditor accept?

A dated engagement letter or statement of work proving the control was authorised inside the period, the scope definition as a separate artefact that reconciles against your system description, the documented methodology, the report with findings and severities, remediation tracking with ticket identifiers and closure dates, risk acceptance memos for anything not fixed, and a retest artefact verifying the fixes. The remediation loop matters as much as the report, because CC4.2 requires deficiencies to be tracked to resolution.

How much does penetration testing for SOC 2 compliance cost?

Scope sets the price, not the framework. In 2026, a web application test runs US$5,000 to US$30,000 or more, an API test US$6,000 to US$30,000, network testing US$5,000 to US$40,000 or more, and cloud scope US$10,000 to US$50,000 or more. Most first-time SOC 2 programmes land in the web application and API bands, plus cloud scope if the described system includes infrastructure. Budget separately for retesting and for the engineering time to fix findings.

Do we need a new penetration test every year for SOC 2?

Only if your control description says so, or if your observation period requires it. SOC 2 sets no frequency. That said, a single annual test gives the auditor a population of one, so one missed or late cycle becomes a 100 percent exception rate on that control. Teams that ship frequently, or whose control description mentions testing after significant changes, are usually better served by continuous testing.

Can a vulnerability scan replace a penetration test for SOC 2?

For CC4.1 a scan is a legitimate separate evaluation, so technically yes, if that is what your control description promises. But scanning and penetration testing answer different questions, and CC7.1's point of focus specifically names vulnerability scanning, so an auditor requesting CC7.1 evidence wants scan output rather than a pentest report. Run both, and be precise about which criterion each one supports.

Can one penetration test cover SOC 2 and ISO 27001 or PCI DSS?

Usually yes, with care. A well-scoped application and infrastructure test can evidence SOC 2 CC4.1, ISO 27001 controls you marked applicable in your Statement of Applicability, and parts of PCI DSS Requirement 11.4. The frameworks differ in what they mandate and in the artefacts they expect, so confirm the mapping with each auditor. Our cross-framework evidence guide sets out the differences clause by clause.

Who should perform a SOC 2 penetration test?

SOC 2 imposes no qualification, certification or independence requirement on the tester, so an internal team can satisfy CC4.1. The constraint comes from your own control description and from customer expectations. If your description asserts an independent or qualified third party, the auditor will verify that assertion, so firm-level accreditation and named certifications become evidence rather than marketing. The examination itself must be performed by a CPA firm acting as service auditor.

References

• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus 2022), TSP section 100

• EY, AICPA revises guidance on applying its Trust Services Criteria and SOC 2 Description Criteria, To the Point No. 2022-13, November 2022

• AICPA, SOC 2 reporting resources and guidance

• Infosecurity Magazine, The Average Cost of a Data Breach Rises to $5 Million, reporting IBM Cost of a Data Breach Report 2026

• Stingrai, Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC

• Stingrai, Cloud Pentest for SOC 2 Type II on AWS: 2026 Scope Guide

• Stingrai, Penetration Testing Cost in 2026