SOC 2 penetration testing

Your auditor asked for evidence of penetration testing, and your enterprise prospect asked for the same thing in their security questionnaire. This engagement produces the document both of them will accept.

What SOC 2 actually requires

SOC 2 does not prescribe a penetration test in the way PCI DSS does. There is no clause that names one. What the Trust Services Criteria require is that you identify, assess and address vulnerabilities — CC7.1 in particular — and auditors have converged on an annual independent penetration test as the standard evidence that you do.

In practice that means two things must be true. The test has to be independent of the people who built the system, and it has to produce documentation that shows scope, methodology, findings, severity and remediation. A scanner export does not satisfy the second point, and auditors increasingly say so.

It also means the retest matters. An auditor seeing a report full of unresolved criticals will ask what you did about them. A reissued report showing each finding verified as fixed closes that conversation before it starts — which is why a free retest is included in every engagement rather than sold separately.

What you receive for the audit

  • Signed attestation letter stating scope, methodology, dates and outcome
  • Executive summary suitable for inclusion in your audit evidence pack
  • Full technical report with reproducible proof of concept per finding
  • CVSS v3.1 severity ratings and business-impact narrative
  • Documented remediation guidance your engineers can act on
  • Free retest within 90 days, with the report reissued as verified-fixed
  • Answers to your auditor's follow-up questions at no extra charge
  • Reusable evidence for customer security questionnaires and vendor reviews

Scope

What we typically test for a SOC 2 engagement

The production application

Your customer-facing application and its API, tested authenticated across every role and tenant — the surface your auditor and your customers care most about.

  • Web + API

Tenant isolation

Whether one customer can reach another customer's data. For a multi-tenant SaaS this is the finding that matters most, to auditors and to buyers alike.

  • Multi-tenancy

Cloud configuration

IAM privilege escalation paths, exposed storage and network segmentation in the environment that hosts the in-scope system.

  • AWS / GCP / Azure

External perimeter

Everything internet-facing in the defined boundary, including assets that are in scope but missing from your inventory.

  • Perimeter

FAQ

Questions about this service

Does SOC 2 actually require a penetration test?

Not by name. The Trust Services Criteria require vulnerability identification and remediation — CC7.1 most directly — and an annual independent penetration test has become the evidence auditors expect. Ask your auditor what they will accept before scoping; we are happy to join that call.

Type I or Type II — does it change the test?

The test itself is the same. What changes is timing. Type I is a point in time, so a recent report is sufficient. Type II covers a period, so your report needs to fall inside the observation window and remediation needs to be demonstrable within it.

How often do we need to repeat it?

Annually is the norm, plus after any significant architectural change. Some auditors and larger customers ask for more frequent testing on systems that change quickly.

Will you talk to our auditor directly?

Yes, at no extra cost. Answering methodology and scope questions from your auditor is part of the engagement, not a billable extra.

Can you do this before our audit window closes?

Usually. Tell us the date on the scoping call and we will tell you honestly whether it is achievable rather than agreeing and then missing it.

Next step

Get the report your auditor is asking for.

Tell us what you have built. You get a reply within one business day, an NDA, and a free 30-minute scoping call with the person who will do the testing.