Skip to content

Compliance

SOC 2
Penetration Testing

Component tests from $4,200, free retest. See all pricing →

Get a fixed quote

Reply in one business day

Senior certified testers, manual-first185+ years combined experienceOnboarding within 24 hoursFree retest includedOur methodology

When you need it

When you need SOC 2 penetration testing

The situations that bring teams to this engagement, and where it fits alongside the rest of your program.

  • Your first SOC 2 Type I is scheduled and the auditor’s evidence request list includes an independent penetration test.
  • You are inside a Type II observation window and the last test predates it, so the auditor will have nothing dated in the period.
  • An enterprise prospect asked for your SOC 2 report and a recent penetration test in the same security review.
  • Vanta, Drata, or another compliance platform is showing the penetration testing control as unmet.
  • The product changed materially since the last test: a new application, a major release, or a cloud migration.

The requirement

Does SOC 2 require a penetration test?

Not in so many words. SOC 2 is a set of Trust Services Criteria, not a checklist, and no criterion says “perform a penetration test.” In practice, nearly every audit firm expects one as evidence that the Security criteria are met and operating, and enterprise customers reading your report expect to see it referenced. A SOC 2 report without recent penetration testing evidence invites questions from both.

The test also does something an audit cannot: an auditor confirms that a control exists and was followed; a penetration test confirms that the control stops an attacker. That is why the same report serves the audit and the customer security review. Our guide to SOC 2 penetration testing requirements covers the criteria in depth, and if buyers also ask about ISO 27001, our comparison of ISO 27001 vs SOC 2 shows where one test serves both.

Control mapping

Which SOC 2 controls a penetration test evidences

Findings are mapped to the Trust Services Criteria your auditor examines. These are the criteria the test speaks to most directly.

What it covers

CC4.1
Ongoing and separate evaluations of whether controls are present and functioning
CC6.1
Logical access security software, infrastructure, and architectures over protected information assets
CC6.6
Security measures against threats from sources outside the system boundaries
CC6.8
Prevention and detection of unauthorized or malicious software
CC7.1
Detection and monitoring procedures to identify new vulnerabilities
CC7.2
Monitoring of system components for anomalies indicative of malicious acts
A1.2
Environmental protections, backup, and recovery infrastructure for availability commitments

What we test

CC4.1
The engagement itself is the separate evaluation; the report documents method, scope, and results
CC6.1
Authentication, authorization, and session handling across the in-scope applications and infrastructure
CC6.6
External penetration testing of the perimeter and internet-facing applications
CC6.8
Attempts to introduce and execute unauthorized code, and the controls that stop them
CC7.1
The vulnerabilities themselves, and evidence of the process that finds and remediates them
CC7.2
Whether the testing activity was logged and detected by your monitoring
A1.2
Resilience and recovery controls on in-scope infrastructure, where Availability is in your report

What we assess

What your SOC 2 test covers

We test the systems in your SOC 2 boundary against the Trust Services Criteria, so your report shows controls that hold up under real attack, not just on paper.

Security (Common Criteria)

The core controls every SOC 2 covers: how you protect systems and data from unauthorized access.

We test for

  • Access control and authentication
  • Network and perimeter security
  • Vulnerability and patch management
  • Change management controls

Availability

Whether systems meet the uptime and resilience commitments you make to customers.

We test for

  • Redundancy and failover
  • Backup and recovery
  • Capacity and monitoring
  • Incident response

Confidentiality

How confidential data is protected in transit, at rest, and in use.

We test for

  • Encryption in transit and at rest
  • Data classification and handling
  • Access restriction
  • Secure disposal

Processing Integrity & Privacy

Whether processing is complete and accurate, and personal data is handled properly.

We test for

  • Input and processing validation
  • Data accuracy controls
  • Privacy notice alignment
  • Consent and retention

Timing

Type I vs Type II: when to test

Type I: design at a point in time

Test before the audit date. The report, the remediation, and the retest all become part of the evidence the auditor reviews on the day. Allow four to six weeks from scoping to a clean retest.

Type II: operation over a window

Test inside the observation window, ideally in its first half, so findings are fixed and retested before the window closes. The retest is what turns a list of findings into evidence that the control operates. Repeat annually inside each new window.

SaaS scope

The typical SOC 2 scope for a SaaS product

Most SOC 2 penetration tests we run are for software companies whose auditor or enterprise prospect asked for one. The scope below covers what those auditors expect to see tested, and our SaaS penetration testing page covers multi-tenant products in more depth.

The product, with every role

A web application penetration test run gray box with an account for each role, usually an administrator and an ordinary member per tenant, so authorization between roles and between tenants is tested by hand. This is the test auditors mean when they ask for “the pentest.”

The APIs behind it

The API surface your product and your customers’ integrations call, tested for broken object-level authorization, token handling, and data exposure. Included in scope when the API is part of the system description.

The perimeter and the cloud

An external test of the internet-facing edge, and a cloud configuration review of the AWS, Azure, or GCP account that hosts the product, for CC6.6 and CC6.1.

What you receive

One report your auditor accepts, a customer-shareable attestation letter, and a free retest, at a fixed price agreed before testing. See every published penetration testing price in one place.

Auditor expectations

What auditors expect in scope

  • The systems inside your SOC 2 boundary, as described in your system description: the product, its APIs, and the cloud infrastructure that hosts it.
  • An independent tester with documented qualifications. Our report states tester qualifications, experience, and independence, which is what a third-party penetration test has to show.
  • A methodology the auditor recognizes, which for us is PTES and the OWASP testing guides.
  • Findings rated by severity, with evidence of remediation and a retest, not just an initial list.
  • A letter of attestation confirming the testing took place, its scope, and its outcome, which we provide on request.
  • Evidence that uploads cleanly into Vanta, Drata, or your GRC platform, which is how we format the deliverable.

Between tests

SOC 2 vulnerability management between tests

A Type II report covers months, not a day. The penetration test is one dated event in that window; CC7.1 asks how you find new vulnerabilities the rest of the time.

What CC7.1 asks for

Detection and monitoring procedures that identify configuration changes introducing new vulnerabilities, and susceptibility to newly discovered ones. Auditors look for a defined cadence, evidence it ran, and tickets showing what was fixed.

How scanning covers it

Validated vulnerability scanning, quarterly or monthly, from $1,500 per scan for up to 250 devices. An analyst removes false positives, so the evidence shows real findings closed, not raw scanner output.

How the test fits

The annual penetration test proves the controls hold against an attacker. The scans prove you keep watching between tests. Together they answer CC7.1 and the enterprise questionnaire that asks both questions.

Methodology

How we test

Full methodology →

Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.

These are the phases your compliance test runs through.

  1. 01

    Scope the boundary

    The systems your framework actually covers, and nothing you would pay to test twice.

  2. 02

    Test

    The component penetration tests run to PTES and OWASP standards by senior testers.

  3. 03

    Map to controls

    Every finding tied to the requirement or control it evidences.

  4. 04

    Report for the auditor

    Evidence formatted the way your assessor, examiner, or QSA expects to read it.

  5. 05

    Fix & retest

    A free retest so the audit shows closed findings, not open ones.

How it works

How your engagement runs

From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.

  1. 01

    Scope & align

    We scope your SOC 2 boundary and align testing to the Trust Criteria.

  2. 02

    Test criteria

    Testing mapped to the Security and Availability Trust Criteria.

  3. 03

    Auditor report

    Findings mapped to your controls, ready for Vanta, Drata, or your GRC.

  4. 04

    Fix & retest

    Fix the findings, then a free retest before your examination.

Proof

Proof in the field

Every engagement is confidential, so the work below is anonymized to sector and engagement type.

All case studies →

Free

Retest on every penetration test

185+

Years combined experience

14

Senior in-house specialists

24h

Onboarding after signing

HR & Payroll SaaS

Web Application Penetration Test

High risk

Critical: a file-inclusion flaw that let an attacker read sensitive files from the server through the application itself. High: stored cross-site scripting capable of session theft, insecure direct object references, and an authorization bypass that let an administrator create or delete organization owners.

Outcome. Delivered a remediation plan sequenced by real business impact, critical and high findings first, with a complimentary retest to verify every fix.

28

Findings

1

Critical

5

High

Read the case study

Fintech · Payments

Web Application Penetration Test

High risk

Critical: a remote code execution flaw in the application’s web framework that could have given an attacker full control of the server. We escalated it to the development team while the test was still running.

Outcome. The critical RCE was reported and remediated during the engagement via an emergency framework upgrade, which also closed the server-side request forgery, and the remaining findings were retested to confirmation.

1

Critical (RCE)

Mid-test

Critical remediated

2

High

Read the case study

FAQ

Frequently asked questions

What teams most often ask before SOC 2 testing.

Still have questions? 
01Does SOC 2 require a penetration test?

Most auditors do not mandate one outright, but nearly every serious examination expects a penetration test as evidence for the Security and Availability criteria, and enterprise customers frequently ask for it directly. We run the test and give you a report your auditor recognizes.

02When should we run the test relative to our audit?

Ideally inside your audit window and early enough to remediate any findings before the examination closes. We build the timeline around your audit dates so it does not become a last-minute scramble.

03Do you work with Vanta, Drata, or Secureframe?

Yes. Each platform has a penetration testing control that stays red until a report is attached. We deliver the report, the executive summary, and the attestation letter as separate files so they upload cleanly into Vanta, Drata, Secureframe, Sprinto, or whichever GRC platform your auditor reads from, and the findings name the criteria they evidence. Our guide to SOC 2 penetration testing providers explains how the platforms’ partner directories work.

04Is a vulnerability scan enough for SOC 2?

Usually not on its own. Scans are good evidence for CC7.1, that new vulnerabilities are identified on a schedule, but they only report known weaknesses and cannot show whether an attacker could get past your access controls. Most auditors and enterprise customers expect a penetration test as well, with scans covering the months between tests. Our comparison of penetration testing vs vulnerability scanning sets out what each proves.

05What is compliance penetration testing, and is a SOC 2 pentest different from a normal one?

Compliance penetration testing is an ordinary penetration test scoped to an audit boundary and reported in the auditor’s language. A SOC 2 pentest is the same technical work as any web application or external test; what changes is the scope (the systems in your system description), the mapping (findings tied to CC6.1, CC6.6, CC7.1 and the rest), and the paperwork (an attestation letter and retest evidence). Nothing is lighter about it, which is why the same report also satisfies enterprise customers and cyber insurers.

06What must the report and attestation letter contain for the auditor?

The report needs the scope stated in the same terms as your system description, the dates, the methodology, the tester qualifications, every finding rated by severity with evidence, and the retest result for each one. The attestation letter is a one-page summary of the same facts, signed, with no technical detail, so you can share it with customers without exposing the findings. Both are written so an auditor can file them without asking follow-up questions.

07How far ahead of the audit window should we test?

Start scoping six to eight weeks before the date you need the evidence. Onboarding begins within 24 hours of a signed proposal, testing typically runs about a week, the report follows within days, and the free retest needs your engineers to have fixed the findings first. For a Type II, aim to test in the first half of the observation window so remediation and the retest land inside it.

08How much does a SOC 2 penetration test cost?

A SOC 2 penetration test is scoped to the systems in your audit boundary, usually a web application or external network test. Those start at $5,200 and $4,200 respectively, fixed before work begins, with a free retest. We confirm a fixed price in writing from your scope details, no sales call required. Starting prices for every service are on our pricing page.

09Type I or Type II: when should the penetration test happen?

For a Type I, which reports on control design at a point in time, test before the audit date so the report and any remediation are in the evidence set. For a Type II, which reports on operating effectiveness over an observation window of typically six to twelve months, test inside the window, early enough that findings are remediated and retested before it closes. Companies that hold SOC 2 year after year test annually and keep the cadence inside each new window.

10Which SOC 2 controls does a penetration test map to?

Primarily the Security criteria: CC4.1 (monitoring and evaluating controls), CC6.1 (logical access), CC6.6 (protection against external threats), CC6.8 (malicious software), CC7.1 (identifying vulnerabilities), and CC7.2 (detecting anomalies). Availability criteria such as A1.2 come into play when the test covers resilience of in-scope infrastructure. Every finding in our report names the criterion it evidences, so your auditor and your compliance platform can file it without translation.

11We are a SaaS startup with one product. What scope do we need?

Usually a web application penetration test covering the product and its APIs, plus an external test of the cloud perimeter, because those are the systems inside a SaaS company’s SOC 2 boundary. Internal network testing matters less when the company is fully cloud-based with no office network in scope. We confirm the boundary from your system description and quote a single fixed price.

Ready to test your defenses?

Talk to our team about what your SOC 2 compliance requires.

Prefer the full scoping questionnaire? 

Get a Fixed-Scope Quote

Tell us what you need tested. We reply within one business day.