SOC 2 penetration testing: requirements and real prices

By The PenTest Index

SOC 2 penetration testing is not required by name. The AICPA criteria list it as one evaluation a company may use, so the real requirement comes from your own controls, your auditor or a customer contract. Before you buy, confirm what must be tested, whether automated-only testing counts, and what retest proof is needed.

Among the offers we checked on October 9, 2026, published starting prices for human-led testing of one web app run from US$3,400 at Pentest-Tools.com (no logged-in testing) to US$10,800 at Software Secured. The gap is mostly scope and retest terms, and both are laid out below. Jump to the offers.

Is SOC 2 penetration testing required?

No. The criteria your auditor uses describe outcomes, and they leave the choice of controls to you.

SOC 2 reports are written against the AICPA's Trust Services Criteria. We read the current edition, the 2017 criteria with points of focus revised in 2022. Here is what it says, in plain terms:

Source: AICPA, 2017 Trust Services Criteria (With Revised Points of Focus – 2022), read October 9, 2026.

One thing to know: many pages quote a different sentence for CC4.1, one that mentions ISO certifications. The edition we read does not use that sentence. If someone sends you a quote from "the SOC 2 rules," ask which edition it comes from.

So where does the requirement come from? Three places, and you can check each one.

If none of the three asks for a pentest, you may not need to buy one right now. If one does, the next step is to find out exactly what it needs.

What should you ask your auditor before buying?

Ask for the request in enough detail to price it: which systems, what kind of testing, what paperwork, and by when.

Copy these and send them. Use the same list for a customer who asked for a pentest.

1. Do you expect a penetration test for our report, or would another evaluation meet the need?
2. Which systems must it cover?
3. Is an automated or AI-led test acceptable, or do you need testing done by people?
4. Does the test need to fall inside our audit period, and how recent must it be?
5. Do you need proof that findings were fixed and rechecked? Is a summary letter enough, or do you need the full report?

Your auditor answers for the audit. Your customer answers for its own purchase rules. One answer does not settle the other.

For a longer list covering report contents and tester independence, see our questions for your report recipient.

Can you use a test you already have, or one bundled with another service?

Often, yes. Check it against the answers above before paying for a second one.

Look at five things: which systems it covered, when it ran, what has changed in your product since, whether findings were fixed and rechecked, and whether you are allowed to share the report. If the test came bundled with a compliance platform or an audit package, ask the seller in writing who did the testing and what was in scope. A discount code or a scanner subscription is a different thing from an included assessment. For that question, see whether a DAST scan can stand in for a penetration test.

If there is a gap, ask whether a smaller top-up test would close it before you assume you need a full new one.

What if the customer asked for a SOC 2 report and you only have a pentest?

Those are two different documents. A pentest report records one security test. A SOC 2 report comes from a CPA firm's examination of your system and controls. Ask the customer which one it needs, and whether it will accept other evidence while you work toward the report.

What should the test cover?

Start from your SOC 2 system boundary, which covers the infrastructure, software, people, procedures and data needed to provide the service, and confirm the boundary with your auditor.

A package sold as "one app" still leaves questions open. Write down each of these:

• The application and the environment to be tested (production, staging or other).
• Every API, including ones used only by a mobile app or by partners.
• The user roles to test while logged in, including admin roles.
• Tenant separation. A tenant is one customer's walled-off area in a shared app. If you serve many customers from one system, ask how the tester will check that one customer can't reach another's data.
• What is excluded, and why.

Cloud configuration reviews, internal network tests and mobile app tests are separate pieces of work. Ask whether each is needed and whether it is in the price. Not every company needs every one.

Say you run a 30-person SaaS company with one web app, the API behind it, and three roles: member, tenant admin and support. Testing only your marketing site would leave everything your customers care about untested. We use this made-up company through the rest of the page.

Write the scope once and send the same version to every provider, so the answers line up. Our scope checklist for a web app and its API lists the prompts. A scope document is a buying aid. It does not give anyone permission to test. That takes separate written authorization covering the actual targets and activities, agreed with your provider.

More on this: how to choose the assessment type and SaaS penetration testing.

SOC 2 pentest offers compared: prices, paperwork and retest terms

For our example company, the offers worth a scoped quote first are Blaze, Cobalt and Software Secured, because their stated retest windows are longer than the time the company needs to fix findings. Astra's Pentest Expert fits only with a written extension. Pentest-Tools.com and Synack need answers before they can be judged.

Here is the example in full. It is fictional, and no provider has quoted for it.

• One SaaS web app and its API, three logged-in roles, two test tenants, no source code shared.
• A customer contract that asks for testing done by people. That condition comes from this made-up customer. It is not a SOC 2 rule.
• Findings are reported March 1, 2027. Fixes will be ready April 6, which is 36 days later. The customer needs retest proof by April 16.

We compared nine offers from seven providers. Every fact below is what the provider publishes on its own page or marketplace listing, read October 9, 2026. Prices are in US dollars. Providers are listed A to Z, and this is not a ranking. We did not buy or run any of these tests.

Tests led by people

One more price, so the range at the top of this page is clear: Pentest-Tools.com also sells a black-box test at a fixed $3,400. It tests only as an anonymous visitor, so it would not cover the three logged-in roles in this example.

Tests led by AI

Read the human role in each one. Whether an AI-led test is enough is your auditor's or customer's decision, which is why question 3 comes before price.

Intruder advertises "Auditor-accepted, or your money back." That is a refund promise. It is not your auditor's approval, and a refund does not give you back the weeks.

How to choose from here

Start with the condition that would rule an offer out.

• Your fixes will take more than 30 days. Look first at Blaze, Cobalt and Software Secured. If you prefer Astra, get the extension and any added cost in writing before you sign.
• You need a signed letter for customers. Blaze states one. Ask every other provider what you receive besides the full report.
• You want to compare published starting figures for logged-in human-led testing. Blaze ("from $4,999") and Astra ($5,999 per year) show lower starting figures than the three-role Pentest-Tools.com example ($6,100). These are three different purchases: a project, an annual package and a starting formula. Compare written quotes for the same scope before calling any of them cheaper.
• Nobody has told you human testing is required. Send question 3. If the answer is that AI-led testing is fine, the second table opens up.
• You can't share source code. Intruder's listed offer does not fit.

Before you click through, here is the one question to send each provider.

Ask Astra whether it will include a recheck requested 36 days after findings are reported, and at what cost.

View Astra Pentest Expert

Ask Blaze which plan your quote is on, whether the retest window is 45 or 90 days, and what starts it.

View Blaze's SOC 2 pentest listing

Ask Cobalt how many credits your scope needs, which pentest type the quote covers, and the retest end date for your contract. According to Cobalt's documentation, its Comprehensive pentests are the type meant for reports shared with outside parties.

Request a Cobalt quote

Ask Pentest-Tools.com for one price covering the app, the API, three roles and a retest.

View managed web app testing

Ask Software Secured whether your quote includes one retest round or three.

View Software Secured pricing

Ask Synack whether the free Basic platform is enough for SynackST, and for an itemized total.

View Synack pricing

If AI-led testing is acceptable to your auditor and you can connect a repository, ask Intruder which price applies to you.

View Intruder pentest pricing

Will the cheaper quote be enough?

It can be, if the written scope and paperwork meet the same must-haves as the dearer one. A lower starting number does not tell you that.

Line the quotes up on four things: what is tested (apps, APIs, roles, tenants), who tests it, what you receive, and how fixes get rechecked and until when. If the cheaper quote matches on all four, take it. If it is cheaper because it leaves out logged-in roles or the retest, it is a smaller purchase, and you would be comparing two different things. Our Quote Check walks through this line by line, and penetration testing cost covers budgeting in more depth.

Your scope, roles and dates decide which of these offers fits. Find My PenTest Match gives you a free scope checklist to copy or print, with no contact details required, so every provider you contact answers the same questions. It prepares the conversation and does not pick a provider for you.

Find My PenTest Match

When should you book the test?

Early enough to fix what it finds and have the fixes rechecked before your evidence is due. Work backward from that date.

Two dates trip people up. The first is the retest deadline. The second is how far ahead you have to book.

The retest deadline. A retest-request window sets the date you must request by, and it starts from a specific event. In our example, findings are reported March 1, 2027. Astra's 30-day window, which runs from the date vulnerabilities are reported, closes March 31. The fixes are ready April 6, six days too late. A later final report does not restart that clock.

Contract end dates can cut a window short too. Cobalt's Standard tier gives six months, but retest requests close at the earlier of that period or 10 days before the contract ends. If an existing Cobalt contract ended April 10, 2027, the last day to request a retest would be no later than March 31, again before the fixes are ready.

The book-by date. Use the calculator below with your own numbers. Here is the example worked by hand:

That is 81 days from booking to proof. The 10, 14 and 36 are made-up inputs. The 21 matches the low end of the 3 to 6 weeks Software Secured states for scheduling. A provider's advertised start time is not a promised report date, so ask for your dates in writing.

Does the timing differ for SOC 2 Type 1 and Type 2?

The two reports cover time differently, so ask your auditor how the test should line up with yours.

A Type 2 report includes the auditor's opinion on whether controls worked throughout a set period. A Type 1 report covers the same subject but does not include that opinion or the detailed test results. That is from the criteria document itself. It follows that if your control promises a pentest on a schedule, a Type 2 auditor can look for evidence that it happened. Whether the test must fall inside the period is question 4 on your list. The criteria don't answer it.

Does SOC 2 require a pentest every year?

Not in the criteria text. It says management varies the scope and frequency of evaluations with risk. Yearly testing becomes your rule when your own control or a customer contract says "annual." Check both.

Is a vulnerability scan or an AI pentest enough for SOC 2?

It depends on what the person asking needs, so go by the work and the evidence. The product name won't tell you.

A vulnerability scan is software checking your systems for known weaknesses. The criteria mention scans in two places, including CC7.1. A penetration test goes further: someone, or something, tries to use the weaknesses to get in and shows what could be reached. AI-led tests differ a lot in how much people are involved.

Ask three things about any offer:

1. What is tested? (Which apps, APIs and roles.)
2. How is it tested? (People, software, or both, and in what mix.)
3. Who stands behind the findings and the report?

Then send the provider this: "Can you show how this test and its report cover the work our auditor or customer asked for, including our user roles and tenant separation?"

If your auditor or customer requires testing by people, an AI-only offer does not meet that condition. If they don't, an AI-led test can be a fair, cheaper choice. Either way, get their answer in writing first. For the full comparison, see penetration testing vs vulnerability scanning.

What should the report and fix evidence include?

Agree the contents before testing starts. You want enough detail to see what was tested, repeat each finding, fix it, and show what happened next.

A short checklist to hold a sample report against:

• Scope and what was left out.
• Testing dates and methods.
• Limits the testers worked under.
• Each finding with evidence and a severity you can understand.
• Clear guidance on how to fix it.
• Retest status for each finding, and anything still open.

This is our buying checklist. It is not an AICPA template. OWASP's Web Security Testing Guide publishes a suggested report structure if you want a second reference. Our page on what a penetration testing report should contain goes deeper.

Do all findings have to be fixed before the audit?

Not always. How an open finding affects your report depends on the control and the risk involved, and that is your auditor's judgment. Write down your response to each finding and ask the auditor early how open ones will be treated. Marking something "accepted risk" in a tracker does not settle the question by itself.

Keep the trail connected. For example (made up): finding F-03, cross-tenant data export, ticket SEC-27, fix ready April 6, retest pending, owner engineering. One line like that for each finding is easy to hand over.

The one-page SOC 2 pentest evidence brief

Fill this in once and send the same copy to every provider. It asks them all the same question, so their answers can be compared.

1. Who asked and why. Auditor, customer or internal owner, by role. Paste the exact request or control wording. Mark each condition as must-have, nice-to-have or assumed.

2. Audit context. Type 1 date or Type 2 period. The testing frequency your own controls state. Any separate customer rule.

3. What you already have. Past provider, test dates, systems covered, open findings, retest status, what has changed since, and any limit on sharing the report. Note the gap, if there is one.

4. Systems and access. App, APIs and versions, environment, user roles, tenant setup, key workflows, rough size, and what you can provide (test accounts, documentation). List what is excluded. Do not include passwords, keys or customer data.

5. Testing needed. What behavior must be tested. Whether the request calls for testing by people, allows automation, or requires an independent tester. Keep an assumption marked as an assumption until its owner confirms it.

6. What you need back. Full report, summary letter or both. Scope, dates, methods, findings with evidence, fix guidance and retest record.

7. Dates. Test window, first findings, final report, fixes ready, last day to request a retest, retest done, evidence due. Ask the provider what starts each window.

8. Price and terms. Exact offer, currency, price per test, target, role or package, minimum commitment, when payment is due, required extras, included retests, cost of an extension, renewal terms and an itemized total. An unknown fee is not zero.

9. Open questions. For each one: who can answer, the exact question, and what each answer would change.

1. Who asked and why. Auditor, customer or internal owner, by role. Paste the exact request or control wording. Mark each condition as must-have, nice-to-have or assumed.

2. Audit context. Type 1 date or Type 2 period. The testing frequency your own controls state. Any separate customer rule.

3. What you already have. Past provider, test dates, systems covered, open findings, retest status, what has changed since, and any limit on sharing the report. Note the gap, if there is one.

4. Systems and access. App, APIs and versions, environment, user roles, tenant setup, key workflows, rough size, and what you can provide (test accounts, documentation). List what is excluded. Do not include passwords, keys or customer data.

5. Testing needed. What behavior must be tested. Whether the request calls for testing by people, allows automation, or requires an independent tester. Keep an assumption marked as an assumption until its owner confirms it.

6. What you need back. Full report, summary letter or both. Scope, dates, methods, findings with evidence, fix guidance and retest record.

7. Dates. Test window, first findings, final report, fixes ready, last day to request a retest, retest done, evidence due. Ask the provider what starts each window.

8. Price and terms. Exact offer, currency, price per test, target, role or package, minimum commitment, when payment is due, required extras, included retests, cost of an extension, renewal terms and an itemized total. An unknown fee is not zero.

9. Open questions. For each one: who can answer, the exact question, and what each answer would change.

This brief is a buying aid. It does not authorize testing, and it does not guarantee that anyone will accept a report.

This brief is a buying aid. It does not authorize testing, and it does not guarantee that anyone will accept a report.

How we checked this

We read the AICPA criteria document and each provider's own pricing, service and help pages on October 9, 2026. Every offer detail above is provider-published. We have not bought these services, tested their quality, or seen any auditor accept or reject their reports. The example company is made up, and the totals and dates are our own arithmetic on published terms.

The PenTest Index compares specific offers against stated buying requirements and shows its sources and check dates. Payment plays no part in which offers appear or in what order. See how we research offers and how we make money. To compare more providers, see penetration testing companies, independently compared.

Sources