Will an Autonomous Pentest Satisfy SOC 2, PCI, & ISO Auditors?

If you’re looking for a binary answer to the question in the title, we’re sorry. The compliance and framework spheres are as probabilistic and grey as the outcome of your next investor or shareholder meeting. 

But we can help you stay prepared, that’s for sure.

Firstly, a lot rides on the framework, and for perhaps the most detailed and comprehensive one, PCI DSS, the answer in late 2025 became an emphatic “no.” For SOC 2 and ISO 27001, autonomous testing can act as meaningful evidence, but most auditors in 2026 expect human-led, adversarial testing. 

Secondly, the market is under acceleration but compliance, as Jed Kafetz of Claranet and the CREST UK Council put it, “moves more slowly than technology, and assurance still depends on who is willing to stand behind the result.”

This article unpacks what each framework actually requires, what autonomous platforms can genuinely do, what auditors and QSAs are saying in writing, and how leading organizations are operationalizing a hybrid model that delivers both continuous validation and audit-grade evidence.

What Each Framework Actually Requires

PCI DSS, SOC 2, and ISO 27001 were all written before autonomous pentesting existed; surprisingly, each one seems to land in a different place on whether it qualifies.

SOC 2: The “Point of Focus” Trap

SOC 2 is not a framework that mandates penetration testing. It is stated as a focus area under Common Criteria 4.1 (CC4.1): “The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.”

Auditors at Linford & Company, one of the most-cited SOC 2 auditor firms in industry literature, have written extensively that the use of all points of focus is not required. They’ve published guidance explicitly noting that organizations may satisfy CC4.1 through ISO certifications, internal audit, vulnerability scans, or, as Blaze Infosec recounts from a real engagement, even a public bug bounty program. 

That said, every credible SOC 2 auditor commentary in 2025-2026, from Linford, Schellman, Bright Defense, Netragard, and Blaze, to Astra Security and MindFort, agrees that in practice, most Type II auditors expect penetration testing evidence, particularly for Type II examinations where control operating effectiveness must be demonstrated over a 6-to-12-month period.

Can autonomous pentesting satisfy SOC 2 CC4.1?

The honest answer is partially, in some circumstances, with caveats. The framework’s flexibility creates room, but auditor commentary is increasingly skeptical of automated-only evidence. 

Netragard’s 2026 SOC 2 guide is blunt: “Automated scanners and AI-only PTaaS are not sufficient; auditors look for human-driven, adversarial testing that can uncover business logic issues, chained exploits, and provide risk-based context, not just raw vulnerability lists.” Netragard’s analysis identifies three specific weaknesses that get autonomous reports rejected:

• Limited scope: scanners “cannot evaluate business logic flaws, chained attack scenarios, or complex authorization bypass techniques that manual testing uncovers,” and generate high rates of false positives and negatives.
• Missing context: scanner-heavy reports “lack the contextual analysis auditors need” and “force auditors to question whether your organization truly understands its security posture.”
• Auditor rejection of reports that don’t include evidence of manual exploitation.

The practical implication for CISOs: for a Type I report, or Type II company, an autonomous pentest combined with strong vulnerability management, change management, and remediation evidence may pass with a cooperative auditor. For enterprise SOC 2 Type II reports, especially those reviewed by enterprise customers, autonomous-only evidence is likely to draw questions if not outright pushback. 

Bright Defense, MindFort, and Astra Security all converge on the same recommendation: auditors want “manual exploitation evidence,” “control mapping to specific Trust Services Criteria,” “executive summaries for management, detailed technical findings with severity ratings, remediation recommendations, and evidence of retesting.”

PCI DSS 4.0 Requirement 11.4: The Definitive “No” From the PCI Council

If SOC 2 is permissive, PCI DSS puts up a straight NO to autonomous-only pentests. 

Jeff Hall, in his long-running PCI Guru blog under the title “Ask And You Shall Receive – Penetration Testing Edition,“ submitted a formal question to the PCI Security Standards Council asking whether automated penetration testing tools could satisfy Requirement 11.4. The Council’s written response leaves essentially no ambiguity:

“While automated tools can assist with repetitive tasks, penetration testing is fundamentally a manual, skilled process that requires human judgment to identify attack vectors and exploit vulnerabilities that automated tools may miss. The Guidance for Requirement 11.4.1 includes that ‘Penetration testing is a highly manual process.

While some automated tools may be used, the tester uses their knowledge of systems to gain access to an environment. Often, the tester will chain several types of exploits together with the goal of breaking through layers of defenses.’ Automated tools can support penetration testing, but do not replace the need for manual, skilled testing as specified in PCI DSS.”

The Council went further on methodology and tester qualifications:

“PCI DSS Requirement 11.4.1 requires that the penetration testing methodology is ‘defined, documented, and implemented by the entity.’ Simply pointing to a vendor’s website or claiming the tool follows a vendor’s methodology is insufficient… The process must include review and consideration of threats and vulnerabilities experienced [by] the entity in the last 12 months and should simulate real-world attack scenarios, neither of which automated tools alone can fully perform.”

And on tester qualification under 11.4.2:

“Being able to operate a tool is not the same as being a qualified penetration tester. The tester is expected to have the skills to interpret results, identify attack vectors, and follow up on findings — skills that go beyond simply running automated tools.”

Basically, for PCI DSS, if you show up with just an autonomous testing report—unbacked by expert pen testers, you might as well not show up at all. 

What does Requirement 11.4 ask for?

• 11.4.1: A documented, named methodology must align with industry-accepted approaches — explicitly NIST SP 800-115, OWASP Testing Guide, PTES, or OSSTMM. The methodology must cover both network and application layers, including the application vulnerabilities enumerated in Requirement 6.2.4 (injection flaws, broken authentication, IDOR, SSRF, business logic flaws, etc.), and must consider threats experienced in the prior 12 months.
• 11.4.2 and 11.4.3: External and internal penetration testing must be performed at least annually and after any significant infrastructure or application change, by a “qualified internal resource or qualified external third-party with organizational independence.”
• 11.4.4: Exploitable vulnerabilities must be corrected and retested, with documented attestation..
• 11.4.5: Segmentation controls must be tested at least every 12 months (every 6 months for service providers) and after any segmentation change.
• 11.4.6 / 11.4.7: Multi-tenant service providers must enable customer pentesting — a new v4.0 obligation with no v3.2.1 equivalent.

QSAs evaluating reports look explicitly for: 

• Documented methodology references
• In-scope CDE coverage matching the entity’s defined CDE
• Manual analysis of evidence (screenshots, request/response pairs, exploit chains rather than scanner output)
• Tester credentials
• CVSS-scored findings
• Retest attestation. 

CREST-certified providers are increasingly expected, according to multiple QSA practitioners writing in 2025-2026.

The implication is rather unambiguous: an autonomous-only pentest will not satisfy Requirement 11.4 in 2026. The PCI Council has effectively pre-empted the entire vendor narrative. Even AWS’s own Security Agent documentation does not claim PCI DSS Requirement 11.4 satisfaction. It positions the agent as a continuous testing capability that complements, rather than replaces, qualified human assessors.

ISO 27001:2022: Principle-Driven, Risk-Based, and Quietly the Most Forgiving

ISO/IEC 27001:2022 is the most flexible of the three frameworks. The standard itself contains no explicit penetration testing mandate. Instead, two Annex A controls do the work, supported by the implementation guidance in ISO/IEC 27002:2022

Annex A 8.8 (Management of technical vulnerabilities)

The ISO 27002:2022 implementation guidance explicitly acknowledges penetration testing as one mechanism for assessing technical exposure — but only as an example, not as a requirement. 

The control requires that “information about technical vulnerabilities of information systems in use shall be obtained in a timely manner, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures taken to address the associated risk.” 

As UK ISO 27001 consultant Alan Parker writes, “ISO 27001:2022 does not specify a penetration testing frequency — or mandate penetration testing at all… Control 8.8 requires a systematic approach to identifying and managing technical vulnerabilities. Penetration testing is one mechanism for fulfilling this, but not the only one.”

Annex A 8.29 (Security testing in development and acceptance) 

ISMS.online’s lead-auditor-authored guidance notes that A.8.29 requires testing throughout the development lifecycle, covering authentication, access control, cryptography, secure coding, and configuration hardening, with security testing requirements embedded in supplier contracts.

In the words of Stuart Barker at High Table and by Vorago Security, “ISO 27001 expects risk-based, structured security testing that is appropriate to the system and its exposure.” It does not prescribe tools, methodology, or whether testing is human or autonomous. But auditors universally expect three things:

1. A signed pentest report dated within 12 months that includes scope, methodology, tester qualifications, and severity-rated findings.
2. A remediation log demonstrating closure of high-risk findings with retesting evidence.
3. Findings mapped to specific Annex A controls (typically A.8.8, A.8.29, A.5.7, A.5.36, and A.8.20).

Can autonomous pentesting satisfy ISO 27001?

This is the framework where autonomous pentesting has the strongest case — and Jed Kafetz, who heads Claranet’s cybersecurity practice and sits on the CREST UK Council, makes that case carefully in his April 2026 blog saying; 

“ISO/IEC 27001 does not simply say ‘you must buy an annual penetration test.’ The standard is structured around risk management and appropriate controls, not a blanket pentest mandate.”

Kafetz’s overall position — which has become widely cited in compliance circles — is worth quoting in full:

“Agentic penetration testing is a force multiplier, not yet a universal substitute. In some organizations, it may be enough for parts of the program. In others it will be an excellent complement to human-led testing. In the most heavily regulated sectors, it will improve the program without replacing the need for an accredited human opinion.”

For a low-risk SaaS with strong patch management, robust vulnerability scanning, and limited internet-facing infrastructure, an autonomous pentest, along with documented evidence under A.8.8, may be defensible. 

For organizations with significant internet-facing systems handling sensitive data, certification bodies will still expect independent, qualified technical testing, and “qualified” in a CREST-aligned UK context, or under the NHS Data Security and Protection Toolkit (DSPT), still means a human assessor with appropriate accreditation.

What Auditors Actually Reject

Across all three frameworks, auditors and QSAs converge on a remarkably consistent list of triggers that’ll make them reject your pentest outputs. 

These come from QSA practitioner write-ups, Linford and Schellman blog content, ManticoreAI’s analysis of failed PCI assessments, and 2026 SOC 2 guidance from Netragard and Bright Defense:

• Reports that are visibly scanner output with a cover page
• No documented methodology. The Council explicitly told QSAs that “simply pointing to a vendor’s website or claiming the tool follows a vendor’s methodology is insufficient.”
• Scope-CDE mismatch: a CDE with 15 IP addresses tested only on 8 will trigger a finding.
• Missing manual exploitation evidence: screenshots, request/response pairs, command output, proof-of-concept artifacts, exploit-chain narratives.
• No retest attestation for Critical/High findings. PCI DSS v4.0 makes this explicit; SOC 2 Type II auditors expect it implicitly.
• No tester qualification documentation: certifications (OSCP, CREST CRT/CCT, GPEN, GXPN) or demonstrable hands-on equivalent experience.
• No human accountability: a name, a firm, a signature, a credentialed practitioner standing behind the report. This is the consistent thread Kafetz identifies — “assurance still depends on who is willing to stand behind the result.”
• Testing outside the audit window, particularly for SOC 2 Type II reports.
• Missing segmentation testing for PCI (a particularly common failure under v4.0’s more demanding 6-month service-provider cadence).
• Missing API coverage — explicitly named in v4.0 with no v3.2.1 equivalent.

Astra’s AI agents think, adapt, and pentest like real hackers, continuously. We bring in an army of AI agents trained on 5,000+ real pentests & 10M+ vulnerabilities that map your app, create threat models, & uncover contextual security flaws. Book your demo.

OWASP APTS: The Governance Framework Nobody Saw Coming

This is a deliberately non-methodological framework that targets governance, scope enforcement, safe autonomy, manipulation resistance, and accountability for autonomous pentesting platforms. 

APTS does not replace PTES, OWASP WSTG, or OSSTMM; it complements them by addressing the unique problems raised by AI agents that make their own decisions about targeting and exploitation.

The standard defines 173 tier-required requirements across 8 domains, plus 18 advisory practices in the appendix, structured in three conformance tiers:

• Tier 1 (Foundation): 72 requirements. The platform will not test outside scope, can be stopped immediately, and provides an audit trail.
• Tier 2 (Verified): 85 additional (157 cumulative). Full transparency, tamper-proof audit trails, and independently verifiable findings.
• Tier 3 (Comprehensive): 16 additional (173 cumulative). Highest assurance for critical infrastructure and L4 autonomous operations.

APTS also defines four autonomy levels; L1 Assisted, L2 Semi-Autonomous, L3 Supervised Autonomous, L4 Fully Autonomous and specific requirements such as:

• APTS-MR-023 that identifies the AI agent’s runtime as an untrusted component (because a vulnerable target application can manipulate the agent)
• APTS-TP-021/TP-022 requires disclosure of foundation models and re-attestation whenever the model materially changes, and mandates that all AI-generated findings include confidence scores and false-positive rates.

The strategic significance for CISOs is twofold: APTS gives procurement teams concrete evaluation criteria for autonomous pentesting platforms, and it gives auditors a vocabulary for evaluating autonomous pentest evidence that previously did not exist.

The Cost Conversation: Why This Debate Exists at All

The economic argument for autonomous pentesting is real and is the reason CISOs are pushing the question to their auditors in the first place. 

A traditional third-party manual penetration test from a reputable firm runs roughly $10,000 to $50,000+ per engagement. A few other numbers also exist in the market:

• Forbes’ analysis pins the typical range at $10,000-$50,000
• Blaze Infosec’s SOC 2 buyer’s guide cites $5,000-$25,000 for narrowly scoped SOC 2 tests at ~$200-$300/hour
• Academic researchers in the 2025 TermiAgent paper cite $10,000-$20,000 per engagement 
• Netragard cites $40,000 for a typical engagement)

Moreover, engagements take weeks, are typically performed once or twice a year, and as AWS itself notes, “most organizations limit manual penetration testing to their most critical applications due to time and cost constraints, which can leave the majority of their portfolio exposed between tests.”

By contrast:

• AWS Security Agent is priced at $50/task-hour, billed per second when active, with an average 24-hour evaluation costing approximately $1,200, as per Forbes. AWS publicly reports that preview customers are seeing 70-90% cost savings compared to manual approaches.
• NodeZero, Pentera, and RidgeBot are subscription-priced, enabling unlimited pentests. Public customer disclosures (Jerome’s Furniture, NCEC, a global water-solutions manufacturer running ~12,000 hosts) indicate dozens to hundreds of tests per year for what one previously paid for a single annual engagement.

When even the largest enterprises historically pentest only the top ~10% of their critical applications (per SiliconANGLE’s reporting on the AWS launch), and when 60% of organizations update web applications weekly or more often but nearly 75% test them monthly or less often (AWS preview data), the economic case for some form of autonomous augmentation is overwhelming.

But the cost argument is also why auditors have hardened their language. They have seen what happens when organizations use price compression to justify substituting a $1,200 autonomous run for a $30,000 human engagement and produce a report that doesn’t clear jack.

The Hybrid Model: What Leading Organizations Are Actually Doing

The model that emerges from credible 2025-2026 practitioner literature is not “autonomous replaces manual.” It is “continuous autonomous + annual human-led, with autonomous tooling embedded in the human engagement.”

Horizon3.ai’s “Pentesting Services for Compliance” (PSC), announced ahead of the PCI DSS v4.0 deadline in March 2024, is the most explicit articulation of this model. Per Horizon3 and Dark Reading’s coverage, PSC pairs OSCP-certified human pentesters with the NodeZero platform (what Horizon3 calls “human-machine teaming”). 

The humans conduct tests to PCI Council methodology (authenticated and unauthenticated, internal and external perspectives, segmentation checks), produce the audit-grade Pentesting Report and Fix Action Report, and the NodeZero platform provides scale, speed, contextual relevance, and the 1-click verify retest capability. 

Jerome’s Furniture, a Southern California furniture retailer with showrooms in San Diego, Los Angeles, Orange County, and the Inland Empire, publicly documented its move from periodic PCI vulnerability scanning to continuous autonomous pentesting. 

IT Director Adam Warren said that this hybrid approach lets his lean team “look at their environment from the perspective of an attacker, while also allowing them to continuously test their defenses, instead of waiting for costly annual or semi-annual external pentests.” 

North Carolina’s Electric Cooperatives (NCEC), the power supplier and trade association serving 26 not-for-profit cooperatives that collectively power 2.5 million North Carolinians, operates one of the most-cited continuous autonomous pentesting case studies for critical infrastructure. 

Brian Burnett, Director of Cybersecurity at NCEC, has publicly described using continuous penetration testing across IT and OT environments and for closing capability gaps at smaller cooperatives that cannot afford their own security teams. 

The case study explicitly maps autonomous pentesting to proactive defense, scalability across decentralized infrastructure, and ongoing risk management for critical energy infrastructure.

Other vendor programs explicitly built around the hybrid model include:

• Astra Pentest combines automated scanning with manual exploitation, marketing audit-ready reports, and control mapping for SOC 2, ISO 27001, and PCI. Astra’s 2026 SOC 2 guidance specifically recommends pairing autonomous and manual approaches for Type II audits.
• Cobalt and BreachLock: Pentest-as-a-Service models that wrap human testers with tooling and continuous engagement portals.
• Edgescan: continuous vulnerability intelligence platform with human-validated findings.

The pattern is consistent: autonomous testing for breadth, frequency, and continuous validation; human-led testing for depth, business logic, audit accountability, and the signed report.

Expert Commentary: What the Practitioners Are Saying

In Jed Kafetz’s Claranet blog “Autonomous Penetration Testing Agents, AWS Security Agent, and the Compliance Question,”  he observes:

“This is why the quality gap between human-led penetration testing and automated testing will continue to narrow. At some point, for some classes of testing, automated systems will likely surpass the average human tester. Are we fully there today? I would not say that with confidence. But the direction is clear. Agents do not sleep, do not get bored, can run continuously, and can revisit your applications every time your code changes. That persistence matters.”

On healthcare and regulated industries specifically, NHS DSPT guidance recommends pentesting at least annually, but more specific service requirements like the NHS MESH API onboarding require a penetration test by a third-party CHECK/CREST-accredited organization before go-live. 

The PCI Council’s October 2025 position is consistent with this view. Linford’s lead-auditor commentary on SOC 2 is consistent with it. ISO 27001 lead auditors at ISMS.online, High Table, and Iseo Blue all converge on the same answer: the autonomous platform produces evidence, but the human assessor produces assurance.

It is worth noting where the commentary diverges from vendor marketing. 

AWS’s own customer testimonials, “AWS Security Agent surfaced findings that no other tool has uncovered… It gave us visibility into issues we typically would not see, even from human pentesting teams” (Bamboo Health) are credible customer statements but not auditor statements about audit acceptance. 

Readers should not conflate “found something useful” with “satisfies framework requirement.” AWS’s own GA documentation carefully avoids claiming Requirement 11.4 satisfaction..

A Decision Framework for CTOs and CISOs

Based on the above, the practical guidance for security decision-makers in 2026 looks like this:

If you must satisfy PCI DSS Requirement 11.4 and you handle, process, or transmit cardholder data, do not attempt to substitute autonomous testing for human-led, qualified, organizationally-independent testing. 

Use autonomous platforms continuously for internal vulnerability validation, segmentation checking, and remediation verification between annual qualified engagements, and integrate autonomous evidence into your CDE control monitoring. 

If you must satisfy SOC 2 CC4.1, you have more latitude. Autonomous testing can contribute to the evidence package, particularly for Type I reports or for low-risk environments. But for Type II reports, and especially those that will be reviewed by enterprise customers, pair autonomous validation with at least an annual human-led pentest that produces a signed, methodology-aligned report mapped to CC4.1, CC6.1, and CC7.1-CC7.4. 

If you must satisfy ISO 27001:2022 A.8.8 and A.8.29, the framework gives you the most flexibility. A defensible, risk-based program that combines continuous autonomous testing with periodic human-led testing for high-risk systems. For internet-facing systems handling sensitive data, plan for an annual human-led engagement regardless.

Across all three frameworks, demand the following from any autonomous platform you deploy:

• OWASP APTS conformance disclosure (Tier 1 minimum, Tier 2+ preferred).
• Confidence scores and false-positive rates on findings (APTS Section MR).
• Foundation-model disclosure and re-attestation on model changes (APTS-TP-021/022).
• Audit trails of all actions, scope-enforcement evidence, and kill-switch capability.
• Exportable findings with manual-style exploit narratives (not just CVE listings), CVSS scoring, and control-framework mapping.
• Integration paths with the human-led testing partner who will sign the final compliance report.

Book your Astra Autonomous Pentest demo now!

The 18-Month Outlook

Several developments will shape this question through 2027:

• PCI DSS guidance updates: the PCI Council has not yet issued an FAQ or updated information supplement on automated penetration testing, despite the October 2025 PCI Guru exchange, but pressure is mounting. An updated supplement is plausible in the v4.x cycle.
• OWASP APTS adoption: as the standard matures from v0.1.0, expect procurement teams, auditors, and regulators to reference it in compliance evaluations. Vendor APTS conformance will become a checkbox.
• AICPA updates to the Trust Services Criteria: the current TSC document was last revised in 2022. Future revisions may either tighten or clarify the CC4.1 point of focus around penetration testing in light of autonomous capabilities.
• The hyperscaler effect: AWS Security Agent’s GA at $50/task-hour, with Microsoft Azure SRE Agent already GA since March 10, 2026, and Google Cloud yet to ship a first-party equivalent, fundamentally changes the buy-vs-hire calculation for autonomous testing. Expect 2026-2027 to be the year that “pentesting is a cloud-native service” becomes a normalized assumption, even as the audit-grade human assessment remains separately purchased.
• The accountability chain: as AI-agent regulation matures, expect “who is responsible when the autonomous pentest misses a critical finding or causes operational impact?” to become a contractual and regulatory question, not just a technical one. This may slow some adoption — and accelerate the hybrid model, mandating human intervention

Final Thoughts

Will an autonomous pentest satisfy SOC 2, PCI DSS, and ISO 27001 auditors in 2026?

• PCI DSS Requirement 11.4: No, “do not replace the need for manual, skilled testing.” Use autonomous platforms continuously for internal validation, but the 11.4 report must be human-led.
• SOC 2 CC4.1: Sometimes, but not safely. The framework’s flexibility allows autonomous testing to contribute to CC4.1 evidence, but auditors in 2026 overwhelmingly expect at least annual human-led testing for Type II reports.
• ISO 27001 A.8.8 / A.8.29: Yes, with proper risk-based justification. The principle-driven nature of the standard makes a well-documented autonomous-plus-periodic-human program defensible for many organizations.

The strategic answer for CTOs and CISOs is not “autonomous or human” — it is “autonomous everywhere, continuously; human-led annually, for accountability, depth, and audit signature.” 

AWS Security Agent, XBOW, and the rest of the autonomous category have not replaced human pentesters but made human engagement smaller, more focused, more verifiable, and, paradoxically, more important. 

The human still signs the report. The auditor still asks who they are. And as Jed Kafetz puts it, “assurance still depends on who is willing to stand behind the result.“

For now, in 2026, that is still a person.

FAQs