Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC (2026)

The most common compliance question we get is some version of "how often does ISO 27001 require a penetration test?" It has no answer, because ISO/IEC 27001:2022 does not require one and sets no testing frequency anywhere.

That is not a technicality. It changes how you scope, how you budget, and what you should worry about in the audit room. Of the four frameworks buyers ask about, exactly one names penetration testing as a requirement across its general population: PCI DSS v4.0.1. One names it for a small top tier only: CMMC Level 3. The other two, ISO/IEC 27001:2022 and SOC 2, never name it as a requirement at all. In those two, a penetration test is a commonly accepted form of evidence that a control you selected is operating, and the binding frequency, where one exists, is one you wrote into your own policy, control description or customer contract.

Mandated, accepted as evidence, or self-imposed

Most confused conversations about compliance and penetration testing collapse three different things into the word "required". They carry different consequences when something goes wrong.

Mandated by requirement text. The framework names penetration testing and attaches an obligation. Failing to perform it is a direct finding against a specific clause. Only PCI DSS Requirement 11.4 and CMMC's Level 3 requirement CA.L3-3.12.1e sit here.

Accepted as evidence of a control you selected. The framework requires an outcome, and a test is one of several artefacts that can demonstrate it. Nothing forces you to choose a test over a scan, an internal audit or a code review. ISO 27001 and SOC 2 sit here.

Self-imposed. You wrote "annual penetration test" into your ISMS policy, your SOC 2 control description or a customer contract, and now an auditor holds you to it. This is where most buyers actually live, and it produces more exceptions than the other two combined, because the obligation is invisible until fieldwork starts.

The cross-framework comparison

PCI DSS v4.0.1: the only broad mandate

PCI DSS is the outlier. Requirement 11.4 in PCI DSS v4.0.1 names penetration testing in requirement text and requires that exploitable findings be corrected. The mandate binds entities validating against the full standard.

11.4.1 is the methodology requirement, and it has teeth. The methodology must be defined, documented and implemented, covering nine elements: industry-accepted approaches; the entire cardholder data environment perimeter and critical systems; testing from inside and outside; validation of segmentation and scope-reduction controls; application-layer testing covering at minimum the vulnerability classes in Requirement 6.2.4; network-layer testing of all network-function components and operating systems; review of threats and vulnerabilities experienced in the last 12 months; a documented approach to assessing and addressing risk from findings; and retention of results and remediation records for at least 12 months. The assessor examines documentation and interviews personnel, so a methodology on a shelf does not pass.

11.4.2 is internal and 11.4.3 is external. This gets reversed constantly in aggregated vendor summaries and is the single most likely accuracy failure on this topic. Both require testing at least every 12 months and after any significant infrastructure or application upgrade or change, and neither substitutes for the other.

Segmentation testing splits by entity type. Requirement 11.4.5 is the baseline for all entities including merchants: test all segmentation methods at least every 12 months and after any change to segmentation controls, a lower trigger than "significant change". Requirement 11.4.6 applies only to service providers and moves that clock to six months.

Multi-tenant providers owe two things, not one. Requirement 11.4.7 obliges a multi-tenant provider to support its customers' external testing, either by supplying evidence (redactable, but still sufficient) that testing covered the customer's subscribed infrastructure, or by granting prompt access so the customer can test. Separately, Appendix A1.1.4 requires the provider to confirm the effectiveness of logical separation between customer environments through penetration testing at least every six months, and its applicability note states this is in addition to the testing under 11.4.6. Both left their best-practice window on 31 March 2025, so in August 2026 they are fully in force.

The cadence is not the hard window vendors describe. Table 4 defines "every 12 months" as at least once every 365 days (366 in leap years) or the same date each year, and "every six months" as at least once every 180 to 184 days. But the timeframe section that follows makes an allowance most summaries omit: where an entity has a documented and implemented process to detect a missed activity, determine why it was missed, perform it as soon as possible and document all of that, a reasonable approach is allowable, and the entity is not automatically non-compliant for performing the activity late. A 13-month gap is not automatically a finding. Lateness bites where no such process exists, or where the slip was oversight or mismanagement. Build the detection-and-catch-up process into your vulnerability management procedure and you convert a scheduling risk into a documented one.

"Significant change" is yours to define. PCI DSS says what counts depends heavily on the configuration of a given environment, then supplies a six-item minimum list you must consider: new equipment in the CDE; replacements or major upgrades in the CDE; changes to account-data flow or storage; changes to the CDE boundary or assessment scope; changes to supporting infrastructure such as directory, time, logging and monitoring services; and changes to third parties supporting the CDE. You document your own determination process, and an assessor can diff your change log against your test dates.

Who may perform. A qualified internal resource or a qualified external third party, with organisational independence, and the standard states in 11.4.2, 11.4.3, 11.4.5 and 11.4.6 that the tester is "not required to be a QSA or ASV". ASV status governs the quarterly external vulnerability scans under 11.3.2, a different control. The 2017 Penetration Testing Guidance supplement sets the independence bar as separation from the management of the target systems, and lists OSCP, CEH, GIAC, CREST and CHECK only as examples PCI SSC does not validate or endorse, adding that qualification cannot be met by certifications alone. It predates v4, so its clause references point at the old Requirement 11.3.

Retest is mandatory and event-driven. Requirement 11.4.4 has two limbs: correct findings in line with your own risk assessment under 6.3.1, and repeat penetration testing to verify the corrections. A closed ticket does not satisfy the second limb, and neither does a rescan. There is no fixed remediation SLA for pentest findings, so urgency flows from your documented 6.3.1 risk ranking and a weak ranking process quietly undermines 11.4.4. The 12-month clock governs the primary test, but retests are unbounded in number, so scope them into the engagement rather than discovering them as a change order.

One more trap: Requirement 12.5.2, at six months for service providers under 12.5.2.1, is a documented scoping exercise rather than a test. It defines the perimeter the test must cover, and a test scope narrower than your confirmed PCI DSS scope is a direct finding.

ISO/IEC 27001:2022: no clause, no control title, no frequency

ISO/IEC 27001:2022 never uses the term "penetration test" in a clause title or an Annex A control title, and sets no testing frequency anywhere. That is the whole answer.

The controlling clause is 6.1.3, information security risk treatment. You determine all controls necessary to implement your chosen risk treatment options, and a note confirms you may design controls yourself or take them from any source. You then compare that set against Annex A to verify nothing necessary was omitted, with notes stating explicitly that Annex A is a list of possible controls and is not exhaustive. Finally you produce a Statement of Applicability listing the necessary controls, justification for each inclusion, implementation status, and justification for excluding any Annex A control.

Set that against Clause 1, which states that excluding any of the requirements in Clauses 4 to 10 is not acceptable when claiming conformity. Clauses 4 to 10 are non-negotiable; individual Annex A controls are excludable with justification. That asymmetry is why "Annex A is mandatory, so A.8.8 forces you to pentest" is the most consequential ISO error in circulation.

Where a test genuinely helps is as evidence for controls you marked applicable. A.8.8 Management of technical vulnerabilities is the one most often evidenced this way, and its title carries no frequency, so any quarterly or annual cadence attributed to it did not come from ISO. A.8.29 Security testing in development and acceptance is the only Annex A control title explicitly about security testing, and it is scoped to the development lifecycle and acceptance into production, which makes it event-driven rather than calendar-based. A.5.35 Independent review of information security is a governance assurance review of your approach to managing information security, not a technical attack simulation, and it is routinely mis-sold as proof that ISO demands an independent third-party pentest. A.8.34 Protection of information systems during audit testing is the hook for rules of engagement, testing windows and authorisation letters.

Where "annual" comes from. Not from ISO 27001. It comes from ISO/IEC 17021-1:2015, which governs certification bodies: a two-stage initial audit, surveillance audits in the first and second years following the certification decision, and recertification in the third year, with surveillance conducted at least once a calendar year except in recertification years. That is when the auditor visits, not how often you test.

No qualification requirement. No clause in the publicly readable portion of ISO/IEC 27001:2022 imposes tester qualification requirements, and no Annex A control title concerns pentester qualification. Internal staff are acceptable. The ISO discipline is competence for the task assigned under Clause 7.2, plus sufficient independence from the area reviewed where A.5.35 has been invoked.

No retest obligation either. ISO has no equivalent of PCI DSS 11.4.4, no remediation deadline and no severity SLA. What drives remediation is 6.1.3 e) and f): an unremediated finding must be consciously accepted by a named risk owner as residual risk. Auditors care far more about the closed loop from finding to risk register to treatment decision to owner acceptance than about the technical depth of the report. A stack of unremediated reports with no risk-register linkage is a more likely finding than the absence of a test. And if your own policy, risk treatment plan or a customer contract states a testing frequency, the auditor holds you to that frequency. Writing "annual penetration test" into your own policy is what creates the obligation.

SOC 2: one mention, in a non-binding point of focus

The phrase "penetration testing" appears exactly once in the entire 2017 Trust Services Criteria with revised points of focus, inside a point of focus under CC4.1 listing eight evaluation types management "may include". Searches for "annual", "annually", "quarterly", "semiannual" and "at least once" across the TSC return zero hits. SOC 2 has no penetration testing criterion, no pentest control number and no mandated frequency.

TSP Section 100 paragraph .07 is the controlling interpretive rule: use of the trust services criteria does not require an assessment of whether each point of focus is addressed. Paragraph .05 adds that some points of focus may not be suitable or relevant, and lets management customise or substitute them. Criteria are the benchmark; points of focus are illustrative.

CC4.1 requires the entity to select, develop and perform ongoing and/or separate evaluations to determine whether the components of internal control are present and functioning. A penetration test is a separate evaluation, but so are vulnerability scanning, internal audit, compliance assessment and control self-testing. The related points of focus say only that management varies scope and frequency by risk and that separate evaluations are performed periodically, and "periodically" is never defined numerically anywhere in the document.

CC7.1 is routinely mis-cited as the pentest clause. It is not. CC7.1 covers detection and monitoring procedures for configuration changes that introduce new vulnerabilities and for susceptibility to newly discovered ones. Its point of focus is labelled "Conducts Vulnerability Scans" and is scoped to infrastructure and software scanning on a periodic basis and after significant changes. Penetration testing appears nowhere in it. Three more criteria get conflated the same way: CC7.5 and A1.3 concern incident-recovery and availability testing, and CC8.1's system-change point of focus names unit, integration, regression, source-code, QA and automated testing, not penetration testing.

CC4.2 is the one that bites. It requires that internal control deficiencies be evaluated and communicated in a timely manner to those responsible for corrective action, including senior management and the board as appropriate, with management tracking whether deficiencies are remedied on a timely basis. Once you elect a penetration test as your CC4.1 evaluation, CC4.2 pulls its results into a tracked, communicated remediation loop. Commissioning a test and sitting on the report creates more audit exposure than not commissioning one. There is no rule that all criticals must be closed; untracked findings, not the existence of findings, are the audit problem.

The 2022 revision moved away from penetration testing, not toward it. The AICPA's own redline shows an earlier construction naming penetration testing among a short list of examples, replaced in 2022 by the permissive eight-item menu. Any claim that the 2022 update strengthened a pentest requirement is backwards.

The Type 2 trap. In a Type 1, a designed-and-implemented control can be evidenced by policy plus evidence it existed as of the as-of date. In a Type 2, a control written as "we perform an annual penetration test" must actually have been performed within, and evidenced across, the period. That cadence is your own commitment, not an AICPA requirement, but once it is in the control description, missing it is an exception. Worse, a once-a-year test gives the auditor a population of one, so a single missed or late test is a 100 percent exception rate on that control. Observation periods of 3 to 12 months are market practice, not standard; neither TSP 100 nor the description criteria prescribe any period length. The description criteria also contain zero occurrences of "penetration", so you are not required to publish your report, disclose findings or name your provider.

CMMC: nothing at Levels 1 and 2, one mandate at Level 3

"Penetration" appears exactly once in all of 32 CFR part 170, including Appendix A, at 170.14(c)(4)(xx), requirement CA.L3-3.12.1e: "Conduct penetration testing at least annually or when significant security changes are made to the system, leveraging automated scanning tools and ad hoc tests using subject matter experts." The annual cadence there is a DoD-assigned organisation-defined parameter; the underlying NIST SP 800-172 text leaves frequency to the organisation, and nothing requires a third-party team.

"Penetration" appears zero times in NIST SP 800-171 Rev 2, the entire Level 2 control set, so Level 2 imposes no penetration testing obligation on the contractor. It does impose other testing obligations, covered below. One nuance to know before someone greps the assessment guide at you: NIST SP 800-171A lists conducting penetration testing of key system components among typical assessor actions under its TEST method. That is an option available to the assessor, not a duty on the contractor.

The Level 2 controls mistaken for a mandate are RA.L2-3.11.2 (scan periodically and when new vulnerabilities are identified), CA.L2-3.12.1 (periodically assess controls for effectiveness) and CA.L2-3.12.3 (monitor controls on an ongoing basis). None names a method. Each is worth 5 points, and 32 CFR 170.21(a)(2)(ii) bars POA&M items worth more than 1 point (the sole carve-out being SC.L2-3.13.11 CUI encryption at 3 points, where encryption is employed but is not FIPS-validated), so all three must be scored MET on assessment day. For the full treatment of scoping, scoring and the Level 3 evidence objectives, see our companion post, does CMMC require penetration testing?

Myths worth correcting before you scope

1. "Every framework requires an annual pentest." Only PCI DSS requires one across its general population, and CMMC only at Level 3. ISO 27001 and SOC 2 require none and set no frequency at all. Where an annual cadence exists outside those two places, your organisation created it.

2. "Certification cadence equals testing cadence." ISO's "annual" comes from certification body surveillance audits, SOC 2's from the observation period you chose, CMMC's triennial cycles from the assessment provisions. None is a testing interval.

3. "You need a certified or accredited third-party tester." No framework here requires tester certification. PCI DSS is the only one requiring organisational independence, and that means separation from the management of the target systems, verified by assessor interview rather than by certificate.

4. "A vulnerability scan satisfies the requirement." For PCI DSS, explicitly not: guidance under 11.4.1 states a scan is not a penetration test, that a test is an active process usually involving exploitation, and that penetration testing is a highly manual process. For CMMC Level 3, the objectives require both automated tooling and expert-driven ad hoc testing.

5. "PCI DSS requires quarterly penetration testing." No. That is Requirement 11.3.2, quarterly external vulnerability scanning by an Approved Scanning Vendor. Testing under 11.4.2 and 11.4.3 is every 12 months.

6. "Internal penetration testing means testing only from inside the CDE." The applicability note to 11.4.1 defines it as testing from inside the CDE and into the CDE from trusted and untrusted internal networks, including corporate networks that are out of scope.

What to actually hand an auditor

PCI DSS. A documented methodology covering all nine elements of 11.4.1, plus personnel who can speak to it. The scope of work and the results for the most recent internal and external tests, as two separate artefacts; many entities produce only the report and get caught on the scope of work. A defensible account of the tester's reporting line or contractual separation, because independence is tested by interview. Findings prioritised against your documented 6.3.1 risk ranking rather than raw CVSS. A retest artefact proving corrections were verified. Segmentation testing covering all segmentation methods, at six months if you are a service provider, and for multi-tenant providers the 11.4.7 customer-support evidence plus separate six-monthly A1.1.4 results. Results and remediation records retained for at least 12 months, evidence of testing after significant changes that reconciles against change control, and a test scope no narrower than your confirmed 12.5.2 scope.

ISO 27001. The Statement of Applicability, the risk treatment plan with documented risk-owner approval and residual-risk acceptance, and documented information about the risk assessment and treatment processes. Note what is absent from the documented information the standard actually requires: a penetration test report. If A.8.8 is applicable, expect the auditor to want a vulnerability management process, information sources, exposure evaluation and records of measures taken, with a test report as one readily accepted artefact among several. If A.8.29 is applicable, expect a defined testing approach inside the development lifecycle and evidence it ran before acceptance. Above all, show the closed loop.

SOC 2. Whatever your own control language promises, which is why that sentence deserves an hour of thought before it is written. In practice: the signed engagement letter and scope definition with dates, proving the control exists, was authorised and fell inside the period; the report with methodology, scope, findings and severities; and remediation tracking with ticket IDs, open and close dates, risk-acceptance memos and evidence results reached management. If your control asserts an independent or qualified tester, the auditor verifies that assertion holds. For CC7.1, expect a request for scan evidence rather than pentest evidence.

CMMC. At Level 2, a written, dated, approved assessment cadence in the system security plan or a security assessment policy, scan configuration and output covering all in-scope components, remediation records tied back to findings, continuous monitoring outputs, complete asset categorisation, and the artefact name and hash inventory frozen before the assessment rather than assembled during it. At Level 3, the penetration test report becomes a named assessment object, and the objectives require separate evidence that automated scanning tools are identified, that expert-driven ad hoc tests are identified, and that testing ran at the defined frequency using both. DIBCAC may interview the testing team, so a report from a tester who cannot be produced for interview is weak evidence.

Where Stingrai fits

Stingrai is a CREST-accredited penetration testing service provider founded in 2021, with teams in Toronto and London, 18 published CVEs and a 5.0 out of 5.0 rating across 19 Clutch reviews. Our penetration testing supports your SOC 2, ISO 27001, PCI DSS and CMMC compliance programme by producing the artefacts the auditor asks for: a documented methodology, a defined scope of work as a distinct deliverable, findings mapped to the clauses you are evidencing, and remediation retesting written into the engagement rather than sold as an afterthought. For PCI DSS that means treating the nine elements of 11.4.1 as the specification and scoping 11.4.4 retesting up front; for ISO 27001 and SOC 2 it means output that drops into your risk register or control description without an analyst translating it first.

Snipe, our autonomous web application testing agent, hunts the complex authorization, IDOR and business logic flaws a scanner will never find, which is the kind of application-layer depth a PCI DSS 11.4.1 methodology is expected to reach, and our PTaaS platform keeps coverage live between formal cycles. Engagement options are on our pricing page, and our guide to scoping a penetration test covers the mechanics.

Frequently Asked Questions

Does ISO 27001 require a penetration test?

No. ISO/IEC 27001:2022 never names penetration testing in any clause or Annex A control title, and it sets no testing frequency anywhere in the standard. Controls flow from your own risk treatment under clause 6.1.3, and Annex A functions as a non-exhaustive cross-check rather than a mandatory list. A penetration test is a commonly accepted form of evidence that controls such as A.8.8 or A.8.29 are operating, if you marked them applicable in your Statement of Applicability.

How often does SOC 2 require a penetration test?

SOC 2 sets no frequency at all. The words "annual", "annually", "quarterly" and "at least once" appear zero times in the 2017 Trust Services Criteria with revised 2022 points of focus. Any cadence you are held to comes from the control description your organisation wrote, or from a customer contract. In a Type 2 examination, whatever cadence you promised must have actually been performed within the observation period.

Which PCI DSS requirement covers internal penetration testing and which covers external?

Requirement 11.4.2 is internal penetration testing and 11.4.3 is external penetration testing under PCI DSS v4.0.1. This is reversed in many vendor summaries. Both require testing at least every 12 months and after any significant infrastructure or application upgrade or change, and they are separate obligations that cannot substitute for one another.

Does CMMC require penetration testing?

Only at Level 3. The word "penetration" appears exactly once in all of 32 CFR part 170, in requirement CA.L3-3.12.1e at 170.14(c)(4)(xx), which requires testing at least annually or on significant security change using both automated scanning tools and ad hoc tests by subject matter experts. Levels 1 and 2 impose no penetration testing obligation on the contractor, and "penetration" appears zero times in NIST SP 800-171 Rev 2, which is the entire Level 2 control set.

Does my penetration tester need to be CREST, OSCP or QSA certified?

No framework in this comparison requires tester certification. PCI DSS states the tester is not required to be a QSA or ASV, and its supporting guidance lists certifications such as OSCP, CEH, GIAC, CREST and CHECK only as examples that PCI SSC does not validate or endorse. ISO 27001 and the SOC 2 Trust Services Criteria impose no qualification or independence bar on a pentester. PCI DSS is the only one of the four requiring organisational independence, meaning separation from the management of the target systems.

Is a 13-month gap between PCI DSS penetration tests automatically a finding?

No. PCI DSS defines "every 12 months" as at least once every 365 days, but the standard also allows a reasonable approach where the entity has a documented and implemented process to detect a missed activity, determine why it was missed, perform it as soon as possible and document all of that. In those circumstances the entity is not automatically non-compliant for performing the activity late. Lateness becomes a finding where no such process exists, or where the slip was caused by oversight or mismanagement.

Can a vulnerability scan replace a penetration test for compliance?

Not for PCI DSS or CMMC Level 3. PCI DSS guidance under 11.4.1 states that a vulnerability scan is not a penetration test, that a test is an active process usually involving exploitation, and that penetration testing is a highly manual process. CMMC Level 3's assessment objectives require evidence of both automated scanning tools and expert-driven ad hoc testing, so neither alone satisfies it. For ISO 27001 and SOC 2 a scan can be a legitimate alternative artefact, because neither framework prescribes a method.

What is the single most useful piece of pentest evidence to give an auditor?

For PCI DSS it is the retest artefact under 11.4.4, because a closed ticket does not prove corrections were verified. For ISO 27001 and SOC 2 it is the closed loop: the traceable path from a finding to the risk register or deficiency log, to a treatment decision, to a named owner accepting or remediating it. Auditors in those two frameworks care more about that loop than about the technical depth of the report, and untracked findings create more exposure than the findings themselves.

References

1. PCI Security Standards Council. Payment Card Industry Data Security Standard: Requirements and Testing Procedures, Version 4.0.1 (June 2024). https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf. Requirement 11.4 and its sub-requirements, Appendix A1.1.4, Requirement 12.5.2 and the Table 4 timeframe definitions.

2. PCI Security Standards Council. Information Supplement: Penetration Testing Guidance, Version 1.1 (September 2017). https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf. Tester independence and qualification guidance, written against the v3.x numbering.

3. ISO. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection: Information security management systems, Requirements. https://www.iso.org/standard/27001. Clause 6.1.3 risk treatment and the Annex A control reference.

4. ISO. ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection: Information security controls. https://www.iso.org/standard/75652.html. The source of the 93 Annex A control titles.

5. ISO. ISO/IEC 17021-1:2015, Conformity assessment: Requirements for bodies providing audit and certification of management systems. https://www.iso.org/standard/61651.html. Clause 9 sets the three-year certification cycle and annual surveillance audits, which is where ISO's "annual" actually originates.

6. AICPA. TSP Section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus, 2022). https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022. CC4.1, CC4.2, CC7.1 and the paragraph .07 interpretive rule on points of focus.

7. AICPA. DC Section 200, 2018 Description Criteria for a Description of a Service Organization's System in a SOC 2 Report (With Revised Implementation Guidance, 2022). https://www.aicpa-cima.com/resources/download/get-description-criteria-for-your-organizations-soc-2-r-report. The Type 1 versus Type 2 subject matter distinction.

8. Code of Federal Regulations. 32 CFR Part 170, Cybersecurity Maturity Model Certification (CMMC) Program. https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170. Sections 170.14, 170.15 to 170.19, 170.21, 170.22 and 170.24.

9. NIST. Special Publication 800-171 Revision 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf. The CMMC Level 2 control set, statically incorporated by 32 CFR 170.2.

10. NIST. Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171A.pdf. Assessment objectives for 3.12.1 and the TEST method description.

11. NIST. Special Publication 800-172, Enhanced Security Requirements for Protecting Controlled Unclassified Information. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-172.pdf. The source of CMMC Level 3 requirement 3.12.1e and its guidance on who may perform the testing.