PCI DSS v4.0.1 puts penetration testing at Requirement 11.4 and vulnerability scanning at Requirement 11.3, and the two carry different intervals, different testers and different outputs. Internal testing at 11.4.2 and external testing at 11.4.3 are each performed per the entity’s defined methodology, at least once every 12 months, and after any significant infrastructure or application upgrade or change. Every clause below is quoted with the page it sits on and the date it was read.
The clauses
Read from PCI DSS Requirements and Testing Procedures v4.0.1, dated June 2024. Each row quotes the requirement it names, gives the page it sits on in that document, and carries the date the text was read.
| Requirement | What it says |
|---|---|
| 11.4.1 — Penetration testing methodology | The clause that decides what a test has to contain: “A penetration testing methodology is defined, documented, and implemented by the entity, and includes: Industry-accepted penetration testing approaches. Coverage for the entire CDE perimeter and critical systems. Testing from both inside and outside the network. Testing to validate any segmentation and scope-reduction controls. Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4. Network-layer penetration tests that encompass all components that support network functions as well as operating systems. Review and consideration of threats and vulnerabilities experienced in the last 12 months. Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing. Retention of penetration testing results and remediation activities results for at least 12 months.” CDE is the cardholder data environment. |
| v4.0.1, pp. 275–276. Read 2026-09-14. The Further Information column names OSSTMM and OWASP as industry-accepted approaches and refers to the Council’s Information Supplement on penetration testing. | |
| 11.4.2 — Internal penetration testing | Performed “Per the entity’s defined methodology”, “At least once every 12 months”, “After any significant infrastructure or application upgrade or change”, and “By a qualified internal resource or qualified external third-party”. The clause adds a fifth condition on the tester: organisational independence. |
| v4.0.1, p. 276. Read 2026-09-14. Testing procedure 11.4.2.b interviews personnel to establish the tester’s qualification and that independence. | |
| 11.4.3 — External penetration testing | The same five conditions, word for word: the entity’s defined methodology, at least once every 12 months, after any significant infrastructure or application upgrade or change, a qualified internal resource or qualified external third party, and organisational independence of the tester. Internal and external testing differ in where the tester stands, not in what the clause asks of them. |
| v4.0.1, p. 277. Read 2026-09-14. Its Guidance column points to the Information Supplement: Penetration Testing Guidance. | |
| 11.4.5 — Segmentation controls | “If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: At least once every 12 months and after any changes to segmentation controls/methods”, by a qualified internal resource or qualified external third party, with organisational independence of the tester. This is the clause that tests whether the boundary you scoped your assessment around is the boundary that exists. |
| v4.0.1, p. 278. Read 2026-09-14. | |
| 11.4.6 — Segmentation, service providers | Printed under the heading “Additional requirement for service providers only”, and setting the same control at “At least once every six months and after any changes to segmentation controls/methods.” The six-month interval travels with that heading, and whether your entity is assessed as a service provider is settled in your assessment. |
| v4.0.1, p. 279. Read 2026-09-14. | |
| 6.2.3 — Bespoke and custom software, before release | “Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities”, with code reviews ensuring code is developed according to secure coding guidelines, looking for both existing and emerging software vulnerabilities, and appropriate corrections implemented prior to release. Its Applicability Notes add that reviews “may be performed using either manual or automated processes, or a combination of both.” |
| v4.0.1, p. 139. Read 2026-09-14. Requirement 6.2.3.1 sets the reviewer-other-than-author and management-approval controls, and applies where manual code reviews are performed. | |
11.4.1 — Penetration testing methodology
v4.0.1, pp. 275–276. Read 2026-09-14. The Further Information column names OSSTMM and OWASP as industry-accepted approaches and refers to the Council’s Information Supplement on penetration testing.
11.4.2 — Internal penetration testing
v4.0.1, p. 276. Read 2026-09-14. Testing procedure 11.4.2.b interviews personnel to establish the tester’s qualification and that independence.
11.4.3 — External penetration testing
v4.0.1, p. 277. Read 2026-09-14. Its Guidance column points to the Information Supplement: Penetration Testing Guidance.
11.4.5 — Segmentation controls
v4.0.1, p. 278. Read 2026-09-14.
11.4.6 — Segmentation, service providers
v4.0.1, p. 279. Read 2026-09-14.
6.2.3 — Bespoke and custom software, before release
v4.0.1, p. 139. Read 2026-09-14. Requirement 6.2.3.1 sets the reviewer-other-than-author and management-approval controls, and applies where manual code reviews are performed.
Two clocks
Three exercises, three different answers to who performs it and how often. Reading one onto another is the easiest mistake to make against this part of the standard, and it changes both what you buy and what you file.
How these citations were read
Deliberately excluded
Against the methodology
11.4.1 is the clause an assessor holds a test against, element by element. Each card names the element and stops where the engagement stops.
11.4.1 asks for coverage of the entire cardholder data environment perimeter and critical systems, tested from both inside and outside the network. What that means for your estate is settled in the scope agreement, signed before anything runs and retained with the engagement.
The methodology has to include testing that validates any segmentation and scope-reduction controls, and 11.4.5 sets when. Where a route out of a segment exists, it is reported as a finding with the path recorded step by step — which is the form the answer has to take, since the claim being tested is about reachability.
Application-layer testing under 11.4.1 identifies at least the vulnerabilities listed at Requirement 6.2.4. Each finding carries the request and response that proved it, a CVSS v4.0 vector printed in full, and the CWE, so the classification can be argued with rather than accepted.
Network-layer tests under 11.4.1 encompass all components that support network functions as well as operating systems. Coverage is identical across the three delivery models; the eleven coverage classes do not change between them.
11.4.1 asks for review and consideration of threats and vulnerabilities experienced in the last 12 months. Prior findings, their retest outcomes and what has been seen in your environment are taken into the scoping conversation rather than left for a run to rediscover.
The last element of 11.4.1 is retention of penetration testing results and remediation activities results for at least 12 months. Each finding carries its state through open, fixed, retested and closed, and the record of both halves is issued to you.
Requirement 6.2.3
6.2.3 sits in the software development lifecycle rather than in the testing requirement: bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, with appropriate corrections implemented before release. Its Applicability Notes say the reviews may be performed using either manual or automated processes, or a combination of both, and Requirement 6.2.3.1 sets the reviewer-independence and management-approval controls that apply where manual code reviews are performed. The review process is the entity’s to define, run and evidence, and an assessor examines it as a process. What an engagement adds to that process is a test of the built application before it ships: every finding arrives with the exchange that produced it, a CWE, and steps written so the engineer who owns the code can reproduce it and then close it against a retest. Findings are mapped to the requirement they bear on and the requirement is named on the finding, which is what makes the mapping something your assessor can check rather than take on trust. The assessment against 6.2.3 itself is theirs to make.
Who the tester is
All three cover the same eleven classes and produce the same evidence per finding. The clause asks two things about the person doing the testing — that they are qualified, and that organisational independence exists — and that is what separates the models.
| State | What it means | What follows |
|---|---|---|
| Autonomous, expert verified | A senior Security Brigade auditor verifies every finding before any of it reaches you, and is named on the engagement record. Security Brigade has been CERT-In empanelled since 2008 and is ISO 27001 certified. | A named qualified tester, independent of the entity being tested, stands behind every finding in the report. |
| Human led | A senior auditor runs the engagement with B-52 underneath: sets the scope against 11.4.1, directs where the depth goes, and owns the report that comes out of it. | The same named qualified tester, with the methodology argued rather than applied — which is what an unusual cardholder data environment tends to need. |
| Fully autonomous Terminal | A person authorises scope and targets and the run proceeds without one. The coverage and the per-finding evidence are the same; there is no auditor inside the engagement to be named on it. | Built for coverage in the months between the engagements you file against. |
Council guidance
The Council’s Information Supplement: Penetration Testing Guidance, v1.1 of September 2017, opens its engagement section with this: “Penetration testing is essentially a manual endeavor. In many cases, tools exist that can aid the tester in performing the test and alleviate some of the repetitive tasks. Judgment is required in selecting the appropriate tools and in identifying attack vectors that typically cannot be identified through automated means.” Read it for exactly what it is. That document was written against the numbering in force in 2017, where the testing requirement sits at 11.3, and its footer states on every page that it supplements rather than replaces or supersedes requirements in any Council standard. It is guidance from the body that writes the standard, nine years old, and it is describing tools as aids to a tester rather than as a substitute for one. That is the same direction 11.4.2 points: the requirement attaches to a qualified, independent tester working to a documented methodology. So where the output of an engagement is going to an assessor, the expert-verified model is the place to start — a senior auditor has been through every finding in it and is named on the report. The fully autonomous model is priced at a $500 entry tier for one scan of one application or target, and what it is for is the coverage in between.
What the report carries
Written for somebody who was not in the room and who is comparing what you say you tested against what 11.4.1 obliged you to cover.
The request as sent and the response as returned, with the portion demonstrating the defect marked, and steps written so your own engineer reproduces it without us present.
CVSS v4.0 with the vector string printed so the score can be recomputed rather than accepted, the CWE, and the requirement the finding is reported against.
What was in scope, who authorised it, when testing ran, and what the three approval gates permitted or refused: destructive or state-changing actions; persistence and movement past the entry host; and live credentials or real customer data. On a cardholder data environment, the third gate is the one asked about first.
In the expert-verified and human-led models the report names the senior Security Brigade auditor who stood behind it and is signed by the firm. The instruments Security Brigade holds are its CERT-In empanelment, since 2008, and its ISO 27001 certification.
Retention
The last element of the methodology clause asks for retention of results and of remediation activities results for at least 12 months. That is a record with two halves, and the second is the one usually missing when an assessment starts.
The finding is raised with its artefact — request, response and reproduction steps — its CVSS v4.0 vector, its CWE, and the requirement it is reported against. This is the results half of what 11.4.1 asks you to retain.
Your engineer marks the finding fixed against a change they can point to. The state moves and the original artefact does not change, so the record still shows what was true when it was found.
The same reproduction is run again against the same target, by the same route that worked the first time.
A finding closes on a retest that cannot reproduce it. The retest and its outcome sit beside the original artefact, and together they are the remediation activities half of the record.
Both halves stay with the engagement, so the twelve-month retention is a record of what was found and what was done about it rather than a report filed beside a fix asserted.
The boundary
A PCI page is where a testing vendor is most tempted to describe its own programme as the standard’s. These are the five places this one stops instead.
| The position | |
|---|---|
| Mapping, not issuing | Findings are mapped to the requirements the standard names, and the requirement is printed on the finding. A Report on Compliance and an Attestation of Compliance are produced by a Qualified Security Assessor engaged for that purpose, and a self-assessment questionnaire is completed by the entity. Testing is an input to those. It is separate work from them. |
| What an engagement produces | The purpose text at 11.4.2 puts it plainly: “A penetration test is not truly a ‘test’ because the outcome of a penetration test is not something that can be classified as a ‘pass’ or a ‘fail.’” What comes out of one is findings, the evidence for each, severity with its vector, and a remediation record that ends in a retest. The same passage adds that a test finding nothing is typically indicative of shortcomings of the penetration tester. |
| v4.0.1, p. 276. Read 2026-09-14. | |
| Whose instruments these are | Security Brigade holds a CERT-In empanelment, since 2008, and ISO 27001 certification. Those are the two instruments this site claims, and both are the firm’s. The B-52 platform holds none of its own, and a tester’s certifications are listed as what they are: qualifications held by the individual doing the work. |
| Each interval with its own clause | Every cadence on this page is attached to the requirement it comes from: three months at 11.3.1 and 11.3.2, twelve months at 11.4.2, 11.4.3 and 11.4.5, six months at 11.4.6 under its service-provider heading, and twelve months of retention at 11.4.1. Where a figure appears without its clause number on any page, that is the point to go back to the standard. |
| Version, page and date | Everything cited here is PCI DSS v4.0.1 of June 2024, read on 14 September 2026, with a page number given per clause and the provenance of the copy stated above. Where the Council issues a later version, this page is restated against it and the date moves. |
Mapping, not issuing
What an engagement produces
v4.0.1, p. 276. Read 2026-09-14.
Whose instruments these are
Each interval with its own clause
Version, page and date
Adjacent obligations
A payments business assessed under PCI DSS is often the same entity carrying an Indian obligation on a different clock — a payment aggregator or payment gateway under the PA-PG Master Direction, which requires an annual system and cybersecurity audit by a CERT-In empanelled auditor, or an entity filing the System Audit Report under the 2018 directive on storage of payment system data, which requires the same empanelled delivery. Where that describes you, the CERT-In page alongside this one sets out which instrument carries the requirement and why empanelled delivery attaches to the testing rather than to the invoice. It is one scoping conversation either way: the same targets, the same eleven coverage classes, and a report written to be read by both audiences without being written twice.
Where the report goes to an assessor, start from the expert-verified model. A scoping call settles what sits inside the cardholder data environment, which segmentation controls have to be tested, and what the engagement has to produce against 11.4.1.