Question 1

Does SOC 2 actually require a penetration test?

Accepted Answer

Not explicitly. The AICPA Trust Services Criteria do not mandate a pen test by name. In practice every reputable CPA firm expects one because it is the most common way to produce evidence for CC4.1 (ongoing evaluation of controls), CC7.1 (detection of new vulnerabilities introduced by configuration changes or new threats), and parts of CC7.2 (monitoring of system components). A documented annual pen test is one of the first artifacts the auditor will ask for during fieldwork.

Question 2

SOC 1 vs SOC 2 - what's the difference and which do I need?

Accepted Answer

SOC 1 reports on controls relevant to a customer's financial reporting (think payroll providers, billing systems that flow into a customer's general ledger). SOC 2 reports on controls relevant to one or more of the Trust Services Criteria - Security, Availability, Confidentiality, Processing Integrity, Privacy. If your buyer is a CFO worried about ICFR, SOC 1 is the right report. If your buyer is a security team worried about how you protect their data, SOC 2 is the right report. Most SaaS and connected-device companies need SOC 2; only a narrow set of financial-services-adjacent vendors need SOC 1.

Question 3

SOC 2 Type I vs Type II - which do I need?

Accepted Answer

Type I is a point-in-time report - 'these controls are designed appropriately as of this date.' Type II adds an observation period - usually 3 to 12 months - showing the controls operated effectively over time. Hospital InfoSec teams, large enterprise buyers, and most procurement reviews require Type II. Type I is sometimes used as a fast-track 'we are on the path' artifact while the Type II observation window runs, but on its own it doesn't unlock most enterprise deals.

Question 4

What's the typical scope of a SOC 2 pen test?

Accepted Answer

Scoped to the systems inside your SOC 2 system boundary - the production environment, customer-facing applications, the APIs and integrations they call, the cloud tenant they run in, and supporting infrastructure (identity providers, secrets stores, monitoring stack). Most engagements run a mix of: external network testing, web application testing on every in-scope app, API testing, cloud-configuration review (AWS/Azure/GCP IAM, network, storage), and sometimes internal network testing. The boundary - not the IT estate - is the right scoping unit.

Question 5

Does the pen tester have to be a third party?

Accepted Answer

Effectively yes. The AICPA framework doesn't explicitly require third-party testing, but auditors consistently flag internal-only testing under CC4.1 as insufficient evidence of an independent evaluation. The signed engagement letter, scope document, and attestation from an independent firm is what closes the criterion cleanly. Internal red-team work is valuable in addition - just not in place of - a third-party annual test.

Question 6

How often does the pen test have to happen?

Accepted Answer

At minimum annually, before the audit window closes. Many organizations test more frequently if they ship significant infrastructure or product changes mid-window - CC7.1 specifically calls out 'configuration changes or new threats' as triggers for re-evaluation. We typically run an annual baseline test for the audit plus targeted retests after any material architectural change.

Question 7

What does the auditor actually want to see in the pen test report?

Accepted Answer

Five things. (1) The test happened - executive summary, scope document, engagement dates. (2) It was independent - signed engagement letter and attestation from a named third party. (3) Findings were tracked and remediated - or have documented mitigations / formal risk acceptance with a named owner. (4) The scope covered the systems in the audit boundary - not a subset. (5) Retest evidence for high/critical findings closed before the audit. A vulnerability scanner export does not satisfy any of these.

Question 8

Type II timing - when should we run the pen test inside the observation window?

Accepted Answer

Early. SOC 2 Type II covers a 3-12 month observation period, so any critical finding that sits open through the audit window can become an exception in the report. We recommend running the pen test in the first third of the window (or before it starts), so engineering has runway to remediate, we have time to retest, and the auditor sees a closed loop instead of an open finding. A pen test run two weeks before audit close almost always produces audit exceptions.

Question 9

What's the difference between a SOC 2 pen test and a 'regular' pen test?

Accepted Answer

Methodology is the same - attack surface mapping, vulnerability identification, exploitation, post-exploitation, reporting. The differences are about purpose and documentation. A SOC 2 pen test is scoped to the audit boundary (not the IT estate), is performed by an independent third party with a documented engagement letter, produces a report formatted for CPA workpapers, includes evidence the findings were tracked and remediated, and is timed to fit inside the Type II observation window. The same testing techniques produce a non-SOC-2 pen test report when those wrappers are missing.

Question 10

Which Trust Services Criteria does the pen test produce evidence for?

Accepted Answer

Primarily CC4.1 (the COSO monitoring activities common criterion - ongoing evaluations to ascertain whether internal control is present and functioning), CC7.1 (vulnerability identification and management), and CC7.2 (system component monitoring for anomalies). Depending on scope it also produces evidence for CC6.6 (logical access controls over external attack surface), CC6.7 (transmission and movement of information), and CC8.1 (change management). The report's findings section maps each finding back to the criteria it touches.

Question 11

How does sub-service organization carve-out affect pen test scope?

Accepted Answer

Sub-service organizations (AWS, Azure, GCP, your IdP, payment processors) are typically carved out of your SOC 2 report - you rely on their own SOC reports for their infrastructure controls. The pen test scope follows the same boundary. We do not test AWS's data-plane infrastructure. We do test your AWS configuration - IAM policies, security groups, public assets, KMS usage, logging coverage - because those are your responsibility under the shared-responsibility model and fall inside your audit boundary. The scope document makes the carve-out explicit.

Question 12

Can the same pen test satisfy SOC 2, HIPAA, and HITRUST evidence requirements?

Accepted Answer

Yes - if it's scoped and reported correctly. The testing techniques overlap substantially. A single engagement can produce evidence for the SOC 2 Common Criteria, the HIPAA Security Rule technical safeguards (164.308(a)(1)(ii)(A), 164.308(a)(8)), and HITRUST CSF control families covering vulnerability management. We deliver a single report with framework-specific appendices crosswalking each finding so your auditor, your OCR-readiness file, and your HITRUST assessor are all reading from the same evidence.

Question 13

What's a bridge letter and why do we need one for SOC 2?

Accepted Answer

A bridge letter (or 'gap letter') is a short attestation that covers the period between your most recent SOC 2 report and the date a customer is reviewing it. Hospital InfoSec and enterprise procurement teams typically require one when your report is more than 90 days old. The pen test attestation feeds into the bridge letter - we provide a refreshed pen test attestation each quarter so your sales team can hand out a current package without going back to the auditor.

Question 14

How long does a SOC 2 pen test take and what does it cost?

Accepted Answer

Most engagements run 4-6 weeks end to end - one week scoping and threat modeling, two to three weeks active testing, one to two weeks remediation coordination and retest, one week report finalization and attestation letter. Pricing is fixed-fee: startup SaaS engagements (external + one app + APIs + one cloud tenant) land in the low five figures; growth-stage scope (multiple apps, multi-account cloud, internal network) runs mid five figures; multi-product or regulated-industry scope runs high five figures and up. Retest of highs and criticals is always included.

SOC 2 Penetration Testing - Auditor-Ready Scope, CPA-Ready Report, Free Retest.

Why SOC 2 pen tests fail to satisfy auditors

Wrong independence posture

Scope doesn't match the audit boundary

Type II timing trap

No remediation evidence trail

Scope of a SOC 2 pen test

External attack surface

Web applications & APIs

Cloud configuration review

Internal network (when scoped)

How the SOC 2 pen test engagement runs

1. Scoping aligned to the audit boundary

2. Threat modeling and test plan

3. Active testing

4. Remediation and retest

5. CPA-ready report and attestation letter

Reviewer-ready deliverables in one engagement

Fixed-fee SOC 2 pen test pricing

Startup SaaS

Growth SaaS

Multi-product / regulated

Standards this service maps to

Technical Guide to Information Security Testing

Cybersecurity Framework

Secure Product Development Lifecycle

Related services mapped to the same standards

Network Penetration Testing

Medical Device Penetration Testing

Device Vulnerability & Pen Testing

SOC 2 penetration testing FAQs

Backed by MedTech leaders.

SOC 2 Penetration Testing - scoped, fixed-fee, FDA-ready.