Do You Need a Penetration Test for SOC 2 or ISO 27001?

Neither SOC 2 nor ISO 27001 spells out a mandatory annual penetration test in its text — yet auditors and enterprise buyers routinely expect evidence of technical security testing. Here is what the standards actually require, how a pentest differs from a vulnerability scan, and what to hand your auditor.

Penetration test vs vulnerability scan: not the same thing

These two terms get used interchangeably, and conflating them causes real problems on audit and questionnaire responses. A vulnerability scan is an automated, largely hands-off process: a tool such as Nessus, Qualys, or an equivalent cloud scanner checks your systems against a database of known weaknesses — missing patches, outdated software versions, common misconfigurations — and produces a list ranked by severity. Scans are cheap, fast, and meant to run frequently, often weekly or continuously, because their value is in catching known issues quickly and at scale.

A penetration test is a manual, human-led exercise in which a skilled tester actively attempts to exploit weaknesses the way a real attacker would. Rather than just reporting that a vulnerability exists, a pentester chains issues together, tries to bypass controls, escalates privileges, and demonstrates what an attacker could actually reach and do. The deliverable is a narrative report with proof-of-concept findings, business-impact ratings, and prioritized remediation guidance — not just a raw severity list.

The practical distinction is breadth versus depth. A scan tells you what is known to be wrong across many systems; a pentest tells you what a motivated adversary could genuinely accomplish against a focused target. Mature programs use both: continuous scanning to keep the obvious closed, and periodic penetration testing to validate that the defenses hold up under real pressure. Neither replaces the other, and an auditor familiar with the difference will not accept a scan report relabeled as a pentest.

What ISO 27001 actually requires (it never says "annual pentest")

This is where honesty matters. The text of ISO/IEC 27001:2022 — the management-system clauses 4–10 and the 93 Annex A controls — does not contain a line that says "you must perform an annual penetration test." Anyone who tells you the standard mandates one is overstating it. What the standard does require is that you identify, evaluate, and treat your technical security risks, and several Annex A controls make technical testing the obvious, expected way to do that.

Two controls are most relevant. Annex A.8.8, Management of technical vulnerabilities, requires you to obtain information about technical vulnerabilities, evaluate your exposure, and take appropriate measures — which in practice means running vulnerability scans and acting on the results. Annex A.8.29, Security testing in development and acceptance, requires that security testing be defined and carried out as part of how you build and release systems, which is where application-level penetration testing typically lives. Because you justify the inclusion or exclusion of every Annex A control in your Statement of Applicability, you are expected to show how you satisfy these without a prescribed method.

So the truthful framing is this: ISO 27001 does not name a pentest, but a certification body auditing your ISMS will look for evidence that you find and fix technical vulnerabilities and test the security of what you build. For most organizations, a combination of regular scanning plus periodic penetration testing is the most credible, defensible way to demonstrate A.8.8 and A.8.29 are operating — and auditors see it constantly.

What SOC 2 expects through the Common Criteria

SOC 2 works the same way. The AICPA Trust Services Criteria do not include a criterion that says "obtain an annual penetration test." SOC 2 is principles-based: you design controls that meet the criteria for your business, and the CPA firm examines whether those controls are suitably designed (Type I) and operating effectively over a period (Type II). Penetration testing shows up not as a named requirement but as a common, sensible control that helps you satisfy several Common Criteria.

The most relevant are in the risk-assessment and monitoring families. CC4 (monitoring of controls) expects you to evaluate whether your controls are present and working, and CC7 (system operations) expects you to detect, evaluate, and respond to vulnerabilities and security events — CC7.1 in particular speaks to identifying configuration weaknesses and vulnerabilities. The risk-assessment criteria (CC3) expect you to identify and assess the threats your systems face. A penetration test, with its scanning counterpart, is a natural way to produce evidence for all of these.

Put plainly: a SOC 2 auditor will not fail you for the absence of a magic "pentest" line item, but they will expect to see how you identify and remediate technical vulnerabilities, and a recent penetration test is one of the cleanest pieces of evidence you can offer. Many organizations build the expectation into their own policies, which then becomes a control the auditor tests against.

Scope, types, and how often to test

"Penetration test" is not one thing, so scope it deliberately. An external network test targets your internet-facing systems — the perimeter an outside attacker sees first. An internal test assumes the attacker is already inside (a compromised laptop, a malicious insider) and probes how far they could move laterally. A web application test focuses on your actual product or portal, examining authentication, access controls, input handling, and business logic — usually the test that matters most for a SaaS company, because the application is the product. There are further specializations (cloud configuration reviews, API testing, mobile, social engineering), but external, internal, and web application are the common core.

Define scope before you buy: which IP ranges, which applications, which environments, and whether the test is black box (no prior knowledge), grey box (partial credentials), or white box (full access and source). Grey-box web application testing is a common, cost-effective choice for product companies because it lets the tester reach realistic depth without burning days on reconnaissance.

On frequency, the durable rule of thumb is at least annually and after any significant change — a major architecture shift, a new product surface, a migration, or a notable acquisition. Enterprise security questionnaires very often ask for a pentest within the last twelve months, which is why annual cadence has become the de facto market expectation even though no standard codifies the exact number. Treat any cost or timeline figure you are quoted as an illustrative estimate, not a fixed rule; actual scope, depth, and price vary widely by provider and target.

What to hand the auditor — and where documentation fits

When the auditor or a prospect asks about technical testing, the report alone is not the whole answer. What demonstrates a working control is the report plus the remediation evidence: the findings, the severity ratings, and crucially what you did about them — tickets opened, fixes deployed, dates, and ideally a retest or attestation that the high-severity issues were closed. A pentest report full of open critical findings with no remediation trail can hurt you more than help. Auditors are evaluating whether your vulnerability-management and monitoring controls actually function, and the remediation loop is the proof.

This is also where your documentation layer matters, because the testing only counts as a control if your policies say you do it and your records show you did. A vulnerability management procedure that defines how you scan, test, triage by severity, and remediate within set timeframes is the control the auditor maps the pentest evidence to. ComplianceDocs SOC 2 and ISO 27001 toolkits sit in exactly this layer: both the SOC 2 Complete Toolkit and the ISO 27001 Complete Toolkit include an editable Vulnerability Management Procedure, alongside the policies, risk register, control mapping, and audit evidence checklist auditors expect — an editable starting point you tailor to how your organization actually tests, then keep current.

Be clear about what that does and does not do. Templates give you the documented procedure and the evidence structure; they do not perform the penetration test, and they do not make you certified or attested. The test must be run by qualified people, the findings must be remediated, and the certification or report still comes only from an accredited body (ISO 27001) or a licensed CPA firm (SOC 2).

Choosing a provider — and why a pentest is evidence, not a certificate

A penetration test is only as good as the people running it, and quality varies enormously. Look for testers with recognized credentials — OSCP, GPEN, GWAPT, CREST, or equivalent — and ask for a redacted sample report so you can judge whether the findings are specific and actionable or boilerplate scanner output dressed up as manual work. Ask about methodology (frameworks such as the OWASP Testing Guide for web apps or PTES for network tests are good signs), what is and is not in scope, whether a remediation retest is included, and how findings are validated to minimize false positives. Cheap, fully automated "penetration tests" that are really just a scan with a cover page are common; if the deliverable has no exploitation narrative, you did not get a pentest.

Clarify the commercial and legal basics too: a signed authorization (rules of engagement), agreed testing windows, and clear communication paths if the tester finds something critical mid-engagement. Get written proposals for your specific scope rather than relying on a list price, and treat any figures as illustrative estimates that vary by provider and target.

Finally, keep the role of the test in perspective. A penetration test is evidence that supports your controls; it is not itself a certification or an attestation. Passing a pentest does not make you "SOC 2 compliant" or "ISO 27001 certified" — those statuses come only from an auditor examining your live program. The pentest is one strong artifact in a body of evidence that demonstrates your security controls work, which is exactly how auditors and serious customers read it.

Frequently asked questions

Does SOC 2 or ISO 27001 actually require a penetration test?

No standard names a mandatory annual penetration test in its text. ISO/IEC 27001:2022 requires you to manage technical vulnerabilities (Annex A.8.8) and perform security testing in development and acceptance (A.8.29), and SOC 2's Common Criteria around risk assessment and monitoring (such as CC3, CC4, and CC7) expect you to identify and respond to vulnerabilities. A penetration test is a common, credible way to satisfy those requirements, but it is the underlying control — finding and fixing technical weaknesses — that the standards actually demand. Most organizations test at least annually because auditors and customers expect that evidence, not because a clause prescribes it.

What is the difference between a penetration test and a vulnerability scan?

A vulnerability scan is an automated tool that checks systems against a database of known weaknesses and produces a ranked list, and it is meant to run frequently. A penetration test is a manual, human-led exercise where a skilled tester actively tries to exploit and chain weaknesses the way a real attacker would, then writes a narrative report with proof-of-concept findings and remediation guidance. Scans give you breadth and speed; pentests give you depth and validation of what an attacker could really achieve. Mature programs use both, and an auditor who knows the difference will not accept a scan relabeled as a pentest.

How often should we run a penetration test?

The widely accepted rule of thumb is at least once a year and again after any significant change — a major architecture shift, a new product surface, a large migration, or an acquisition. No standard fixes the exact interval, but enterprise security questionnaires very commonly ask for a pentest performed within the last twelve months, which has made annual cadence the de facto market expectation. Continuous or regular vulnerability scanning runs much more often in between to catch known issues quickly. Match your frequency to your risk, your change rate, and what your customers contractually expect.

What should we give the auditor from a penetration test?

Hand over the full report plus your remediation evidence, not just the report on its own. Auditors want to see the findings, their severity ratings, and what you did about them — tickets, fixes, dates, and ideally a retest or confirmation that high-severity issues were closed. A report with open critical findings and no remediation trail can actually weaken your position, because the control they are testing is whether your vulnerability-management process works. The remediation loop, mapped to your documented procedure, is what turns a pentest into audit evidence.

Will a SOC 2 or ISO 27001 toolkit pass our penetration test for us?

No. A toolkit gives you the documentation layer — for example, an editable vulnerability management procedure, supporting policies, a risk register, and an audit evidence checklist — that defines how you test and remediate and gives the auditor something to map the pentest evidence to. It does not perform the penetration test, fix the findings, or make you certified or attested. The test must be run by qualified people, the issues must be remediated, and ISO 27001 certification comes only from an accredited body while a SOC 2 report comes only from a licensed CPA firm examining your live controls.

Related guides: ISO/IEC 27001 · SOC 2

Toolkits that help

← All articles