Penetration testing requirements: which rules require a test, and what applies to you
By The PenTest Index · Rules and offer terms checked October 8 to 10, 2026
Penetration testing requirements come from whoever needs your report: a rule, an auditor, a customer or your own policy. Of the 21 rules we track, 8 require a test, most with exemptions, and 5 set a yearly baseline, including PCI DSS, New York's NYDFS rule and the FTC Safeguards Rule. SOC 2, ISO 27001 and HIPAA do not require one universally today, but your contract might.
Find your row below. It shows what must be tested, who can do the testing, how often, and what proof to keep. Then we turn that into a brief you can send to providers.
Penetration testing requirements by rule: who must test and how often
Eight of the 21 rules in our rule tracker require a penetration test. Five set a yearly baseline: PCI DSS, the FTC Safeguards Rule, NYDFS, FedRAMP's legacy guidance and GovRAMP. A penetration test (pentest) is a planned, permitted attack on your own systems to find weak spots.
We read the text of the three rules most buyers ask about. Here is what each one says.
| Rule | What must be tested | Who may test | How often | Proof to keep |
|---|---|---|---|---|
| PCI DSS v4.0.1, Requirement 11.4 (card payments) | Inside and outside the network. The whole perimeter of the cardholder data environment (CDE, the systems that touch card data) and critical systems. Both the application layer and the network layer. Segmentation controls, if you use them to shrink scope. | A qualified internal person or a qualified outside firm. The tester must be organizationally independent. They do not have to be a QSA or ASV. | At least once every 12 months, and after any significant infrastructure or application upgrade or change. Segmentation tests: every 12 months, or every six months for service providers, and after any changes to segmentation controls or methods. | Fix exploitable findings by risk, then repeat testing to verify the fixes (11.4.4). Keep results and fix records for at least 12 months. |
| FTC Safeguards Rule, 16 CFR 314.4(d)(2) (non-bank financial firms such as auto dealers, tax preparers, mortgage brokers) | Your information systems, chosen each year from the risks in your risk assessment. | The rule does not say. | Yearly, plus vulnerability assessments at least every six months, whenever material operations or business-arrangement changes occur, and whenever other circumstances you know or reasonably should know may materially affect your information security program. Only if you have neither effective continuous monitoring nor other systems that detect ongoing information-system changes that may create vulnerabilities. | Testing results feed your program review and the Qualified Individual's written report, regularly and at least annually, to your board or equivalent governing body. If neither exists, the report goes in a timely manner to the senior officer responsible for the program. |
| NYDFS, 23 NYCRR 500.5(a)(1) (firms licensed by New York's financial regulator) | Your information systems "from both inside and outside" their boundaries. | A qualified internal or external party. | At least annually. | Written vulnerability management policies, and timely fixes ranked by risk. |
Sources: PCI SSC, Prioritized Approach for PCI DSS v4.0.1, requirements 11.4.1 to 11.4.6; 16 CFR 314.4; 23 NYCRR Part 500. All read October 10, 2026.
Three conditions change the answer before you spend anything.
PCI DSS: which requirements apply depends on how your company validates. Ask your acquirer or QSA whether 11.4 applies to your environment.
FTC Safeguards Rule: the testing duty does not apply to firms that hold customer information on fewer than 5,000 consumers (16 CFR 314.6). That exception covers four listed provisions, not the whole rule.
NYDFS: a limited exemption removes section 500.5 for a covered entity with fewer than 20 employees and independent contractors across the entity and its affiliates, or less than $7.5 million in gross annual revenue in each of the last three fiscal years from all the entity's business operations plus its affiliates' New York business operations, or less than $15 million in year-end total assets calculated under generally accepted accounting principles, including all affiliate assets (section 500.19(a)). Confirm your status with DFS's own exemption guidance before you rely on it.
The other five rules that require a test
| Rule | Who it covers | How often |
|---|---|---|
| FedRAMP legacy Rev. 5 Penetration Test Guidance | Cloud services following that guidance | At least every 12 months, unless the authorizing body approves another interval. FedRAMP launched new consolidated rules in June 2026 with a January 1, 2027 transition, so confirm which rule set applies to you. |
| GovRAMP Penetration Testing Requirements Guide | Cloud services subject to that guide | At least every 12 months, unless approved otherwise |
| NIST SP 800-53 Rev. 5, control CA-8 | Systems using the High baseline, subject to tailoring | A frequency the organization defines |
| EU DORA, Article 26 | Financial firms their regulator identifies for advanced testing | Threat-led penetration testing at least every 3 years |
| IRS Publication 1075, control CA-8 | Agencies and contractors that receive federal tax information | Every 3 years |
Source: our rule tracker, checked October 8, 2026. We read DORA Article 26(1) again on October 10, 2026.
CMMC Level 3 sits apart. Its rule still says to test at least annually or after significant security changes. The Defense Department suspended the Phase II rollout on July 13, 2026, so read your actual contract.
Rules that mention a test, and rules that do not name one
Eight more rules mention penetration testing or give guidance without a general duty to commission one: SOC 2, the EU's NIS2, the NIST Cybersecurity Framework 2.0, Swift's customer security controls, the FDA's premarket guidance for medical devices, the TSA pipeline directive, Singapore's MAS guidelines and the FBI's CJIS policy. Device makers can read what FDA's guidance says about testing.
Four do not name a penetration test at all: the HIPAA Security Rule in force today, CMMC Level 2, NERC CIP-010-4 and ISO/IEC 27001:2022.
This table reports what each text says. It is not legal advice. Your auditor, QSA, regulator or customer decides what they accept.
Is a penetration test required for SOC 2, ISO 27001, HIPAA or GDPR?
No. None of the four names a penetration test as a universal requirement in the text we checked. What can still bind you is a control you wrote yourself, or a contract you signed.
SOC 2. The criteria mention penetration testing once, under CC4.1, as one kind of evaluation management may use. No interval is given (AICPA Trust Services Criteria, read October 10, 2026).
ISO/IEC 27001:2022. Our tracker's reading of Annex A controls 8.8 and 8.29 found no named penetration test and no stated interval (checked October 8, 2026). The full standard is a paid document that we read through a public mirror, so check your own licensed copy and your selected controls.
HIPAA. The Security Rule asks for a risk analysis and a "periodic technical and nontechnical evaluation" (45 CFR 164.308, read October 10, 2026). It does not name a penetration test. A proposed update from January 6, 2025 would require one at least every 12 months. It was still not final when we checked on October 8, 2026. A proposal is not a requirement.
GDPR. Article 32(1)(d) asks for "a process for regularly testing, assessing and evaluating the effectiveness" of your security measures, as appropriate to the risk (EUR-Lex, read October 10, 2026). It names no method and no interval.
So why does everyone say you need one? Often because of your own paperwork. If your SOC 2 control or security policy says "an independent penetration test is performed annually," you have set your own requirement. It works like putting a date on your own calendar: nobody made you, but now people will check that you kept it.
If an auditor tells you a test is required, ask one question first:
"Which control or request requires this test, and what scope and dates must the evidence cover?"
The answer tells you what to buy, or whether you need to buy anything.
What do customers require in a penetration test?
A customer can ask for more than any rule does, and their contract is the requirement that counts. Customers also tend to be specific about how the test is done, which most rules are not.
Google publishes the rules it sets for its own suppliers, so it makes a useful public example. Its supplier penetration testing guidelines (read October 10, 2026) check seven things:
- The test was done in the past 12 months.
- The testing effort matches the number of systems tested.
- The scope covers every system used to serve Google.
- A third-party provider did the test.
- The work used manual methods. Google says automated testing, or manually checking automated results, does not meet this.
- Testers had suitable authenticated test accounts.
- Critical and high findings must be fixed, not just accepted as risk. If fixes are still pending when the report is shared, include a remediation plan; for completed fixes, include confirmation.
Google also says an automated scan or a bug bounty program is not a replacement for the report. A Google Security Engineer may accept a valid ISO 27001 certification or SOC 2 report as an alternative. It notes that its requirements can differ by vendor.
Your customer is probably not Google, and their list will differ. That is the point. Do not guess. Send them the questions for your report recipient and get the answers in writing before you compare offers.
What does a penetration test need to include to be accepted?
Six things decide whether a report is accepted: what was tested, who tested it, how, when, what the report shows, and proof that fixes were checked. Each rule or customer spells out some of these and leaves the rest open.
Much of what people believe about these six is assumed, not written. Here is what the text says.
| Common belief | What the text we read says |
|---|---|
| "Every compliance rule requires a yearly pentest." | Five of the 21 rules we track set a yearly baseline. |
| "A vulnerability scan counts." | PCI DSS, the FTC rule and NYDFS each list scanning and penetration testing as separate duties. |
| "It has to be an outside firm." | PCI DSS and NYDFS both allow a qualified internal tester. PCI DSS adds that the tester must be organizationally independent. Google's supplier rule does require a third party. |
| "The tester must be a QSA." | PCI DSS says the tester is "not required to be a QSA or ASV." |
| "An external test is enough." | NYDFS says inside and outside. PCI DSS requires internal and external testing. |
| "Internal testing means our staff do it." | In these rules, internal and external describe where the test starts from: inside or outside your network. Who employs the tester is a separate question. |
| "The offer says compliant, so the report will pass." | The person who receives the report decides. A provider's label is not their approval. |
How to turn your requirement into a brief
Write each requirement as a condition that a scope, a report or a provider's written answer can prove. A brief gives every provider the same question, so their answers line up and you can compare them.
Copy this and fill it in privately. For each line, mark it Mandatory, Preferred or Assumed, and note where it comes from.
Your penetration testing requirements brief
| Field | Fill in |
|---|---|
| 1. Exact requirement and source | The wording, plus the document, version and clause or control |
| 2. Why it applies, and who decides | Who interprets the requirement; who receives the report |
| 3. Systems and boundaries | Apps, APIs, networks, environment, user roles, tenant boundaries; what is excluded |
| 4. Testing work and access | Inside, outside or both; test accounts, documents or source code you will provide |
| 5. Tester conditions | Experience, independence, outside-party or named-credential conditions, each with its source |
| 6. Dates and triggers | Test interval, change triggers, how recent the report must be, delivery deadline, retest deadline |
| 7. Evidence and follow-through | What the report must contain, what can be shared, proof of fixes, proof the fixes were checked |
| 8. Existing work and gaps | What a current report clearly covers; what is missing or unconfirmed |
| 9. Decision and next question | Reuse, clarify or buy the missing scope; the one question that could change this |
The brief is a purchasing aid. It does not authorize anyone to test anything.
A filled-in brief leads to one of three results, and all three are good ones:
- Reuse existing work, when it clearly meets every mandatory line and the recipient's needs.
- Clarify a vague request before you buy anything.
- Buy the missing scope, when a real mandatory gap remains.
Which penetration testing offers meet these requirements?
Start with the line that rules an offer out. In the example below, two mandatory lines do most of the sorting: authenticated testing and an outside tester.
Say you run a 30-person SaaS company with one web app and an API. This buyer is made up. You are preparing for SOC 2, and one enterprise customer's contract asks for a yearly test by an independent third party. It must cover the app and the API with two signed-in user roles, and fixes must be checked before the contract renews. Last year two of your own engineers tested the app.
The verdict first. Your in-house test does not meet this contract, and it missed the API. You need an outside test with signed-in roles. Among the published offers we checked, a black-box package is out, an AI-led package is a risk until the customer approves it in writing, and the retest window is the detail most likely to catch you later.
| Requirement in the brief | Checked against | Finding | Why | Question to send |
|---|---|---|---|---|
| Independent third party (mandatory) | Last year's test by your own staff | Mismatch | The contract names an outside provider | To the customer: "Would you accept internal testing? Please confirm in writing." |
| App and API (mandatory) | Last year's report | Mismatch | The report covers the app only | To any provider: "Does this quote cover the app and every API we listed?" |
| Two signed-in roles (mandatory) | Pentest-Tools.com black-box web app test, $3,400 | Mismatch | Sold as an anonymous-attacker test | "Can you add signed-in roles, and at what price?" |
| Two signed-in roles (mandatory) | Pentest-Tools.com grey-box web app test, from $3,400 + $900 per user role | Supported, starting amount only | Tests anonymous and signed-in users. Two roles: $3,400 + (2 × $900) = $5,200 | "What is the complete price with our API and a retest?" |
| Fixes checked before renewal (mandatory) | Pentest-Tools.com, either test | Unresolved | We found no retest count or window on its page | "How many retests are included, and until when?" |
| Fixes checked before renewal (mandatory) | Astra Pentest Expert, $5,999 per year per target | Unresolved, published window known | Two manual rescans; requests must be submitted within 30 days from the date the findings were reported. Extensions are case by case. Completion before renewal is unconfirmed | "Can the request window be extended, at what cost, and when will the rescan be completed?" |
| Fixes checked before renewal (mandatory) | Cobalt Agile or Comprehensive test on Standard, Premium or Enterprise | Unresolved, published window known | Free retest requests for 6 months (Standard) or 12 months (Premium, Enterprise), while the contract is active, with a cutoff 10 days before contract end if earlier. Retesting is completed within seven days after submission; the renewal schedule is unconfirmed | "What is our contract end date, and how many credits does this test need?" |
| Customer accepts the testing method (assumed) | Cobalt Autonomous Pentest, $3,500 per test promotion; Astra Pentest Auto | Unresolved | Both are sold as AI-led. Your contract may or may not allow that | To the customer: "Do you accept an AI-led test with human oversight?" |
All offer terms are provider-published and were read on October 10, 2026, except Astra Pentest Auto's description as autonomous testing, which comes from our comparison checked October 7, 2026. Cobalt's $3,500 price is a promotion: the test must start and finish before December 31, 2026. The $5,200 figure is our arithmetic on a published starting formula. It is not a quote, and it does not price the API or a retest. "Supported" means that one line is supported by the provider's page. It does not rate the provider or promise your customer will accept the report.
View the web app testing service
View Astra's plans and pricing
View Cobalt's pricing and offer terms
How to choose from here. If you want a published price for a human test with signed-in roles, the Pentest-Tools.com grey-box offer is the place to start, once you have its retest terms and API price in writing. If you expect fixes to take more than a month, look hard at the retest window. Four reports published in 2026 put repair and resolution benchmarks for serious flaws at 38 to 58 days, each measured a little differently. Cobalt's resolved findings include accepted risk. A 30-day request window is shorter than that, so ask about an extension before you sign. If you plan several tests a year, Cobalt's longer retest periods fit better, but its packages need a quote. And if a cheaper AI-led test tempts you, get the customer's yes first.
Not our example? The same steps work for your brief. Your requirement lines decide which offers are even worth a call. Answer a few questions and see which of the web app and API offers we compare fit, with a brief to send the providers you choose. It is free, needs no email or sign-up, and nothing is sent to providers.
Need internal network testing for PCI DSS or NYDFS? Most single web app packages will not cover it. Ask each provider to confirm inside and outside scope in the quote, and see which type of test fits.
Does a vulnerability scan meet a penetration testing requirement?
No, where the rule lists them as two separate duties, and the three rules we read all do. A scan looks for known weak spots. A penetration test tries to use them, the way an attacker would.
The FTC rule asks for yearly penetration testing in one line and vulnerability assessments every six months in the next. NYDFS asks for penetration testing in 500.5(a)(1) and automated scans in 500.5(a)(2). PCI DSS puts scanning under Requirement 11.3 and penetration testing under 11.4. Google's supplier rules say a scan alone does not meet its requirement.
A report with "penetration test" on the cover is not proof either. Read what was done. Our guide to penetration testing versus vulnerability scanning shows how to tell them apart.
Can an automated or AI penetration test meet the requirement?
It depends on who reads the report. The FTC and NYDFS text we read does not ban or bless a tool. PCI DSS guidance describes a highly manual process that may use automated tools. Some customers do: Google's supplier rules say most of the work must be manual, and that automated testing with manual checking does not qualify.
An "AI" or "autonomous" label settles nothing in either direction. What matters is the work done, the human role and the evidence in the report. Send the provider this:
"Please describe the testing work, the human role, the attack paths you validated and the report evidence for this exact scope. Name any mandatory condition in our brief it does not cover."
Then send the answer to whoever receives your report, and ask if they accept it. A refund promise from a provider is not the same as that acceptance.
Who is allowed to perform the penetration test?
It varies by source. PCI DSS and NYDFS both allow your own qualified people. A customer contract may still require an outside firm.
| Source | Can your own team test? | Condition | Evidence to ask for |
|---|---|---|---|
| PCI DSS 11.4.2 and 11.4.3 | Yes, a "qualified internal resource" | The tester must be organizationally independent. Not required to be a QSA or ASV | Who tested, their relevant experience, and how their role is separate from the systems tested |
| NYDFS 500.5(a)(1) | Yes, a "qualified internal or external party" | Must be qualified | Who tested and why they are qualified |
| FTC Safeguards Rule | The rule does not say | None stated in 314.4(d)(2) | Your own record of who tested and why |
| Your contract | Read it | Often names a third party, as Google's supplier rule does | The provider's name on the report |
None of the texts we read names a specific certificate a tester must hold. A credential can help show someone is qualified. It does not prove it on its own.
How often is penetration testing required, and when should you start?
Every 12 months is the most common stated interval, and PCI DSS adds a test after any significant change. DORA's threat-led tests and IRS Publication 1075 run on three-year cycles.
The date that catches people is not the test date. It is the date the fixes must be proven. Work backward.
Say your recipient wants a report with fixes verified by June 30. This is an illustration, not a schedule. If you allow 58 days for fixes, matching the highest benchmark above, May 3 is the latest findings date before allowing time for retesting and evidence delivery. Start earlier by the verification time your provider agrees. If findings arrive on May 3 and your offer's rescan request window is 30 days from the date findings are reported, that request window closes on June 2. So either your fixes land inside 30 days, or you need an extension agreed before you sign.
Ask every provider for three dates in writing: when testing starts, when the final report arrives, and when the retest window closes.
What do you need before a penetration test can start?
Written permission that names the actual targets and the activities allowed. Without it, nobody should touch your systems, and a scope brief or checklist from us does not provide it.
Agree these before testing begins:
- The named systems, the environment (production or staging) and what is off limits
- Who signs the authorization, and that they have the right to
- Test accounts and how access will be shared safely
- Permitted and prohibited activities, including any third-party services
- The testing window, and who to call to stop or resume
- How test data will be handled and deleted
- When and how the report will be delivered
If your systems run on a cloud or hosting platform, check that platform's current testing policy too. Your own permission does not cover someone else's infrastructure.
NIST's testing guide, SP 800-115, treats these agreed rules as part of planning a test. Our scope guide has a filled-in example, and how a penetration test is done walks through the steps.
A few remaining questions
Does CMMC require a penetration test?
Level 2 does not name one. Level 3 has a clause that says to test at least annually or after significant security changes, but the Defense Department suspended the Phase II rollout on July 13, 2026 (our tracker, checked October 8, 2026). Read your contract and the current DoD instructions.
Can one penetration test satisfy several rules?
Yes, if it covers the scope, dates and evidence each one needs. "Same provider" or "same framework" is not proof. Put every requirement in one brief, mark each line with its source, and check the report against all of them.
Does cyber insurance require a penetration test?
We did not find public insurer wording we could cite, so we will not guess. Ask your broker for the exact question on the application and treat it like any other line in your brief.
Do you need a new test if you already have a report?
Not always. Check the report against your brief first. If it clearly meets every mandatory line and it is recent enough for the recipient, reuse it. If it misses one area, ask your current provider to add that scope before you pay for a whole new test.
Looking for the requirements to become a penetration tester?
This page is about buying a test. For job skills, see the NICE Workforce Framework.
What to do next
Fill in the brief, send the same one to every provider, and keep any unanswered mandatory line next to that offer until it is answered in writing.
Already have a proposal? Check it against your brief with Quote Check. Ready to look at offers? Compare published penetration testing offers. Still working out the budget? See published penetration test prices.
Sources and how we checked
We read the rule text for the conditions shown here and kept rules, proposals and made-up examples apart. Where we relied on our own tracker instead of re-reading a rule today, the row says so. We do not perform, authorize or certify penetration testing, and we have not bought the offers listed. Read how we check offers.
| Source | What we used | Checked |
|---|---|---|
| PCI SSC, Prioritized Approach for PCI DSS v4.0.1 | Requirements 11.4.1 to 11.4.7, plus the full standard's 11.4.1 guidance, read from the Council-authored standard on a university mirror because the issuer's full-standard download was blocked | October 10, 2026 |
| 16 CFR 314.4 and 314.6 | Paragraphs (d), (g), (i); the under-5,000-consumers exception | October 10, 2026 |
| NYDFS, 23 NYCRR Part 500 | Sections 500.1(l), 500.5, 500.19(a) | October 10, 2026 |
| AICPA Trust Services Criteria, red-lined version | CC4.1 point of focus | October 10, 2026 |
| 45 CFR 164.308 | (a)(1)(ii)(A) and (a)(8) | October 10, 2026 |
| HHS proposed HIPAA Security Rule update | Proposed status | October 8, 2026 |
| GDPR, Regulation (EU) 2016/679 | Article 32(1) | October 10, 2026 |
| DORA, Regulation (EU) 2022/2554 | Article 26(1) | October 10, 2026 |
| The PenTest Index rule tracker | Counts and the rows for FedRAMP, GovRAMP, NIST SP 800-53, IRS 1075, CMMC, ISO/IEC 27001 and the eight rules that mention testing | October 8, 2026 |
| Google supplier Penetration Testing Guidelines | The seven report checks and method rules | October 10, 2026 |
| Pentest-Tools.com, web app penetration testing | Black-box and grey-box prices, scenarios, timing (provider-published) | October 10, 2026 |
| Astra, plans and pricing and rescan rules | Pentest Expert price, rescan counts and window (provider-published) | October 10, 2026 |
| Cobalt, pricing and retest policy | Autonomous Pentest promotion, retest periods and contract cutoff (provider-published) | October 10, 2026 |