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 what the auditor is examining.

The stakes scale with the estate. A single-product startup can paper over a thin scope for a while. A mid-market or enterprise SaaS business cannot: several products, multi-tenant data separation, a system description spanning multiple applications and more than one cloud account, and a procurement function that will forward the report into customer security reviews for a year. The test stops being a compliance errand and becomes a supply-chain artefact.

This guide covers the intersection precisely, for buyers in Canada and the United States: 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 must contain, what procurement will ask a vendor, and how to decide between a one-time engagement and continuous coverage.

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. Startups are one segment of the audience, not the default reader.

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, and the examination runs under SSAE No. 21, which superseded AT-C section 205 for 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 listing evaluation types management "may include". There is no pentest criterion 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 criteria does not require an assessment of whether each point of focus is addressed, and lets management customise or substitute them. The AICPA's 2022 revision updated the points of focus and implementation guidance, not the criteria themselves, as EY's summary confirms.

CC7.1 is not the pentest criterion, though it is routinely cited as one. It covers detection of configuration changes that introduce new vulnerabilities, and its point of focus is labelled "Conducts Vulnerability Scans". Hand an auditor a pentest report against a CC7.1 request and 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 ongoing or separate evaluations of 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 ask about in security reviews. Auditors expect testing evidence because you 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 sits in the system description the service auditor examines, and it becomes the standard you are measured against for the whole period. It is the highest-leverage hour in a SOC 2 programme, and it is usually spent copying a template.

Two rules follow from that table.

Promise the cadence you can hold, not the one that sounds impressive. "Annually and after significant changes" reads well in a security 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 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 over-claiming in the system description.

A pentest is strongest under CC4.1 and CC4.2, useful as corroboration under CC6 and CC8, and actively misleading offered 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 the description covers a portfolio of customer-facing applications, their APIs, the supporting cloud infrastructure and internal administrative tooling, a test that covers only one unauthenticated public web app leaves most of the described system unevidenced. On a multi-product estate this is the default failure, not the edge case.

Work through it in this order.

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

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

3. Include the API surface explicitly. Modern products are mostly API. If the scope says "web application" and the auditor's request says "the system", the gap surfaces 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 AWS specifics, 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 knows the dates, the test proves nothing about detection. That is a legitimate choice; just do not claim criteria it did not exercise.

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

For the 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. If cardholder data is in scope, PCI DSS Requirement 11.4 adds internal, external and segmentation obligations on their own clock.

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, not a standard; neither TSP section 100 nor the description criteria prescribe a length. Most first-year Type 2 reports use three to six months, 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: far enough in that the control is demonstrably operating within the period, early enough that remediation, retest and ticket closure 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, 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. Moving from Type 1 to Type 2, check the dates: 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 to close tickets, sign risk acceptance memos and assemble the evidence package.

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

Retesting and the CC4.2 loop

Commissioning a test and filing the report is worse than not commissioning one. CC4.2 requires deficiencies to be 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 is 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. A provider who prices remediation verification separately, and slowly, becomes the reason your evidence package is late. On a multi-application programme, insist on the same retest turnaround for every application.

One test a year, or continuous testing

A Type 2 asks whether the control operated throughout the period, and the number of times it ran is the population the auditor samples. Run once and the population is one, so a single missed or late cycle is a 100 percent exception rate. 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 cheaper and entirely legitimate.

Continuous testing, or [PTaaS](https://www.stingrai.io/ptaas), fits when you ship weekly, when the control description mentions significant changes, when you carry 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. On a multi-product estate the two models coexist, with the flagship application on continuous coverage and secondary applications on a dated annual cycle.

Our explainer on continuous PTaaS covers how the delivery model differs from a project engagement, and the budget case for continuous penetration testing runs the numbers against an annual engagement. Whichever you pick, the rule from the control description section 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:

First-time programmes land in the web application and API bands. Multi-product estates multiply the application line and add cloud scope, which a SaaS system description nearly always includes.

Three costs buyers forget: 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.

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

Canadian price bands

Canadian buyers budget in CAD and are usually comparing a Toronto or Montreal provider against a US one. The bands below come from our ranking of top penetration testing companies in Canada, compiled from published Canadian vendor pricing.

Stingrai publishes fixed prices rather than quote-only bands: the Autonomous Pentest starts at US$3,000 and the Hybrid Pentest with penetration testers is US$6,800 as one-time engagements, with continuous programmes priced as monthly subscriptions. Current figures are on the pricing page, and multi-application estates are scoped per application under one agreement.

Canadian companies buying SOC 2 for US customers

Most Canadian SaaS companies do not pursue SOC 2 for a Canadian regulator. They pursue it because a US enterprise buyer's procurement team made the report a condition of the contract. Three consequences follow.

SOC 2 sits on top of Canadian privacy law, it does not replace it. PIPEDA federally, and Quebec's Law 25, impose obligations no Trust Services criterion covers. A US customer asking for SOC 2 will often ask separately about Canadian data handling.

Data residency surfaces twice. Once in your system description, where the location of production data is part of the described system, and again in the engagement, where findings, credentials and test evidence sit with the provider. Ask where report data is stored, which jurisdiction the portal runs in, and whether a subcontractor touches it. A provider who cannot answer that in the MSA is a procurement problem before it is a security one.

US federal buyers are a different track. If the customer pulling you toward SOC 2 is a US government agency or a contractor serving one, the requirement usually escalates to FedRAMP and its prescriptive annual testing against a defined attack-vector list. See our guide to FedRAMP penetration testing requirements first.

The evidence pack to hand your auditor

Assemble this before fieldwork opens, not during it. On a multi-application estate, assemble it per application and keep the format identical across all of them.

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 and the report, showing a structured test with findings, severities and evidence per finding

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

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

6. The retest artefact, verifying closure, plus an attestation of completion if your customers ask for a shareable summary

7. 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. Anything on the list your description does not imply 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, and the default failure on a multi-product estate. Reconcile the two before the period opens.

2. Unauthenticated-only testing, or no retest. The first evidences almost nothing about authorisation controls; the second leaves CC4.2 half-evidenced.

3. Adjectives you cannot evidence. Independent, qualified and comprehensive are all assertions the auditor will verify.

What a mid-market or enterprise buyer needs from a pentest vendor

A startup buys a report. A mid-market or enterprise programme buys a vendor that has to survive procurement, customer security review and the audit at once, usually across several applications and more than one framework. Eight things decide whether it clears all three.

Procurement and security questionnaire fit. Your vendor-risk process runs the penetration testing firm through the same questionnaire every supplier gets. Findings data is among the most sensitive material you will hand a supplier, so expect questions on access controls, background checks, subcontracting and retention. A provider who cannot answer quickly stalls the purchase for weeks.

An attestation of completion the auditor can read. Alongside the technical report, ask for a signed letter confirming the engagement, the dates, the scope tested and that remediation was verified. It is what you attach to the evidence request and what you share with customers who should not receive full findings. The SOC 2 opinion comes from your service auditor, a CPA firm; the letter evidences that your testing control ran.

Named testers with verifiable credentials. SOC 2 imposes no qualification bar, but if your control description says "qualified", the auditor verifies the assertion. Firm-level accreditation and named individual certifications are different things, and our guide to CREST-accredited penetration testing companies explains which is which. Ask who is actually assigned, not who is on the website.

Retesting scoped into the engagement. In the contract, with a committed turnaround, not sold as an add-on after the report lands. Late retesting is the most common reason a SOC 2 evidence package misses fieldwork.

Portal access rather than a PDF. Role-based access for engineering, status per finding, export into your issue tracker, history across periods. For a multi-application estate that is the difference between one evidence pull and twelve.

MSA and insurance terms you can sign. Liability caps, indemnity, professional and cyber liability certificates at your policy limits, subprocessor disclosure, and clarity on who performs the work. Raise these in week one, the usual cause of a signature slipping a month.

Multi-application scoping under one reporting standard. Separate scope documents per application, but one methodology, one severity scale, one report format. Mixed severity scales make remediation tracking unreadable to an auditor sampling the whole estate.

Both cadences available in one contract. The flagship product may warrant continuous coverage while secondary applications run a dated annual cycle. Stingrai delivers both one-time annual penetration tests and continuous programmes, so cadence can differ per application without a second vendor.

The pentest and red team RFP question bank turns these asks into a scoreable form. For a ranked view of providers that clear the bar, see our best penetration testing companies for SOC 2 in 2026. If the described system is AWS-heavy, the best cloud penetration testing companies for AWS and SOC 2 covers that shortlist.

Where Stingrai fits

Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements, delivered through its PTaaS platform. Each human-led engagement is staffed with two named penetration testers, reviewed by the team lead and an engagement partner, so a service auditor asking who performed the test gets names and certifications rather than a logo. The team has published 18 CVEs and includes a founding member of Uber's offensive security team and researchers credited in the bug bounty Halls of Fame of Apple, Google, the US Department of Defense and the US Federal Reserve.

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, retesting of remediated findings scoped into the engagement rather than sold afterwards, and an attestation letter and verified badge issued with the report. For the multi-tenant SaaS systems most SOC 2 reports describe, testing is authenticated across every user role and tenant boundary against OWASP ASVS, and the cloud side runs control plane to workload, covering cross-account role assumption, bucket and resource policies and instance metadata abuse on AWS, and app registrations, service principals, consent grants and Conditional Access gaps on Entra ID, which is where the logical access criteria are usually proven or broken. Where a control description promises testing after significant changes, we scope the cadence to match the promise. Both one-time annual engagements and continuous programmes are available, so a multi-application estate can mix the two under one contract and one reporting standard.

Snipe, our autonomous web application testing agent, hunts the complex authorisation, IDOR and business logic flaws a scanner will never reach, performs white-box review against application source, and can gate pull requests before vulnerable code merges. That matters for SOC 2 because broken authorisation between tenants and roles is the failure mode most likely to become a customer-visible incident inside your observation period. On the Hybrid tier our penetration testers test concurrently with Snipe for the whole engagement, directing where it focuses and extending the attack paths it opens, and both contribute findings at every severity. Findings reach the PTaaS portal as they are confirmed, each with a working proof of concept and prioritised remediation guidance, with live chat to the assigned testers and a push into Jira or Slack, so fixes can land inside the observation period rather than after it. Engagement options are on our pricing page.

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 separate evaluations of your controls, and a penetration test is the evaluation most service organisations select and then write into their own control description. The SOC 2 pentest requirements that actually bind you are the ones in that sentence: if it says "annual penetration test by a qualified third party", the auditor tests you against exactly that.

What should a mid-market or enterprise buyer ask a SOC 2 penetration testing vendor?

Eight things, in writing, before the MSA is signed: how they answer your security questionnaire about their own controls and subcontracting, whether they issue a signed attestation of completion your auditor can read, which named testers with which certifications are assigned, whether retesting is in the contract with a committed turnaround, whether findings sit in a portal with issue-tracker export, what their liability caps and insurance limits are, how they scope several applications under one severity scale and report format, and whether they offer both one-time annual engagements and continuous programmes.

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 before fieldwork to close tickets and assemble the evidence package. Anchor the schedule to the observation period, not 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 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. Canadian bands run roughly C$5,000 to C$12,000 for a small web application and C$40,000 to C$120,000 for an annual continuous programme. Budget separately for retesting and 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. Teams that ship frequently, or whose control description mentions testing after significant changes, are better served by continuous testing, and a multi-product estate can run both models side by side.

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 marked applicable in your Statement of Applicability, and parts of PCI DSS Requirement 11.4. The frameworks differ in what they mandate and 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 verifies that assertion, so firm-level accreditation and named certifications become evidence rather than marketing. The examination itself is performed by a CPA firm.

Related reading

• Best penetration testing companies for SOC 2 in 2026

• Best cloud penetration testing companies for AWS and SOC 2

• FedRAMP penetration testing requirements in 2026

• Best penetration testing companies in the USA

• Top penetration testing companies in Canada

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

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