AI pentesting has been making waves and rivals the power of human hackers in ways we weren’t expecting. But frequently, companies are looking for pentesting to achieve and support their compliance certifications. And the pressure to do it more often is real. According to Aikido Security's 2026 State of AI in Pentesting report, which surveyed 400 CISOs and senior engineering leaders, 79% are concerned about missing vulnerabilities introduced between scheduled tests.
In the past, auditors have rejected results from automated tools. But that’s not because a human was required to sit and do all the testing, but rather that those old tools weren’t doing anything close to proper pentests. An AI pentest running 250 orchestrated agents against your application closely matches how human pentesters perform their assessments. This means exploring the application, understanding how features work, finding ways to break them, and validating that the issue is actually exploitable before putting it in the report.
True AI pentests today are being regularly accepted by auditors. In this post, we’ll discuss misconceptions about AI pentesting and how it relates to compliance, and explain how and when you can use AI pentesting to meet your compliance requirements.
{{cta}}
What do you need for compliance pentesting, really?
When an auditor asks for a penetration test, they're asking for documentation that your application was tested against a defined set of attack vectors and testing methodologies, that findings were validated and recorded, and that you have a remediation plan for anything critical. Whether it was a human that sat in front of a terminal for two weeks or AI agents that spent a day on it isn’t really the question. It is also the case that infrastructure changed much more slowly in the past, with quarterly releases, so the thought of performing weekly penetration tests was kind of absurd. That is most definitely not the case now.
The most common frameworks that require or recommend pentesting are SOC 2, ISO 27001, HIPAA, and PCI DSS. For most of these, none of them explicitly require a human to have conducted the test. What they specify is coverage, methodology, and documentation. PCI DSS is less straightforward— its guidance defines penetration testing as 'essentially a manual endeavor' and states that automated tools alone don't satisfy the requirement (we'll look at what that means for AI pentesting later).
Let's look at SOC 2. The framework doesn't actually mandate pentesting at all. What it does require is that you demonstrate your controls are effective, particularly around logical access (CC6.1), change management (CC8.1), and risk mitigation (CC7.1 through CC7.4). Auditors have settled on pentesting as the most credible way to evidence those controls, because it shows that someone actually tried to break them. A pentest report that maps findings to these criteria, documents what was tested, and shows remediation of anything critical, is what satisfies the requirement. As it turns out, the framework says nothing about who or what conducted the test.
ISO 27001 follows a similar pattern, recommending pentesting as part of ongoing risk assessment.
HIPAA has historically treated pentesting as a best practice rather than a hard requirement, but that's changing. In December 2024, HHS proposed updates to the HIPAA Security Rule that would make annual penetration testing mandatory for all covered entities and business associates, with testing required to be performed by qualified personnel with appropriate cybersecurity knowledge. That rule is expected to be finalized by mid-2026. If you're in healthcare, check directly with your compliance team on current status.
All the frameworks require a structured report with an executive summary, a methodology section, validated findings with evidence and reproduction steps, severity ratings, and remediation guidance. The OWASP Web Application Security Testing Guide is the benchmark most testers follow for coverage (and it's a long list). Even a human team working with a week's budget can't realistically work through all of it in any depth. They have to triage and prioritize the most important things. Frequency and breadth are constraints that no longer limit our testing scope.
The assumption that compliance pentesting means human pentesting isn't written into most frameworks. It's been true by default because, until LLMs, no tech could come close to actually doing them. For teams in heavily regulated sectors with specific compliance requirements, it's worth having that conversation with your auditor directly. For most, however, the report won't raise any flags. AI pentesting covers the requirements.
Scroll to the end of the piece to learn more about how AI pentesting works with different frameworks in detail.
What auditors looks for
In short, auditors or standards are actually looking for the following in a penetration test:
- A documented, repeatable methodology, not ad-hoc poking
- Independence, and that the tester is not the same team that builds or runs the system
- Real testing of effectiveness, going beyond automated vulnerability scanning
- Evidence, like findings, severity, and proof
- Remediation and re-testing of findings
If your pentest meets these criteria, AI or human, there's a good chance your auditor will accept it.
Where AI pentesting already delivers for compliance
Audit trails
The audit trail from an AI pentest is extensive and detailed, often better than many human pentest reports. Every request sent, every payload tried, every action taken by every agent is logged. You can see exactly what was tested, how the test was conducted, and what was found. Most human pentest reports give you findings and a methodology section. They’re not giving you a complete trace of every step taken. If your auditor asks, "How do we know they tested X?", the report generated from an AI pentest can actually show the log for that exact thing.
Test Coverage
AI pentesting covers significant ground. For those asking, "How do we know it tried everything?" the concern applies equally to human pentesters. A manual pentest report that comes back with zero findings and no audit trail of what was tested is being taken entirely on faith. A kind of servitude to the ritual of the annual penetration test exists. You can't prove a human tried everything, anyway. With an AI pentest, you can enumerate detailed test coverage through the logs.
Agents can work through the full OWASP Top 10 in hours. They test authorization checks across every endpoint, not just a representative sample. They try every attack vector on every feature, not just the ones a human tester had time to reach before the engagement ended.
AIs are improving exponentially in their ability to reason and understand code. They’re finding new, context-dependent vulnerabilities that humans have missed for years. Skeptics assume that AIs can’t handle business logic vulnerabilities. This is no longer the case. In practice, agents read the codebase, understand the intended behavior, and find creative ways to break it. The phrase “If all you have is a hammer, every problem looks like a nail” is apt here. Even if a human tester is really good at finding XSRF vulnerabilities and earns a six-figure bug bounty, the truth of the matter is that AI testing brings a sack full of hammers to the job.
In Aikido Security's head-to-head benchmark across four non-trivial web applications, AI agents found twice as many broken access control vulnerabilities as senior human testers. They also uncovered an e-signature forgery in a payment application that the manual testers didn’t catch at all. The AIs admittedly had a huge advantage because they had access to the source code. An AI absorbs a full codebase almost instantly, while human testers usually work without it for logistical and NDA reasons. But white box, grey box, or black box testing is definitely elevated by the parallelism that agentic pentesting brings to the table.
The benchmark also found that human testers did better on probing for poor configuration hardening and identifying compliance hygiene checks. Since then, AI pentesting has continued to improve. Aikido’s AI pentesting, for example, regularly catches complex IDOR vulnerabilities, which involve authenticating as real users and following long workflows end-to-end.
Third-party integrations, particularly complex OAuth flows and SSO implementations, are harder for agents to navigate consistently. Aikido’s AI pentesting has put in the effort required to solve these issues, but don’t take it for granted that all AI pentesting products can do this.
Reports
The report format maps directly to what compliance teams need. SOC 2 and ISO 27001 get a full PDF with evidence, detailed remediation guidance, and reproduction steps for re-testing after remediations are applied. HIPAA requirements are covered.
Turnaround times for AI pentesting are on the order of hours (definitely less than a day), which is really helpful when you're on a certification timeline or responding to an audit request that includes in-scope assets that have not been tested previously.
What can AI pentesting not do for compliance?
While AI pentests are increasingly being accepted, the tech is still quite new, and some industries and their regulators are still figuring out their stance on the issue.
PCI DSS is more prescriptive than SOC 2 or ISO 27001 and explicitly requires penetration testing at least annually, with specific coverage of cardholder data environments. Its official guidance for pentesting, last updated in 2017, describes penetration testing as 'essentially a manual endeavor' and states that running automated tools alone does not satisfy the requirement. The spirit of the requirement has always been about active exploitation, validated evidence, and judgment applied to results. Human pentesters can use AI pentesting as a tool to handle a large chunk of the heavy lifting on the application side. That said, PCI DSS also requires network-layer and segmentation testing alongside application-layer testing, which AI pentesting won't cover anyway.
For some financial services regulators or government sector requirements, companies will need to check directly with their auditor in order to gauge their openness to seeing continuous monitoring and testing as not just equivalent to point-in-time testing, but significantly superior evidence of security controls and program rigor.
FedRAMP, which applies to cloud service providers selling to US federal agencies, requires assessments to be conducted by accredited third-party assessment organizations (3PAOs). Recent RFCs for FedRAMP 20x, however, indicate that the program is working on finding ways to modernize its approach to vetting SaaS solutions to protect critical infrastructure and government applications and services.
Physical security testing and social engineering are fully out of scope (phishing tests are required for FedRAMP). We’re a ways off from having AI pentesters walking around turning doorknobs to see if they are locked and sending phishing emails (probably for the best).
We’re more likely to see accredited firms leveraging AI pentesting in discrete places as tools instead of full replacements for their reconnaissance and pentesting. Today, AI pentests can be used in a partner model where an accredited firm reviews and co-signs the work and testing artifacts. That approach is worth exploring if you're operating in either of those markets.
Don’t auditors reject AI pentesting tools as scanners?
The most common objection isn't even about AI pentesting. The problem is automated scanners that masquerade as AI pentesting.
For years, less scrupulous organizations have tried to pass off basic vulnerability scanner output as a pentest report. Tools like Nessus or OpenVAS produce long lists of flagged issues with severity ratings that look credible on paper, but nothing has been validated, exploited, or contextualized. They conflate the concept of a possible vulnerability with a demonstrable attack path. Auditors have seen enough of these to be skeptical of anything that smells like a scan dressed up as a pentest. So you have to make sure your AI pentest is truly AI pentesting, rather than a scanner or DAST wearing AI lipstick.
A real AI pentest actually exploits and confirms vulnerabilities against a live target before surfacing them in a report. You can tell the difference in the report language and details. Validated findings come with proof-of-concept evidence and reproduction steps showing how the exploit was actually executed, whereas unvalidated scanner findings just describe a potential issue with a generic severity rating and include no proof that anything was actually tried. If a report comes back with hundreds of findings and none of them show exploitation evidence, you likely have a scanner on your hands, regardless of what it says on the tin.
This goes back to what we were saying about PCI DSS. The 2017 language describing pentesting as 'essentially a manual endeavor' was written specifically to address the issue of organizations submitting scanner output as a pentest report. The guidance was drawing a line against that practice, not anticipating a world where AI agents actively exploit and validate findings the way human testers do. While AI pentests don't all of cover PCI DSS pentesting requirements (like network-layer and segmentation testing), AI pentesting tools can help organizations perform application pentesting more efficiently, and we may see these regulations update their wording in the future to address the nuance. The industry tends to move faster than compliance frameworks.
Continuous compliance
Beyond the compliance checkbox, point-in-time or snapshot pentesting is a broken model for anything that ships code more regularly than once per year.
A yearly pentest tells you what your application looked like on the day or week the test ran. But your development team likely pushed new changes the very next day. Three months later, the compliance report is still valid on paper, but your attack surface has changed significantly. The 85% of CISOs and engineering leaders in our survey who say findings are outdated at least sometimes aren't wrong about their situation. The lag is palpable and high-risk.
Continuous pentesting changes your point-in-time assertion into a living record. Instead of telling an auditor "we ran a pentest against production assets in March," you can show them a security testing history that sits right alongside your deployment history. And not just in production, but also in the lower environments. Every change impacting your attack surface was tested, so issues were caught and fixed fore they reached production.
Banks and heavily-regulated industries are forced currently to slow down release cycles, specifically to get features and functionality pentested before being shipped. Continuous AI pentesting changes that, because testing runs in stride with your deployment cadence, checking only what changed, so releases don't have to wait for security reviews.
See what an audit-grade AI pentest looks like
Auditors are checking that a test happened, that it followed a defined testing methodology, that test findings were documented with evidence, and that critical issues were addressed. An AI pentest report satisfies all of those requirements. The frameworks that define what counts as a test report and compliance artifact don't specify who or what ran the test.
If you're working toward SOC 2 compliance, ISO 27001, HITRUST, or a similar certification and want to see what the report looks like before committing, you can request a sample report or run a feature scan against your application. Most teams find the AI pentest format isn't a surprise to their auditors at all.
At Aikido, we’ve seen really good outcomes with our customers using AI pentesting with compliance. While we promise to do a manual pentest if your AI pentest is rejected by an auditor, so far, we haven’t seen it happen. Talk to us today to unlock fast, compliant pentesting today.
Appendix: Industry Specifics
Finance Industry
PCI DSS
The requirement: PCI DSS is the most prescriptive framework here. It requires a documented penetration-testing methodology, internal and external penetration tests at least once a year and after significant changes, re-testing of anything you fix, and separate testing of the controls that segment the cardholder data environment (more often for service providers). The test has to be run by a qualified tester who is organizationally independent from the systems under test.
Can autonomous testing satisfy it? No. PCI’s own Penetration Testing Guidance draws a line between a penetration test and a vulnerability scan: a scan is automated, while a penetration test is a manual process of exploitation that relies on the skill of a qualified, independent tester. Automated tools may assist, but the guidance treats the manual work as the test itself. An autonomous penetration test will not be accepted as the PCI pentest.
Aikido’s agents do exploit business logic, BOLA and chained flaws, so they are worth running as continuous security testing alongside the required engagement, including after significant changes. That is a security benefit and a source of remediation evidence, not a PCI sign-off. Plan the qualified human pentest separately.
Verdict: Does not meet the requirement. The penetration test must be performed by a qualified human tester. Autonomous testing will not be accepted as the PCI pentest.
Reference: PCI DSS v4.0.1 Requirement 11.4 (11.4.1 to 11.4.6); PCI SSC Penetration Testing Guidance.
DORA
The requirement: DORA has two tiers of testing. The general tier is a digital operational resilience testing program that every financial entity must establish, and penetration testing is one of the methods it must use. The advanced tier requires Threat-Led Penetration Testing (TLPT) at least once every three years for significant financial entities, with strict rules about who may run it.
Can autonomous testing satisfy it? Yes for the general program, no for TLPT. The general program is method-flexible and its listed methods include penetration testing, so continuous autonomous testing fits it and goes beyond the periodic minimum. TLPT is different. It is modeled on the ECB’s TIBER-EU framework and requires external, qualified red-teamers and an external threat-intelligence provider, with significant credit institutions required to use external testers exclusively. That is, by design, a human red-team engagement.
Verdict: Yes for the general testing program. It will not meet the TLPT requirement, which mandates external human red-teamers. Use Aikido to run and evidence the general program. The TLPT is a separate engagement that must be performed by humans.
Reference: DORA (Regulation (EU) 2022/2554) Articles 24 and 25 (testing program), Articles 26 and 27 (TLPT).
FTC Safeguards Rule
The requirement: The FTC Safeguards Rule governs how financial institutions protect customer information. It requires regular testing of how well your safeguards work, and gives you two ways to do it: continuous monitoring, or, in its absence, an annual penetration test plus vulnerability assessments at least every six months. Testing is also required after major changes to operations.
Can autonomous testing satisfy it? Yes. Continuous monitoring is written in as a direct alternative to the annual penetration test, which is what continuous autonomous testing provides. For an institution that prefers the periodic route, one autonomous program supplies both the annual test and the six-month assessments. The rule sets no human or accreditation requirement for the tester.
Verdict: Yes. Continuous monitoring is an explicit substitute for the annual pentest.
Reference: FTC Safeguards Rule, 16 CFR 314.4(d) and 314.4(d)(2).
NYDFS Cybersecurity Regulation
The requirement: New York’s financial-services cybersecurity regulation applies to banks, insurers and other entities licensed in New York, and it is referenced beyond the state as a financial-sector baseline. Its penetration-testing section requires testing built around your risk assessment, structured as either continuous monitoring or an annual penetration test together with twice-yearly vulnerability assessments.
Can autonomous testing satisfy it? Yes. As with the FTC rule, the regulation treats continuous monitoring and the annual penetration test as alternatives. Continuous autonomous testing maps onto the continuous-monitoring path, and for entities that choose the periodic route it also produces the annual test and the twice-yearly assessments. The regulation sets no tester-accreditation requirement.
Verdict: Yes. Continuous monitoring satisfies the requirement on its own.
Reference: NYDFS Cybersecurity Regulation, 23 NYCRR 500.5 (Second Amendment, 2023).
Healthcare Industry
HIPAA
The requirement: HIPAA’s Security Rule does not explicitly name penetration testing. Its evaluation standard requires a periodic technical and non-technical evaluation of your safeguards, which is the hook pentests typically fall under. A proposed update from December 2024 would make it explicit, calling for vulnerability scanning at least every six months and penetration testing at least once a year. As of mid-2026 that update is not final, but the direction is clear.
Can autonomous testing satisfy it? Yes. Neither the current evaluation standard nor the proposed update mandates a human tester. An autonomous report is evidence of a periodic technical evaluation today, and it would satisfy the proposed annual-pentest obligation tomorrow, with continuous testing exceeding a once-a-year cadence.
Verdict: Yes, and ready for the proposed rule.
Reference: HIPAA Security Rule, 45 CFR 164.308(a)(8); 2024 NPRM (RIN 0945-AA22).
HITRUST CSF
The requirement: HITRUST CSF is a certifiable framework that US healthcare organizations and their vendors use to demonstrate protection of Protected Health Information (PHI). Penetration testing sits in its technical-compliance and security-assessment requirements. For the higher (r2) certification the test must fall within a rolling 12-month window and run as an ongoing program rather than a single yearly event, with findings tracked and retested.
Can autonomous testing satisfy it? Yes HITRUST does not require a human or accredited tester for the penetration test, and its preference for an ongoing program over a once-a-year event lines up with continuous autonomous testing. An autonomous penetration testing report is valid evidence for the assessor.
Verdict: Yes for the penetration testing requirement. The External Assessor validation is a separate audit step.
Reference: HITRUST CSF control 06.h (Technical Compliance Checking).
FDA premarket cybersecurity guidance
The requirement: The FDA’s guidance Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions recommends a layered security-testing approach, but in practice requires a penetration test report during pre-market submissions.
Can autonomous testing satisfy it? Yes. The guidance is outcome-oriented: it wants evidence that testing was performed, by whom, what scope, what was found and most importantly what you did about it. It ultimately comes down to ensuring the safety risks are under control. Aikido’s AI pentest report meets those expectations.
Verdict: Yes, but document scope, methods, and independence in the submission.
Reference: FD&C Act Section 524B; FDA premarket cybersecurity guidance (2025).
EU Medical Device Regulation (MDR)
The requirement: The MDR’s general safety and performance requirements expect medical-device software to be developed to the state of the art, with verification and validation and minimum IT-security measures across the product’s life. The EU’s medical-device cybersecurity guidance (MDCG 2019-16) names penetration testing as part of that verification and validation, alongside security-feature testing, fuzzing and vulnerability scanning.
Can autonomous testing satisfy it? Yes. The MDR and its guidance are method-neutral, and an autonomous penetration test is valid verification-and-validation evidence. Continuous testing also fits the life-cycle emphasis better than a one-off test. Similar to the FDA guidance, it comes down to proving the safety risks are under control.
Verdict: Yes.
Reference: EU MDR (Regulation (EU) 2017/745) Annex I, GSPR 17.2 and 17.4; guidance MDCG 2019-16.
IEC 81001-5-1
The requirement: This is the secure-software-lifecycle standard for health software, and will be harmonized for the MDR. Its software-system-testing activities include security-requirements testing, threat-mitigation testing, vulnerability testing and penetration testing. The standard asks for penetration testing to be carried out by a department or organization that is independent of the developers, and it has a separate provision on managing conflicts of interest between testers and developers.
Can autonomous testing satisfy it? Yes, and the independence requirement is a point in your favor. What the standard demands is organizational independence from the developers, not a human tester. As an external third party, Aikido satisfies that independence requirement, while the autonomous methodology and audit trail provide the documented, repeatable activity the standard expects.
Verdict: Yes, third-party independence satisfies the standard.
Reference: IEC 81001-5-1:2021 clause 5.7.4 (mapped to SVV-4) and 5.7.5.
Automotive
ISO/SAE 21434
The requirement: Automotive cybersecurity rests on ISO/SAE 21434, the engineering standard for vehicle cybersecurity, its risk methodology, and Threat Analysis and Risk Assessment (”TARA”). The standard names penetration testing as a way to validate that the cybersecurity goals were met.
Can autonomous testing satisfy it? Yes, for the parts it can reach. The standard is outcome based. Penetration testing is one validation method among several (e.g. fuzzing, SAST, DAST, …), and an autonomous pentest report is valid evidence, with continuous testing fitting the lifecycle emphasis as well. One caveat: vehicles are built on embedded components, physical security testing at a hardware level cannot be done through autonomous methods.
Verdict: Yes for the connected and backend attack surface. The standard is method-flexible and accepts autonomous testing as validation evidence.
Reference: ISO/SAE 21434:2021 cybersecurity validation (Clause 11, RQ-11-01).
Government & public sector
ENS
The requirement: Spain’s Esquema Nacional de Seguridad lists penetration testing as an explicit security measure. It is mandatory for high-category systems and recommended for medium-category systems, and recent results feed the framework’s periodic audit.
Can autonomous testing satisfy it? Yes. ENS specifies that you test, not who keys it in. Autonomous pentest results satisfy the measure, and continuous testing beats the recommended annual (high) and biennial (medium) frequencies.
Verdict: Yes, autonomous pentests fulfil the requirement.
Reference: ENS (Real Decreto 311/2022) Annex II measure mp.s.3; periodic audit under Article 31.
NIST SP 800-53
The requirement: NIST 800-53 has a dedicated penetration-testing control. It calls for penetration testing at a frequency the organization sets, provides for an independent penetration agent or team, and adds red-team exercises as an enhancement. The control says explicitly that penetration testing goes beyond automated vulnerability scanning and is carried out by agents and teams with demonstrable skills.
Can autonomous testing satisfy it? Largely yes, more so than PCI. The control is framed around independence and going beyond scanning, both of which Aikido meets: it is an independent third party, and it exploits and validates rather than only scanning. The control even uses the word “agents.” The residual judgment, whether an autonomous agent shows the required “skills,” sits with the assessing authority, so confirm acceptance with your assessor.
Verdict: Yes, with assessor concurrence. Independence and “beyond scanning” are clearly met.
Reference: NIST SP 800-53 Rev. 5, control CA-8 (with CA-8(1) and CA-8(2)).
US EO 14028
The requirement: This US executive order drove the Secure Software Development Framework (SSDF). The framework has a practice for testing executable code to find vulnerabilities, which is where dynamic testing, fuzzing and penetration testing sit. Suppliers to US federal agencies self-attest to following the framework on a CISA attestation form.
Can autonomous testing satisfy it? Yes. The framework is technology-neutral. An autonomous penetration test is a legitimate way to meet the code-testing practice, and your report is the evidence behind the self-attestation.
Verdict: Yes, human or manual testing is not required.
Reference: EO 14028 Section 4(e); NIST SSDF (SP 800-218) practice PW.8 and PW.8.2; CISA Secure Software Development Attestation Form (OMB M-22-18).
FedRAMP
The requirement: FedRAMP requires an annual penetration test across its baselines, run to a mandatory set of attack vectors and performed by an accredited third-party assessment organization (a 3PAO) for Moderate and High systems.
Can autonomous testing satisfy it? No. The penetration test behind a FedRAMP authorization, and the annual pentest that maintains it, must be performed by an accredited 3PAO. An autonomous test by a non-3PAO will not be accepted in an authorization package or an annual assessment. It can run between those engagements as additional security testing, but that is not authorization evidence.
Verdict: Does not meet the requirement. The pentests must be performed by an accredited third-party organization.
Reference: FedRAMP Penetration Test Guidance; NIST SP 800-53 control CA-8; 3PAO accreditation by A2LA.
FISMA
The requirement: FISMA inherits its testing expectations from NIST 800-53, applied through NIST’s Risk Management Framework. The scope and rigor are set by the agency and the system’s categorization.
Can autonomous testing satisfy it? Generally yes, the same logic as the NIST 800-53 control, subject to the agency’s assessment requirements. For systems that also pursue an external authorization with accredited-assessor rules (like FedRAMP), defer to that program’s constraints.
Verdict: Yes, but at agency discretion.
Reference: FISMA via NIST SP 800-53 (CA-8) and NIST SP 800-37 (Risk Management Framework).
International standards
SOC 2
The requirement: SOC 2 doesn’t explicitly require a pentest, but the AICPA (the governing body behind SOC 2) Trust Services Criteria point to one: the monitoring criterion mentions penetration testing as an acceptable evaluation method, and the criterion on detecting new vulnerabilities is supported by active testing. In practice, auditors expect pentest evidence, especially for a Type II report, within the audit period, with remediation and re-test evidence.
Can autonomous testing satisfy it? Yes. An independent third-party test is stronger evidence than an internal test, and the “ongoing or separate evaluations” language points toward continuous testing.
Verdict: Yes. Continuous testing maps directly to “ongoing evaluations.”
Reference: AICPA Trust Services Criteria CC4.1 and CC7.1
ISO/IEC 27001
The requirement: A few of ISO 27001’s Annex A controls are the hooks: one on managing technical vulnerabilities, which calls for “planned, documented and repeatable penetration tests or vulnerability assessments by competent and authorized persons”; one on security testing in development and acceptance; and one on the secure development lifecycle.
Can autonomous testing satisfy it? Yes. The language in the standard is almost a description of autonomous testing, and reproducibility is built into how the agents run. Auditors accept third-party automated and continuous testing as evidence here, and the report and audit trail provide the “documented” part.
Verdict: Yes. “Repeatable” testing is a natural fit.
Reference: ISO/IEC 27001:2022 Annex A; ISO/IEC 27002:2022 controls 8.8, 8.25 and 8.29.
European Regulations
NIS2 Directive
The requirement: NIS2 requires in-scope organizations to handle vulnerabilities and to have policies for assessing how well their security measures work. The implementing regulation spells this out with vulnerability management requirements and automated or manual security tests, penetration tests and vulnerability scans, carried out regularly and after significant changes.
Can autonomous testing satisfy it? Yes, explicitly. NIS2’s implementing regulation is one of the few instruments that names automated testing and penetration testing as acceptable methods. Continuous autonomous testing matches the “regular basis and after significant changes” language, and the report is evidence for both the vulnerability-management and effectiveness-assessment obligations.
Verdict: Yes. Automated and penetration testing are expressly contemplated.
Reference: NIS2 Directive (EU) 2022/2555 Article 21(2)(e) and (f); Implementing Regulation (EU) 2024/2690 Annex points 6.10 and 7.1.
GDPR
The requirement: GDPR requires a process for regularly testing, assessing and evaluating how well your technical and organizational security measures work.
Can autonomous testing satisfy it? Yes. GDPR does not prescribe a method and emphasizes regular testing, so continuous autonomous testing is a stronger demonstration of an ongoing process than an annual PDF. The report evidences both the testing and the remediation loop.
Verdict: Yes, it favors continuous testing.
Reference: GDPR (Regulation (EU) 2016/679) Article 32(1)(d).
Cyber Resilience Act
The requirement: The CRA requires products with digital elements to be placed on the market without known exploitable vulnerabilities and, as part of handling vulnerabilities over the product’s life, to apply effective and regular tests and reviews of the product’s security.
Can autonomous testing satisfy it? Yes. “Effective and regular” testing is what continuous autonomous pentesting delivers across the product lifecycle, and the report supports both the testing obligation and the “no known exploitable vulnerabilities” bar at release.
Verdict: Yes, “regular” testing favors autonomous penetration testing.
Reference: Cyber Resilience Act (Regulation (EU) 2024/2847) Annex I (Part I and Part II point 3); Article 13.
FAQ
Does AI pentesting work for SOC 2 compliance?
Yes, in most cases. SOC 2 doesn't specify who or what conducts a pentest, only that testing happened, findings were documented with evidence, and critical issues were addressed.
Will auditors accept an AI pentest report?
Most will, provided the report includes validated findings with proof-of-concept evidence, a methodology section, severity ratings, and remediation guidance. The main risk of rejection is submitting automated scanner output dressed up as a pentest, not a genuine AI pentest.
What's the difference between AI pentesting and automated scanning?
Automated scanners pattern-match against known vulnerability signatures and flag potential issues without confirming whether they're actually exploitable. A genuine AI pentest reasons about how the application works, attempts to exploit findings against a live target, and only surfaces vulnerabilities that were actually confirmed.
Does SOC 2 require a human pentester?
No. SOC 2 is outcomes-based, meaning it defines what your controls must demonstrate based on your written security policies rather than how testing must be conducted. The framework maps to Common Criteria controls like CC4.1 and CC7.1, and a well-documented AI pentest report satisfies those requirements.
Can AI pentesting replace manual pentesting for compliance?
For most SOC 2, ISO 27001, and HIPAA programs, yes. Certain regulated environments, like UK industries requiring CREST certification or US federal agencies requiring FedRAMP authorization, have accreditation requirements that currently need a human to co-sign the work.
How often do I need to run a pentest for compliance?
Most frameworks expect annual testing at minimum, plus retesting after significant changes are introduced to your application or infrastructure. AI Pentesting can cover this for SOC 2 and ISO 27001. PCI DSS a the more prescriptive framework, explicitly requiring both internal and external tests annually and after any significant change to the cardholder data environment. AI pentesting covers much of the application-layer portion of that requirement, but needs to be used by a human pentester. Network-layer and segmentation testing require separate coverage, typically from a human pentester.
What frameworks explicitly require penetration testing?
PCI DSS explicitly requires it under section 11.4, and FedRAMP requires it as part of cloud service provider authorization. SOC 2, ISO 27001, and HIPAA don't mandate it outright, but auditors routinely expect it as evidence that security controls are working.
What does a pentest report need to include for compliance?
At minimum: an executive summary, a methodology and scope section, validated findings with proof-of-concept evidence and reproduction steps, severity ratings, and a remediation plan. For SOC 2 specifically, findings should map to the relevant Trust Services Criteria.
Is AI pentesting accepted for ISO 27001?
Yes. ISO 27001 recommends pentesting as part of ongoing risk assessment but doesn't specify how it must be conducted. A report that documents what was tested, how, and what was found satisfies the framework's evidence requirements.
What are the limitations of AI pentesting with compliance?
Physical security testing and social engineering are out of scope for any application-focused pentest, AI or otherwise. PCI DSS needs a human pentester for network and segmentation testing at a minimum. Industries with specific accreditation requirements, such as CREST in the UK or 3PAO requirements under FedRAMP, may need additional steps before an AI pentest fully satisfies their compliance obligations.
