Auditors do not accept or reject a penetration test based on whether a human or an AI agent ran it. They evaluate the report, not the tool. For SOC 2, ISO 27001, and PCI DSS, the question that decides acceptance is whether the test has a documented methodology, an independent and competent tester, defensible scope, and evidence quality an examiner can trace. An autonomous or AI-driven test that produces those artifacts is acceptable evidence. A raw tool export that skips the methodology narrative and the independence attribution usually is not, and that gap has nothing to do with how good the scan was.
This post is the Stingrai research team's canonical 2026 reference for how auditors treat AI and autonomous penetration tests across the three frameworks buyers ask about most. It leans on the actual control text: the AICPA Trust Services Criteria for SOC 2, ISO/IEC 27001:2022 Annex A for the ISO path, and PCI DSS v4.0.1 Requirement 11.4 for card data environments. Every framework rule below is attributed to its standard, not to any vendor's interpretation, so any claim can be audited against the source.
Framework requirement language is current as of July 2026: SOC 2 uses the 2017 Trust Services Criteria with revised 2022 points of focus, ISO 27001 uses the 2022 revision, and PCI DSS v4.0.1 is the only active version of the standard after v4.0 was retired on 31 December 2024, with the future-dated Requirement 11.4 items effective since 31 March 2025.
The direct answer
Yes, an auditor can accept an AI or autonomous penetration test as evidence for SOC 2, ISO 27001, and PCI DSS, but acceptance depends on the report, not the automation. None of the three frameworks names a specific tool, bans automation, or requires a human to press every key. What they require is a defensible methodology, a tester who is independent from the systems under test and competent to run them, coverage that matches the audited scope, and findings an examiner can evaluate. A tool-only export tends to fail on the methodology narrative and the independence attribution, which is why hybrid delivery (continuous autonomous testing validated and extended by human pentesters) is the cleanest fit.
That is the whole answer. The rest of this post explains what each auditor actually looks at and where a raw AI export falls short.
What an auditor actually evaluates
Across all three frameworks, an examiner is checking four things when they open a penetration test report. None of them is "was this run by a person."
1. Documented methodology. The report has to name a recognized approach and show it was followed. PCI DSS 4.0.1 Requirement 11.4.1 is explicit: the methodology must be documented and based on an industry-accepted approach such as NIST SP 800-115, the "Technical Guide to Information Security Testing and Assessment" (NIST, 2008), and must cover both the application and network layers plus the threats in Requirement 6. SOC 2 and ISO auditors expect the same discipline even though their standards do not spell out a named framework: a report that lists testing phases, techniques, and coverage reads as evidence; a bare vulnerability dump does not.
2. Tester independence. PCI DSS 4.0.1 requires the tester to be organizationally independent from the systems being tested. The tester does not have to be a third party, but they cannot be the person responsible for managing the environment under test. SOC 2's CC4.1 language similarly frames penetration testing as one of the "separate evaluations" that support monitoring, which carries an independence expectation. An autonomous agent inherits the independence of whoever operates and attests to it, so the report needs a named, independent party standing behind the result.
3. Scope coverage. The test must cover the environment the audit covers. For SOC 2 Type 2, the test also has to fall inside the observation period to count. For PCI DSS, Requirement 11.4 covers the entire card data environment perimeter and critical systems, and segmentation controls carry their own testing obligations. An autonomous tool that runs continuously is actually strong here, because it can demonstrate coverage across the whole period rather than a single point in time, but only if the scope is documented and justified.
4. Evidence quality. The report needs risk-rated findings, a clear severity model, remediation guidance, and, for critical and high findings, retest evidence that the fix worked. This is where tool-only exports most often fall down: they list findings but rarely include the human judgment that separates a real business-logic flaw from a noisy false positive, or the retest artifact an auditor wants to see.
Where a tool-only AI export falls short
A raw autonomous or AI scanner export is a strong input, not a finished audit artifact. The gaps are consistent across frameworks.
Methodology narrative. A scanner emits findings; it rarely emits the "here is the recognized methodology we followed and why" narrative that PCI DSS 11.4.1 demands and that SOC 2 and ISO auditors look for.
Independence attribution. A tool has no professional standing on its own. Someone independent and competent has to own the result and sign the report.
Scope justification. Auditors want to see that the scope was reasoned about (what was in, what was out, and why), not just whatever the tool happened to reach.
Business-logic and authorization depth. Generic AI scanners are strong on known-class bugs and weaker on the complex classes, IDOR, broken access control, and business-logic flaws, that auditors and attackers both care about most. Coverage of those classes is a quality signal.
Retest evidence. Auditors want proof that critical and high findings were fixed and re-verified, which is a workflow artifact, not a scan output.
None of these gaps is a reason to avoid autonomous testing. They are the reason a report needs a human methodology, a human owner, and a human-written narrative wrapped around the automation.
Per-framework: what the auditor actually accepts
Here is how the three frameworks treat the penetration testing evidence, and what a raw tool-only export gets you versus a human-led or hybrid report.
Framework | Where the pentest evidence lands | Frequency the standard drives | Methodology and independence | Tool-only export vs human-led / hybrid |
|---|---|---|---|---|
SOC 2 (AICPA Trust Services Criteria, 2017 with 2022 points of focus) | Penetration testing is standard evidence for CC4.1 (monitoring / separate evaluations); vulnerability scanning maps to CC7.1 | At least annually; for a Type 2 report the test must fall inside the observation period | No named methodology required, but auditors expect a recognized approach and an independent, competent tester | Raw export rarely satisfies CC4.1 alone; a report with methodology, scope-to-system mapping, and retest evidence does |
ISO/IEC 27001:2022 | Annex A 8.8 (technical vulnerability management) and A.8.29 (security testing in development and acceptance), supported by Clause 9.1 | At least annually, aligned to the surveillance audit cycle, plus after significant change | Standard never says "penetration test," but periodic documented testing by internal staff or a qualified third party is the expected evidence | Tool-only output can leave a Stage 2 audit uncomfortable; a documented, methodology-backed report is what closes A.8.8 and A.8.29 |
PCI DSS v4.0.1 | Requirement 11.4 (11.4.1 methodology, 11.4.2 internal, 11.4.3 external, plus segmentation testing) | At least every 12 months and after any significant change | Documented, industry-accepted methodology (such as NIST SP 800-115) is mandatory; tester must be organizationally independent from the systems tested | Strictest of the three: a raw export without a documented methodology and independence attribution does not meet 11.4.1; a human-led or hybrid report does |
The pattern is consistent. No framework blocks automation. All three weigh methodology, independence, and evidence quality, and PCI DSS makes those weights explicit and mandatory. For a deeper walk through how these map to a purchasing decision, see our guide on compliance and regulation in pentesting services and the PCI DSS audit process best practices.
The auditor-ready report checklist
If a penetration test report, whether the work was autonomous, human-led, or hybrid, contains these elements, it will survive an auditor's review. Use this as a pre-submission gate.
Named methodology (for example NIST SP 800-115, OWASP, PTES) with the phases actually followed.
Scope statement that maps to the audited system boundary, with in-scope and out-of-scope reasoning.
Test window / dates, and for SOC 2 Type 2, confirmation the test fell inside the observation period.
Independence attribution: a named party independent from the systems under test who owns the result.
Tester competence: certifications or firm-level accreditation behind the report.
Risk-rated findings with a documented severity model (for example CVSS) and clear descriptions.
Coverage of complex classes: evidence that authorization, access-control, and business-logic issues were tested, not just known-class bugs.
Remediation guidance per finding.
Retest evidence for critical and high findings showing the fix was verified.
Statement of limitations describing what the test did and did not cover.
For a fuller treatment of what separates a report an auditor accepts from one they push back on, see how to evaluate a penetration test report and our AI pentesting evaluation guide.
Where continuous autonomous testing helps most
Continuous autonomous coverage is not a weaker substitute for a point-in-time test. For the evidence auditors want, it is often stronger, in specific ways.
Observation-period coverage. SOC 2 Type 2 rewards evidence spread across the audit window. Continuous testing produces exactly that, rather than a single dated snapshot.
After-significant-change testing. ISO 27001 and PCI DSS both expect testing after significant changes. Continuous coverage that runs on every material change satisfies that expectation as it happens, not at the next annual cycle.
Depth on the classes that matter. The value of automation is highest when it reaches the complex classes, IDOR, broken authorization, and business-logic flaws, that generic scanners miss and that carry the most audit and breach risk.
The catch is the same one that runs through this whole post: continuous coverage is evidence of testing, but the artifact an auditor accepts still needs the methodology, independence, and human-owned narrative around it.
How Stingrai fits
Stingrai pairs continuous autonomous coverage with human-led testing so the report is one an auditor evaluates on its merits. Our autonomous web application agent, Snipe, is purpose-built to hunt the complex, high-impact classes, IDOR, broken authorization, and business-logic flaws, that generic AI scanners miss. It runs black-box dynamic testing and white-box source review, can gate pull requests, and generates fix pull requests, so testing coverage is continuous and reaches the classes auditors and attackers care about most.
The human-led side is what turns that coverage into an audit artifact. Stingrai is a firm-level CREST-accredited penetration testing provider, which is an independence and competence signal auditors recognize. Senior pentesters validate and extend Snipe's findings, write the methodology narrative, justify the scope, and produce the retest evidence. The result supports your SOC 2, ISO 27001, and PCI DSS evidence: a report a qualified auditor evaluates on its merits.
Explore Stingrai's PTaaS platform, web application penetration testing, and red teaming to see how continuous autonomous coverage and human-led testing produce audit-ready evidence.
Frequently Asked Questions
Does an auditor accept an AI pentest report for SOC 2, ISO 27001 or PCI DSS?
Yes, an auditor can accept an AI or autonomous penetration test, but acceptance depends on the report, not the automation. None of the three frameworks names a tool or bans automation. Auditors evaluate documented methodology, tester independence, scope coverage, and evidence quality. A report that provides those, whether the work was autonomous, human-led, or hybrid, is acceptable; a raw tool export that omits the methodology narrative and independence attribution usually is not.
Is a human-led penetration test still required for compliance in 2026?
No framework mandates that a human runs the test, but all three effectively require a human to stand behind the report. PCI DSS 4.0.1 requires a documented, industry-accepted methodology and an organizationally independent tester. SOC 2 and ISO 27001 auditors expect a recognized methodology and a competent, independent party who owns the result. In practice that means human ownership of the methodology and the artifact, even when automation does much of the testing.
What does PCI DSS 4.0.1 require for penetration testing?
PCI DSS v4.0.1 Requirement 11.4 requires a documented methodology based on an industry-accepted approach such as NIST SP 800-115 (11.4.1), internal penetration testing at least every 12 months and after significant change (11.4.2), external testing on the same cadence (11.4.3), and segmentation testing where segmentation is used to reduce scope. The tester must be organizationally independent from the systems under test. See the PCI Security Standards Council for the source language.
What does SOC 2 require for penetration testing?
Penetration testing is not explicitly mandated by SOC 2, but auditors treat it as standard evidence for Trust Services Criterion CC4.1, which covers monitoring and separate evaluations. Vulnerability scanning maps to CC7.1. For a SOC 2 Type 2 report, the test must fall inside the audit observation period to count as valid evidence, and the report should map scope to the system description and include risk-rated findings and retest evidence. See the AICPA Trust Services Criteria.
What does ISO 27001:2022 require for penetration testing?
ISO/IEC 27001:2022 never uses the phrase "penetration test," but Annex A 8.8 (technical vulnerability management) and A.8.29 (security testing in development and acceptance), together with Clause 9.1, make periodic technical testing the evidence auditors expect. The standard accepts testing by internal staff or a qualified third party, performed at least annually and after significant change, aligned to the surveillance audit cycle.
Will an autonomous or continuous pentest satisfy the "after significant change" requirement?
It can, and this is one of the strongest cases for continuous coverage. ISO 27001 and PCI DSS both expect testing after significant changes to the environment. A continuous autonomous test that runs on material changes produces that evidence as changes happen, rather than waiting for the next annual cycle, provided the coverage and scope are documented.
Does the penetration tester have to be a third party?
Not necessarily. PCI DSS 4.0.1 requires the tester to be organizationally independent from the systems under test, not external to the company. An internal team can qualify if it is independent from managing the environment being tested. Many organizations still use a third party because independence is easier to demonstrate and firm-level accreditation such as CREST is a recognizable competence signal to auditors.
What is the difference between a vulnerability scan and a penetration test for audits?
A vulnerability scan is an automated check that identifies known vulnerabilities and misconfigurations; a penetration test attempts to exploit weaknesses and chains findings to demonstrate real impact. For SOC 2, scanning maps to CC7.1 while penetration testing maps to CC4.1, so they are complementary, not interchangeable. A scan export alone does not stand in for a penetration test report.
Where can I get the latest framework language for penetration testing requirements?
Use the primary sources: the PCI Security Standards Council document library for PCI DSS v4.0.1, the AICPA Trust Services Criteria for SOC 2, and ISO/IEC 27001:2022 for the ISO path. NIST SP 800-115 is the methodology reference PCI DSS cites by name.
References
AICPA and CIMA. 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus, 2022). 2022. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022. The control criteria SOC 2 examinations are performed against, including CC4.1 (monitoring) and CC7.1 (system operations).
PCI Security Standards Council. Just Published: PCI DSS v4.0.1. 2024. https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1. Announces PCI DSS v4.0.1 as a limited revision, confirms v4.0 retirement on 31 December 2024, and the 31 March 2025 effective date for future-dated requirements.
PCI Security Standards Council. Document Library. 2024. https://www.pcisecuritystandards.org/document_library/. Source for PCI DSS v4.0.1, including Requirement 11.4 penetration testing methodology, frequency, and independence language.
International Organization for Standardization. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements. 2022. https://www.iso.org/standard/27001. Annex A 8.8 (technical vulnerability management) and A.8.29 (security testing in development and acceptance).
National Institute of Standards and Technology. Special Publication 800-115: Technical Guide to Information Security Testing and Assessment. September 2008. https://csrc.nist.gov/pubs/sp/800/115/final. The industry-accepted methodology PCI DSS Requirement 11.4.1 cites by name; covers planning, discovery, attack, and reporting.
