PCI DSS penetration testing: what Requirement 11.4 actually asks for, how often, and whether it reaches a SaaS on a hosted checkout

At least every 12 months and after significant changes: that is how often PCI DSS penetration testing is required under Requirement 11.4, and service providers test any segmentation they use at least every six months. Whether 11.4 reaches you depends on how you take cards: Stripe points Checkout and Elements to SAQ A, which in v4.0 does not list 11.4.

What PCI DSS penetration testing is: Requirement 11.4, line by line

PCI DSS penetration testing is Requirement 11.4 of the standard: a documented methodology, internal and external tests at least once every 12 months and after any significant upgrade or change to infrastructure or applications, exploitable findings corrected and the test repeated to verify the corrections, and segmentation tested where it is used to isolate the cardholder data environment.

That one requirement is what a PCI pen testing request refers to, whatever the wording in the email. Where it sits among the other controls a web app needs is in web app security.

The current standard is PCI DSS v4.0.1, which the council published on 11 June 2024 as “a limited revision” of v4.0, with “no additional or deleted requirements”. The revision did clarify “the focus and intent of some of the requirements and guidance”, so the wording below can differ slightly from the v4.0.1 text your assessor reads. The requirement text below comes from the council’s self-assessment questionnaire D for v4.0, which prints each requirement in full, and from the service provider version of the same questionnaire for the last two rows. The version history is in the council’s note on PCI DSS v4.0.1.

An older PCI DSS pentest report may use different numbers: the council’s penetration testing guidance, dated September 2017, calls the test Requirement 11.3, and under v4.0, published in March 2022, it is 11.4.

Penetration testing counts toward PCI compliance through the card brands, your acquirer or your payment provider, not through the council. The council says it does “not define compliance requirements for any organization or set compliance validation responsibilities”, and that “Compliance validation requirements are set by brands, acquirers, payment facilitators, etc.” So the final word on what you must submit is theirs, and nothing on this page is legal or assessor advice.

PCI DSS compliance testing: the scan, the penetration test and the segmentation check

PCI DSS compliance testing includes three kinds of test from Requirement 11: internal vulnerability scans, external scans by an Approved Scanning Vendor, and the penetration test with its segmentation check. Scans are due at least once every three months, the penetration test at least once every 12 months, and each after any significant change.

The difference between a scan and a test is set out in the council’s penetration testing guidance. A scan runs “At least quarterly and after significant changes” and is “Typically a variety of automated tools combined with manual verification of identified issues”. A penetration test runs “At least annually and upon significant changes” and is “A manual process that may include the use of vulnerability scanning or other automated tools, resulting in a comprehensive report”. That wording dates from 2017, under the old numbering, and the cadences still match the questionnaire rows above.

PCI scanning, for a merchant on SAQ A or SAQ A-EP, means external scans only, since neither questionnaire lists the internal scans in 11.3.1. A PCI scan service is an Approved Scanning Vendor: an organization whose “ASV scan solution is tested and approved by PCI SSC” before it joins the council’s list of approved scanning vendors. The PCI scanning tools that count for 11.3.2 are that vendor’s own solution, and the council says it “does not endorse” the vendors it lists; I name and rank none of them. A free online PCI compliance checker is not an ASV scan, in my reading: the scan that counts for 11.3.2 comes from a listed vendor’s approved scan solution.

Scanner versus penetration test versus red team, outside PCI, is covered in pen test vs vulnerability assessment. If a request leaves you unsure what it wants, start with which of a scan, a code review and a test you are being asked for.

Why it matters for a small SaaS: whether 11.4 applies to you at all

Requirement 11.4 reaches a merchant that validates with a self-assessment questionnaire only where that questionnaire lists it, and the questionnaire follows how card data reaches the payment provider. In the council’s v4.0 questionnaires, SAQ A lists no part of 11.4, SAQ A-EP lists the external test but not the internal one, and SAQ D for merchants lists 11.4.1 to 11.4.5.

The SAQ A row holds only while you meet its eligibility criteria. One of them reads: “All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.” The questionnaire adds that a requirement which applies to your card data environment but is missing from it “may be an indication that this SAQ is not suitable”. Stripe makes the same point from its side: writing your own code to handle card information can leave you “ineligible for an SAQ A”.

The row lists in the table come from the v4.0 editions. On 30 January 2025 the council announced a new SAQ A that removes Requirements 6.4.3 and 11.6.1, along with 12.3.1, the risk analysis behind 11.6.1, and adds an eligibility criterion that merchants “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)”. That version took effect on 31 March 2025, and the council notes the changes “do not remove or diminish the underlying requirements within PCI DSS”. The details are in the council’s January 2025 SAQ A update.

My reading for a small SaaS: the cheapest way to meet 11.4 is an integration that never brings it in. An app that swapped the hosted card fields for its own form “to match the design” may have moved itself from the SAQ A row to a longer one without anyone deciding to. The PCI DSS web application security requirements work the same way, through the rows your questionnaire lists, and the full scoping question, the list of requirements and the attestation document are a separate topic: PCI DSS requirements for a SaaS on Stripe.

PCI DSS web application security requirements: what Requirement 6.4 adds

Web application security requirements mandated by PCI DSS sit in Requirement 6, not 11, and each reaches a merchant only where its questionnaire lists it. Requirement 6.4.1 asked for public-facing web applications to be reviewed “At least once every 12 months and after significant changes” “By an entity that specializes in application security”, or protected by “an automated technical solution(s) that continually detects and prevents web-based attacks”. That review route has closed: the questionnaire says 6.4.1 “will be superseded by Requirement 6.4.2 after 31 March 2025”, and 6.4.2 asks that “an automated technical solution is deployed that continually detects and prevents web-based attacks”, configured “to either block web-based attacks or generate an alert that is immediately investigated”.

Requirement 6.4.3 covers payment page scripts: a method to confirm each script is authorized, a method to assure its integrity, and an inventory “with written justification as to why each is necessary”. In the v4.0 questionnaires, SAQ A-EP and SAQ D list all three rows, and SAQ A listed only 6.4.3, which the January 2025 update then removed from it. The automated solution itself is usually a firewall in front of the app; setting one up is a separate question: how to set up a web application firewall.

How it works: how often, who may test, what is in scope, what to keep

Once the test is on your questionnaire, four practical questions follow: when the test is due, who may run it, what it has to cover, and what you keep afterwards.

Annual penetration testing, and what counts as a significant change

Annual penetration testing under PCI DSS means at least once every 12 months, plus a test after any significant infrastructure or application upgrade or change. What counts as significant is not prescribed by the standard: the council’s guidance leaves it to the entity’s own risk assessment and environment.

The exact row words are in the two tables above. The guidance is plain that “a significant change is not prescribed by PCI DSS”, and it gives one test: “If the change could impact the security of the network or allow access to cardholder data, it may be considered significant by the entity.” My working rule for a small SaaS is to treat four changes as significant: moving from a hosted checkout to your own card form, changing payment provider, moving to a new hosting platform, and putting new authentication in front of the payment flow.

An annual penetration test that a customer’s security questionnaire asks for is usually not PCI at all, in my reading. For that request, see what is the pen test a customer is really asking for.

Who may run the test

The penetration tester can be a qualified internal resource or a qualified external third party, and the standard asks for organizational independence of the tester; it is not required to be a QSA or an ASV. In my reading, independence in a company of two means an outside tester.

The guidance puts the independence rule more sharply: the tester “must be organizationally separate from the management of the target systems”, and a firm doing the entity’s PCI DSS assessment “cannot perform the penetration test if they were involved in the installation, maintenance, or support of target systems”. On skills, certifications “may be an indication of the skill level and competence” of a tester, though the guidance calls them “not required certifications”. Its examples include OSCP, CEH, GIAC and CREST certifications, listed without ranking, and the council states it “does not validate or endorse these certifications”.

For a two-person company the practical effect is simple: the developer who built the payment flow manages that system, so someone else tests it. What that tester does during the engagement is covered in web application penetration testing.

Scope: the cardholder data environment, the application layer and segmentation

For the method, the guidance names OSSTMM, NIST SP 800-115, the OWASP Testing Guide, the Penetration Testing Execution Standard and the Penetration Testing Framework, “including but not limited to” those. The phases of a test belong to the web application penetration testing guide linked above.

Your payment provider covers its own part under its own assessment. Stripe says it “is certified annually by an independent PCI Qualified Security Assessor (QSA) as a PCI Level 1 Service Provider meeting all PCI requirements”, in Stripe’s integration security guide. Your hosting platform’s attestation is a separate document from Stripe’s; one example is Vercel’s PCI DSS attestations.

The report, the retest and the evidence to keep

A PCI penetration test report built on the council’s suggested outline has nine sections: executive summary, scope, methodology, limitations, testing narrative, segmentation results, findings, tools used, and cleanup. A retest report adds the dates and results. Keep results and remediation evidence for at least 12 months.

The guidance says these are “only suggested outlines and do not define specific reporting requirements”, and that “Testers may have different sections, alternative titles, and/or report format”. The outline, in its own section names:

1. 01 Executive Summary
2. 02 Statement of Scope
3. 03 Statement of Methodology
4. 04 Statement of Limitations
5. 05 Testing Narrative
6. 06 Segmentation Test Results
7. 07 Findings
8. 08 Tools Used
9. 09 Cleaning up the Environment Post-Penetration Test

Its example retest report has five parts: Executive Summary, Date of Original Test, Date of Retest, Original Findings and Results of Retest. The attestation that carries the result to your payment provider is covered in the SaaS-on-Stripe guide linked above.

Pen testing under other frameworks: ISO 27001, HIPAA, FedRAMP

Pen testing under other frameworks is tied to each framework’s own controls. ENISA maps security testing to ISO/IEC 27001 controls A.8.29, A.8.33 and A.8.34. HIPAA’s 45 CFR 164.308 never uses the word, though HHS proposed a test at least every 12 months in January 2025. NIST’s CA-8 leaves the frequency open; FedRAMP applies it to Classes B, C and D.

ISO 27001 penetration testing: the Annex A controls it maps to

ISO 27001 penetration testing evidence belongs under Annex A controls: ENISA’s mapping of the NIS2 technical measures to ISO/IEC 27001:2022 lists controls A.8.29, A.8.33 and A.8.34 against “Security testing” and A.8.8 against “Vulnerability handling and disclosure”. Whether ISO 27001 does or does not require pen testing by name is not checked here, because the standard’s own text was not readable to me. The table prints control numbers only, not their titles, so I don’t give titles either. The source is ENISA’s NIS2 implementation guidance and mapping table.

In my reading, an ISO 27001 penetration test is evidence under those controls, and how often you run one follows your own risk treatment. Which controls a company applies, and why, is recorded in its statement of applicability, part of what ISO 27001 certification costs a small SaaS.

HIPAA penetration test: what the Security Rule says today, and the proposed change

HIPAA is United States law, and this section covers only the Security Rule. Whether the current rule requires a test is answered in whether the HIPAA Security Rule requires a penetration test.

What this page adds is HHS’s proposed rule, published in the Federal Register on 6 January 2025 as document 2024-30983. It would make HIPAA penetration testing a named specification: “Penetration testing must be performed at least once every 12 months or in accordance with the covered entity’s or business associate’s risk analysis required by Sec. 164.308(a)(2), whichever is more frequent.” The test would be run by “a qualified person”, and automated vulnerability scans would run in line with the risk analysis “or at least once every six months, whichever is more frequent”. The full text is in HHS’s proposed Security Rule update.

It is still a proposed rule. The Federal Register’s own search returns no final rule for it, and the government’s regulatory agenda lists it under “Long-Term Actions”, with a final action dated July 2027.

FedRAMP vulnerability scanning requirements and penetration testing

FedRAMP applies to cloud services sold to United States federal agencies. FedRAMP’s control reference covers “every active control and control enhancement in the vendored NIST SP 800-53 Revision 5 OSCAL catalog”. In NIST’s catalog, RA-5 is “Vulnerability Monitoring and Scanning” and CA-8 is “Penetration Testing”, which reads “Conduct penetration testing [Assignment: organization-defined frequency] on [Assignment: organization-defined system(s) or system components]”.

Who CA-8 reaches differs between the two lists. NIST’s own baseline profiles select CA-8 in the high baseline only, while FedRAMP’s reference lists CA-08 under “FedRAMP Rev5 Baselines: Class B Class C Class D”. FedRAMP’s guidance on the control adds: “Penetration testing is part of vulnerability detection and is subject to the Vulnerability Detection and Response rules.”

Those rules sit in FedRAMP’s “Consolidated Rules for 2026”, separate from its “Legacy Documentation Reference”. They launched on 24 June 2026, allowed optional adoption from 4 July 2026, and apply to initial and ongoing certification from 7 December 2026. For scanning they set a SHOULD rather than one scan date: providers “SHOULD persistently perform vulnerability detection” on resources likely to drift at least once every 3 months for Class A, every month for Class B, every 14 days for Class C and every 7 days for Class D, and remediation timeframes vary by class, potential agency impact, internet reachability and likely exploitability. A small SaaS does not end up under FedRAMP by accident, in my reading; the row is here so you can recognize the request when it arrives.

How to check your own app before you pay for a test

The PCI self-check is six steps: confirm where the card fields are served from, search code and logs for card numbers, find the questionnaire your provider points you to and read its Requirement 11 rows, date the last test against your changes, check the report against the outline, and collect the scan reports.

Run these only on systems you own. Each check has a pass condition and the evidence to keep, and each is my working rule.

1. 01 Open your payment page with the browser's developer tools and find the card fields. Pass: they sit in an iframe whose origin is your payment provider's domain, or on the provider's own hosted page. Evidence: a screenshot that shows the frame's origin.
2. 02 Search your codebase, and the logs your host still keeps from about the last 30 days, for runs of 13 to 19 digits. Pass: you opened every hit and none is a card number other than your provider's published test cards. Evidence: the search command, the date and the list of hits you cleared.
3. 03 Find which questionnaire your payment provider says applies to you and read its Requirement 11 rows. Pass: you know whether 11.4 and 11.3.2 are on it. Evidence: the questionnaire or the provider's screen that names it.
4. 04 If 11.4 is on it, find the date of your last penetration test and list every significant change since. Pass: the test is less than 12 months old and no significant change came after it untested. Evidence: the report's cover page and the change list.
5. 05 Check the report against the council's suggested outline, including the retest report for anything that was fixed. Pass: scope, methodology, segmentation results and findings are all there, and every exploitable finding has a retest. Evidence: the marked-up outline.
6. 06 If 11.3.2 is on it, collect the quarterly ASV scan reports for the last year and any scans run after significant changes. Pass: a passing scan every quarter, or the first-year condition below. Evidence: the scan reports.

For check 2, one search over the repository and an exported copy of your logs lists the candidates:

# Every hit is a candidate to open and read, not a failure.
grep -rEn --exclude-dir=node_modules --exclude-dir=.git \
  -e '(^|[^0-9])[0-9]{13,19}([^0-9]|$)' \
  -e '[0-9]{4}[ -][0-9]{4}[ -][0-9]{4}[ -][0-9]{1,7}' \
  . ./exported-logs

Expect hits that are not cards: millisecond timestamps, long numeric ids and phone numbers match the same pattern. A Luhn check on each hit shortens the list, but some timestamps pass it too, so read what is left. An empty result on logs your host has already deleted proves nothing, which is why the search covers only what it still holds.

For check 3, Stripe tells its users to “Review the documentation requirements for your business in your Dashboard”. For check 6, the questionnaire’s first-year note says four passing scans are not required within the first 12 months if “the most recent scan result was a passing scan”, scanning every three months is written policy, and the scan’s findings were corrected in a rescan. A failed check 1 or 2 is the one to fix first, because it changes every answer after it.

Where the sprint fits

The Production Hardening Sprint’s deliverable 3.10, targeted external penetration testing, tests the five highest-risk externally reachable attack surfaces, remediates findings, and delivers the methods and evidence. Deliverable 3.10 is verified this way: record the five surfaces, authorized tests, findings, fixes, and retest outcomes. AxonBuild performs this targeted test. The targeted security tests cover the five priority attack surfaces documented in the report, and the package also includes an OWASP review and a controls checklist with evidence. Formal third-party certifications and independent audit opinions are separate from the sprint deliverables. Legal advice and certification are separate services; the sprint implements and documents the technical data-handling controls. The full list is in the sprint’s published security scope.

Common questions about PCI testing and scans

Can I do PCI compliance myself?

At Stripe’s Levels 3 and 4, mostly yes; at Levels 1 and 2, not on your own. Stripe says its Level 3 and Level 4 users are enrolled in a program that “may include completing one or more PCI DSS Self-Assessment Questionnaires (SAQs)”, and that they “must also complete quarterly network scans by an Approved Scanning Vendor (ASV)”. At Level 2, “merchants completing SAQ A, SAQ A-EP, or SAQ D must engage a QSA for compliance validation”, and Level 1 businesses “are not eligible to use an SAQ to prove PCI compliance”.

Whether a customer also wants a penetration test from you is a separate question, covered in the pen test article linked in the annual testing section.

What is PCI testing?

PCI testing is a loose name for the checks in Requirement 11 that test how card data is protected: vulnerability scans inside the network and from outside by an approved vendor, a penetration test of the systems around card data, and, where a network is split to keep card data apart, a test that the split holds. Who runs each and how often is in the compliance testing table above.

How often is PCI DSS compliance required?

All year, with a yearly attestation. Stripe tells merchants they must accept payments “in a PCI-compliant manner, and annually attest to this compliance”. The testing calendar that sits inside that year is in the cadence table above.

Does FedRAMP use NIST 800-53?

Yes. FedRAMP’s 2026 control reference lists every active control in NIST SP 800-53 Revision 5 and marks which FedRAMP Rev5 baselines each one applies to.