Does SOC 2 Require Penetration Testing?

The gap between not required and expected as evidence is exactly where SOC 2 projects stall. Auditors have discretion over what counts as sufficient evidence, and a thin or missing test is one of the more common reasons a control gets flagged. Below is what the criteria actually ask for, how often to test, who is qualified to run it, and how EJN Labs delivers the test that feeds your report.

Where penetration testing sits in SOC 2

SOC 2 is an attestation, not a certification. A licensed CPA firm examines your controls against the Trust Services Criteria (2017, revised 2022) and reports an opinion. There is no pass mark and no badge issued by a scheme. That structure matters, because it means the auditor is looking for evidence that your stated controls operate as described, rather than ticking a fixed checklist of named tests.

Two criteria do the heavy lifting for offensive testing. CC7.1 covers detecting and monitoring for new vulnerabilities and anomalies. CC4.1 covers evaluating whether your controls are actually working. A penetration test is one of the clearest, most widely accepted ways to produce evidence against both. It is not written into the criteria as a mandatory step, but it is the mechanism auditors most commonly accept as proof.

What the criteria actually ask for, in plain English

Read past the framework language and CC7.1 and CC4.1 are asking a few concrete questions:

• Are you actively looking for new weaknesses? CC7.1 expects you to detect and monitor for vulnerabilities and anomalous activity across the systems in scope, not just run an annual scan and file it away.
• Can you show the controls work? CC4.1 expects you to evaluate your controls and confirm they are operating, which points towards independent testing that tries to defeat them rather than a self-assessment.
• Is the evidence credible? Auditors weigh the quality of your evidence. A structured penetration test from a competent, independent tester carries far more weight than an automated scan report with no manual validation.
• Do you act on what you find? Finding issues is only half of it. The criteria expect a documented response, so the remediation trail is part of the evidence.

None of this says run a penetration test in those exact words. All of it is far easier to satisfy when you have one.

How often should you test for SOC 2?

Test annually, aligned with your SOC 2 reporting period. A SOC 2 Type II report covers controls over a window of time, often six or twelve months, so a penetration test dated inside or close to that window gives the auditor current evidence rather than stale results.

Beyond the annual cadence, sensible triggers for an additional test include:

• A significant change to the application, infrastructure or cloud environment in scope.
• A new product, a major feature or a migration that changes your attack surface.
• A merger, an acquisition or the onboarding of a new system that inherits customer data.
• A security incident that suggests your controls need re-evaluating.

Testing once and never again tends to weaken the CC7.1 story, because the criterion is about ongoing detection rather than a single snapshot.

Who is allowed to run a SOC 2 penetration test?

Any competent, independent tester can run a SOC 2 penetration test, because the criteria do not name a scheme or a qualification. Auditors look for someone demonstrably skilled who is not marking their own homework, which is where recognised accreditation earns its keep.

CREST accreditation is not written into the Trust Services Criteria, but it is accepted evidence of tester competence and process quality, and CPA firms routinely accept a CREST-accredited provider’s report without further questions.

EJN Labs is a CREST-accredited provider and an independent third party, which covers both bars an auditor cares about. Our testers are UK-based, and every engagement is scoped and delivered so the resulting report reads as credible evidence for CC7.1 and CC4.1. To be precise about roles: we perform the penetration test and hand you the report, and your CPA firm attests to the overall SOC 2 controls. We feed the evidence, they sign the opinion.

What the test should cover

Scope should track whatever sits inside the boundary of your SOC 2 report, which for most SaaS and technology organisations means the customer-facing platform and the environment that supports it. A test that meaningfully supports CC7.1 usually covers:

• The web application and its APIs, including authentication, authorisation and access-control logic.
• The external network perimeter and internet-facing services.
• Cloud configuration for the hosting environment, where that forms part of your control set.
• Role-based and multi-tenant boundaries, so one customer cannot reach another customer’s data.

The point is not volume of findings. It is coverage that lets the auditor see the systems handling customer data were tested by someone competent and independent. If you are also pursuing ISO 27001, the same test can support Annex A control objectives, and our guide to ISO 27001 penetration testing explains how one engagement can feed both programmes.

What happens when findings appear

You prioritise, fix and verify them, and that response is what the auditor grades. Findings are expected, and an auditor would be more suspicious of a spotless report with no evidence of rigour than of a report that surfaces issues and shows them fixed.

We deliver a report that prioritises each issue by real-world risk, with clear reproduction steps and remediation guidance your engineers can act on. Once you have remediated, EJN Labs provides a free retest of the original findings, giving you a closed loop of detected, fixed and verified to show the auditor. That remediation trail is often the strongest single piece of evidence for CC4.1, because it demonstrates the control was evaluated and improved.

How EJN Labs delivers SOC 2 penetration testing

We keep it simple and audit-ready. Engagements are fixed-price with no day-counting surprises, scoped to your SOC 2 boundary, and scheduled to land inside your reporting period. You get a CREST-accredited test from UK-based testers, a report structured as evidence a CPA firm will accept for CC7.1 and CC4.1, and a free remediation retest to close findings out. For a fuller walkthrough of the approach, see how EJN Labs delivers SOC 2 penetration testing.

If you have a SOC 2 audit on the horizon and need the pen test that feeds it, get a fixed-price quote in 24 hours and we will scope it around your reporting period.

Frequently asked questions

Does SOC 2 legally require a penetration test?

No. SOC 2 is a voluntary AICPA attestation, not a law or a certification scheme, and the Trust Services Criteria do not name penetration testing as a mandatory control, so nothing in the framework legally compels you to commission a test before your audit.

In practice, though, a penetration test is the evidence auditors expect for CC7.1 and CC4.1, and most SOC 2 reports rely on one to show vulnerabilities are being found and managed.

Which Trust Services Criteria does a penetration test support?

Mainly CC7.1 and CC4.1. CC7.1 covers detecting and monitoring for new vulnerabilities and anomalies, while CC4.1 covers evaluating whether controls are operating effectively, and a structured penetration test produces credible evidence for both criteria at the same time, from one piece of work.

That dual coverage is why CPA firms look for a penetration test even though the criteria do not demand one by name.

How often do we need to test for SOC 2?

Annually, aligned with your SOC 2 reporting period, plus an extra test after any significant change to the systems in scope, such as a major release, a cloud migration or a security incident. That cadence keeps the evidence current for each reporting window.

Ongoing detection is the spirit of CC7.1, so a single one-off test tends to weaken the evidence over time.

Does the tester need to be CREST-accredited for SOC 2?

No, the Trust Services Criteria do not require CREST or any named qualification. What auditors want is a competent, independent tester, and CREST accreditation is widely accepted evidence of that competence, so a CREST-accredited provider’s report is typically accepted by CPA firms without extra scrutiny.

EJN Labs is CREST-accredited and independent, which is exactly the combination auditors are looking for.

Who signs off the SOC 2 report, EJN Labs or the auditor?

Your CPA firm signs the SOC 2 report and issues the attestation opinion. EJN Labs performs the penetration test and provides the report that feeds your evidence for CC7.1 and CC4.1. We supply the test and the CPA firm attests to the controls. The two roles are separate and both are needed.

Can one penetration test cover SOC 2 and ISO 27001?

Often, yes. If the scope overlaps, a single engagement can produce evidence for SOC 2 CC7.1 and CC4.1 and support ISO 27001 Annex A control objectives at the same time. We scope the test once to serve both programmes where that is sensible, which saves duplicated effort and cost.