SOC 2 Penetration Testing

Not by name. SOC 2 is an attestation against the AICPA Trust Services Criteria, and none of the criteria contains the words "penetration test", so strictly it is not a mandated line item the way Requirement 11.4 is for PCI DSS. In practice, though, a recent penetration test is the evidence auditors most commonly accept that your common-criteria controls, the ones covering risk assessment, monitoring and vulnerability management, actually operate rather than merely exist on paper, so most SOC 2 reports are backed by one. Two forces make it effectively necessary: the auditor wants evidence the controls work, and your enterprise customers very often ask for a recent pentest report as part of their own vendor due diligence before they will sign. So the honest answer is that SOC 2 does not require a pentest, but a credible SOC 2 almost always has one behind it, and scoping the test to the criteria your auditor is testing is what turns it from a generic security exercise into audit evidence.

A SOC 2 report can only be issued by a licensed, independent CPA firm working under the AICPA attestation standards, and that firm must stay independent of whoever designed and implemented the controls being attested. SecureRoot is not a CPA firm and does not issue the report: it is issued by one of our partner CPA firms, introduced to you during scoping, and you choose between them. What we do is everything on either side of the attestation, scoping the system, closing the gaps, running the penetration test the auditor expects as evidence, and supporting you through the partner firm's fieldwork, and because our testers are independent of whoever built your controls, the test itself meets the independence the attestation requires. Be cautious of anyone who implies a single firm can both build your controls and issue your SOC 2 report, or that a penetration test alone is a SOC 2 report; neither is how the attestation works, and an auditor will see through both.

Inside it. A SOC 2 Type 1 report describes how your controls are designed at a single point in time, while a Type 2 reports on how they operated across a period, commonly three to twelve months, and the evidence an auditor wants is a test that falls within that observation window rather than before it opens or after it closes. The practical consequence is timing: if you run the test too early, the auditor may treat it as stale by the time fieldwork happens; too late, and there is no room to fix and retest exploitable findings before the window ends. We schedule the test to land inside your window and, when you are already mid-period, plan the retest so the closure evidence also falls within it. For a first Type 2, we usually test early in the window so remediation and a clean retest are both captured as operating evidence; for a renewal, we time it to your established cycle. The scoping call is where we place it against your audit calendar.

Assume the report will be read by a CPA auditor who was not in the room and needs it to stand as evidence. That means it must state the scope that was agreed and when, the methodology and standard behind each surface tested, every finding with a proof of concept that shows the issue was reproduced rather than inferred, a severity that is justified, a remediation that names the component to change, and a retest recording what closed and what still stands. Crucially for SOC 2, the findings should be mapped to the Trust Services Criteria they bear on, so the auditor can see the test as evidence that specific controls operate rather than as a standalone security document they have to interpret. SecureRoot writes findings that way and keeps the retest inside the engagement, so the original report and the closure evidence come from the same team and carry the same methodology. If your auditor has a preferred format or specific criteria in focus, tell us on the scoping call and we will shape the report to it.

The system your SOC 2 report describes, not the whole company. A SOC 2 report is written about a defined system, the combination of infrastructure, software, people, data and procedures that delivers a particular service to your customers, so the penetration test is scoped to that boundary rather than to everything your organisation runs. In practice that is usually the customer-facing application, the APIs behind it, the cloud infrastructure it runs on and the administrative and authentication systems that support it, while unrelated internal tools outside the system boundary are typically out of scope. Getting the boundary right matters, because testing the wrong scope produces a report that does not line up with the system the auditor is attesting. On the scoping call we map the system boundary with you first, and where the boundary is still being decided for a first report, we help you draw one that is both defensible to the auditor and honest about what the service actually depends on, rather than one drawn narrowly to make testing cheaper.

Most SOC 2 engagements run one to three weeks of testing depending on the size of the system in scope, plus a retest window once fixes are in. The indicative range for the underlying web application, API, cloud or network tests is the band on our penetration-testing services, with the retest included; where a SOC 2 engagement lands depends on the size of the system boundary, the number of applications and APIs inside it, and whether cloud infrastructure testing is included, rather than on a rate card. Those are ranges, not quotes. One point specific to SOC 2 cost: the penetration test is one line in a larger readiness and attestation budget, and the partner CPA firm's fee for issuing the report is separate and theirs, not ours; we are clear on the scoping call about which costs are the testing and which are the attestation, so you are not surprised later. You receive a fixed price in writing for the testing after the call, and our SOC 2 and penetration-testing cost guides, linked below, set out the drivers.

Usually yes, if it is scoped for it from the start. A single penetration test, scoped to the right boundary and written to map findings to controls, is evidence for several things at once: the SOC 2 Trust Services Criteria, the ISO 27001 technical-vulnerability and secure-development controls, and the recent-pentest line that enterprise customers put in their vendor security questionnaires. Because the same team at SecureRoot runs those compliance programmes, we scope the test to the controls that are driving it so the report satisfies each rather than being re-interpreted or re-run for the next one. What a test cannot do is be stretched to cover a system it never looked at, so if your SOC 2 boundary and your ISO 27001 scope genuinely differ we will say where the test covers both and where an addition is needed, rather than imply one report answers everything. Tell us on the scoping call which frameworks and which customer questionnaires are in play, and we will design a single engagement that produces evidence for each.