ISO 27001 & SOC 2 Penetration Testing: What Auditors Want

Two frameworks, one recurring confusion. Search volume for "pentest ISO 27001" and "SOC 2 penetration testing requirements" keeps climbing, and almost every result answers half the question: it tells you whether a test is required, then stops before the part that actually decides your audit, which is whether the report you hand over is accepted.

This page is the consolidated answer. It covers the exact clause and criterion basis for each framework, what scope an auditor considers adequate, how frequently you have to test, what has to be inside the report, and the question buyers now ask most often: whether an automated or PTaaS report will be accepted at all.

Why 2026 is different from 2024

Three things changed, and none of them are a rewrite of either framework.

The ISO 27001:2013 transition window closed on 31 October 2025. Every valid certificate now sits on the 2022 edition, which means Annex A 8.29 is assessed on every certified organisation rather than only on early movers. Surveillance and recertification audits running through 2026 are the first full cycle where an inadequate answer on security testing is a routine finding rather than a novelty.

SOC 2 itself did not change. The operative document is still the 2017 Trust Services Criteria with revised points of focus published in 2022. What moved is auditor behaviour: evidence quality, scope traceability, and subservice organisation review are all under sharper scrutiny than they were two years ago. If an audit firm tells you there are "new 2026 SOC 2 requirements", ask them to cite the criterion number. They should be able to.

AI systems entered scope without a new control. Neither the AICPA nor ISO has issued an AI specific criterion for these frameworks, yet auditors increasingly fold model vendors, retrieval pipelines, and shadow AI tooling into existing risk assessment, access, and vendor management criteria. If an LLM feature sits inside your system boundary, expect it to be inside your test scope too.

Does ISO 27001 require penetration testing?

No clause in ISO/IEC 27001:2022 states that you must run a penetration test. The standard is outcome based: it defines what has to be achieved and leaves the method to your risk assessment. That flexibility is exactly why so many teams get caught out.

Four places in the standard do the work:

The Statement of Applicability is where this becomes binding. If 8.29 is marked applicable, and for any organisation that develops software or runs internet facing systems it almost always is, the auditor will ask to see the test report for your last major release. There is no third option between producing evidence and raising a nonconformity.

Full detail on control mapping lives in our ISO 27001 penetration testing requirement guide and on the ISO 27001 compliance service page.

Does SOC 2 require penetration testing?

Also no, and the textual basis is even thinner than most articles imply. Across the entire Trust Services Criteria, penetration testing appears inside a single point of focus under CC4.1, which asks the entity to select, develop, and perform ongoing or separate evaluations to determine whether components of internal control are present and functioning. The point of focus lists penetration testing alongside independent certifications and internal audit assessments as example evaluation types.

Points of focus are not criteria. You can, in principle, satisfy CC4.1 with an ISO certification, internal audit programme, or a mature bug bounty, and some auditors have accepted exactly that.

In practice, three things push almost every SaaS company toward a test:

• CC4.1 needs evidence that someone independently evaluated whether controls function. A report describing attempted control bypass is the cleanest form of that evidence.
• The CC7 series, particularly CC7.1 and CC7.2, requires detection of newly introduced and newly discovered vulnerabilities. Scanning maps here naturally.
• Type II is a period opinion. A single artifact dated outside the observation window does not describe the period under examination.

The distinction worth memorising: vulnerability scanning maps most naturally to CC7.1; penetration testing maps to CC4.1. Auditors routinely ask which one you did, and submitting a scan report labelled as a pentest is one of the most common reasons for a supplemental evidence request. Our SOC 2 penetration testing requirements breakdown and SOC 2 compliance page go deeper on the criteria themselves.

What type of penetration test satisfies each framework

Neither framework prescribes a test type. Both judge whether the scope you chose matches the boundary you claimed.

• ISO 27001 anchors scope to the ISMS boundary declared in your scope statement and SoA. Anything inside that boundary that could be attacked is fair game for the auditor's question.
• SOC 2 anchors scope to the system description in Section III of your report. The auditor will read your system description and your rules of engagement side by side.

That gives you a workable rule: test everything that stores, processes, or transmits in scope data, plus everything that controls access to it. For a typical B2B SaaS that means the external perimeter, the production web application in an authenticated grey box configuration, the APIs behind it, the cloud control plane, and role boundaries between tenants and privilege levels.

The scope adequacy test auditors actually run

Auditors are rarely security engineers. They do not evaluate technique. They evaluate traceability, using roughly five questions:

For scoping specifics by asset type, see our guides on web application penetration testing, API penetration testing scope and methodology, cloud penetration testing across AWS, Azure and GCP, and internal and external network testing.

How often do you have to test?

Annual is the accepted baseline for both. The frameworks diverge on the second trigger and on how timing is judged.

The Type II timing rule is the one that costs companies real money. A test completed two months before a twelve month observation window opens is a fine security exercise and a weak audit artifact. Read SOC 2 Type 1 vs Type 2 if you are still choosing.

The ISO 8.29 nuance matters differently. A full external test is not expected for every minor release. A risk based split is what auditors want documented: automated scanning and code review for minor changes, focused testing for significant releases, one full independent test annually. Write that cadence down with its risk rationale. "We test annually because everyone does" is a weaker answer than "we test annually as a baseline and after any change that materially alters the attack surface of in scope systems."

Will my auditor accept an automated or PTaaS penetration test report?

This is the question buyers now ask before they ask about price, and the honest answer has two halves.

Yes, most modern SOC 2 and ISO 27001 auditors accept PTaaS reports, provided the engagement was human led and the report meets the same scope and methodology bar as a traditional consultancy report. Delivery format is not what auditors assess. A findings platform with a live dashboard, continuous retest, and exportable point in time reports is, from an evidence standpoint, a better artifact than a static PDF, because it can demonstrate remediation across the observation period rather than on one day.

No, fully autonomous or scanner only output generally does not clear the bar, and this is where the market's terminology does buyers real harm. Two very different products share the PTaaS label:

The practical test to apply before you buy: ask the provider to show one finding with a working proof of exploit and a named tester attached. If they cannot, you are buying a scanner subscription with a PTaaS label, and your auditor will classify it as CC7.1 vulnerability scanning no matter what the cover page says.

Worth naming the uncomfortable version of this too. Because framework auditors assess whether testing occurred and whether findings were managed, rather than whether the tester was skilled, a weak report often does pass. Passing is not the same as being tested. The better question is not whether your auditor will accept the report, but whether that engagement would have found a serious vulnerability had one been sitting in the environment while it ran.

What a compliant penetration test report must contain

Most rejected reports are not rejected for weak testing. They are rejected for missing artifacts. Use this as an evidence ledger.

The retest is the artifact teams skip and auditors notice. Without it you have proof that vulnerabilities were found and no proof anything was done, which is a weaker position than not having tested at all in some auditors' eyes, because the finding is now documented.

One engagement, two frameworks

If you are pursuing both, scope once and map twice. No authority guarantees that a single test satisfies both frameworks automatically, but a report written with both mappings is one evidence pack instead of two audit preparation cycles.

Our SOC 2 vs ISO 27001 comparison covers the wider overlap between the two programmes, and the cost guide covers what scope does to price.

Frequently Asked Questions

Is penetration testing mandatory for ISO 27001? Not by name. Annex A 8.8 and A.8.29 make it the expected evidence, and ISO/IEC 27002:2022 implementation guidance references penetration testing directly. If those controls are applicable in your SoA and no test evidence exists, the auditor has grounds for a nonconformity.

Is penetration testing mandatory for SOC 2? No. Penetration testing appears once, in a point of focus under CC4.1, as one example of an evaluation activity. Most Type II auditors expect a test in practice and rarely accept scanner output alone for CC4.1.

Will a vulnerability scan satisfy ISO 27001 or SOC 2? Usually not on its own. Scanning maps to CC7.1 and supports A.8.8, but neither auditor community treats automated output as evidence of independent control evaluation under CC4.1 or as security testing under A.8.29.

Will my ISO 27001 auditor accept an automated penetration test report? If the engagement was human led and the report carries scope reconciliation, stated methodology, named testers, control mapping, and retest evidence, then yes, delivery platform is irrelevant. Fully autonomous scanner output with no human validation is normally classified as vulnerability scanning instead.

How often do we need to test? Annually as a baseline for both, plus after any significant change to in scope systems. For SOC 2 Type II, schedule the test inside the observation window.

Can one penetration test cover both frameworks? Yes, if the scope covers both the ISMS boundary and the system description, and findings are mapped to Annex A control numbers and Trust Services Criteria in the same report.

Does the tester have to be external? Neither framework mandates it. Independence is far easier to demonstrate with a third party, and internal testing invites questions about objectivity under CC4.1 and Clause 9.2.

What about AI features in our product? There is no AI specific criterion in either framework yet, but auditors are folding AI systems into existing risk, access, and vendor management criteria. If a model or retrieval pipeline sits inside your boundary, keep it inside your test scope.

Getting this scoped correctly

The failure mode in both frameworks is identical: the test was fine, the evidence pack was incomplete. Scope reconciliation, control mapping, and retest evidence are what convert a security exercise into an audit artifact.

SecurityWall runs human led testing scoped to your ISMS boundary or SOC 2 system description, with findings mapped to Annex A control numbers and Trust Services Criteria, and retest included so high and critical findings are provably closed before your auditor asks. If you want continuous coverage across a Type II observation period rather than a single dated report, SLASH extends the same testing into a PTaaS model.