PCI DSS penetration testing for requirement 11.4
PCI DSS 4.x requires penetration testing: requirement 11.4 asks for internal and external tests at least once every 12 months and after significant changes, plus segmentation tests where segmentation narrows your scope. BERRY9 runs that test by hand from Hyderabad and reports each finding with a proof of concept, a CVSS 3.1 score and its fix, while the quarterly ASV scans and the assessment itself are done by others and your assessor decides what evidence is enough.
- Tests start from
- INR 27,000 + 18% GST
- Covers
- Internal, external, segmentation
- Severity
- CVSS 3.1 per finding
- Delivery
- Remote from Hyderabad
Last reviewed
BERRY9: the penetration test under requirement 11.4, internal, external and segmentation, reported finding by finding.
An Approved Scanning Vendor: the quarterly external vulnerability scans of requirement 11.3.2. BERRY9 is not an ASV.
A QSA or your own self-assessment: the assessment itself and the compliance report. BERRY9 is not a QSA.
01 / What PCI DSS asks
What PCI DSS requirement 11.4 asks for
PCI DSS is the card industry's security standard, maintained by the PCI Security Standards Council, and requirement 11.4 is where it sets out penetration testing. Unlike many frameworks it makes the test a stated requirement, so the questions are what the test must cover, how often, and who may run it.
11.4.1 A written method
Your organization defines, documents and follows a penetration testing methodology. It covers the whole perimeter of the cardholder data environment and its critical systems, testing from inside and outside the network, application-layer and network-layer tests, and checks on any segmentation used to reduce scope.
11.4.2 and 11.4.3 Inside and outside
Internal and external penetration tests are each due at least once every 12 months and after any significant infrastructure or application upgrade or change.
11.4.4 Fix, then test again
Exploitable vulnerabilities and security weaknesses the test finds are corrected according to your own risk ranking, and penetration testing is repeated to verify the corrections.
11.4.5 Segmentation that holds
If segmentation keeps the cardholder data environment apart from other networks, the segmentation controls are tested at least once every 12 months and after any change to them, to confirm they work and isolate the environment from every out-of-scope system.
11.4.6 Service providers
Service providers that rely on segmentation test those controls more often: at least once every six months, and after any change to them.
11.4.7 Multi-tenant providers
Multi-tenant service providers, such as shared hosting providers, support their customers in carrying out external penetration testing.
On the tester, requirements 11.4.2, 11.4.3, 11.4.5 and 11.4.6 ask for a qualified internal resource or a qualified external third party with organizational independence, and they state that the tester does not have to be a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV). Whether a tester counts as qualified is for your assessor to judge.
Requirement numbers follow PCI DSS v4.0.1, the June 2024 revision of PCI DSS 4.0. Ask your assessor which version and testing procedures they work from.
02 / Requirement to report
What a PCI penetration test report gives your assessor
Each part of requirement 11.4 leaves a trace your assessor looks for. The map pairs those parts with the section of a BERRY9 report that speaks to them, so you can see before testing what the report will and will not contain.
| Requirement area | What the requirement asks for | What the BERRY9 report supplies |
|---|---|---|
| 11.4.1 Methodology | A documented method that covers the perimeter of the cardholder data environment (CDE), critical systems, both network and application layers, and testing from inside and outside | The agreed scope and the five-phase method, written into the report so your assessor can set it beside your own methodology |
| 11.4.2 Internal testing | A test from inside the network at least once every 12 months and after significant change | Internal findings, each with reproduction steps, a proof of concept and a CVSS 3.1 severity |
| 11.4.3 External testing | A test of the perimeter from outside at least once every 12 months and after significant change | External findings in the same form, with the addresses, hosts and applications tested set out in the scope |
| 11.4.4 Correction and retesting | Exploitable issues corrected by risk, and the test repeated to verify each correction | A remediation matrix your team updates as fixes land, and retest results on the terms in your proposal |
| 11.4.5 and 11.4.6 Segmentation | Proof that segmentation controls work and keep the CDE apart from out-of-scope systems | For each boundary tested, which zones could reach which, backed by a topology diagram |
The table is a planning aid. It does not mean a report satisfies a requirement; your assessor reaches that view against the testing procedures of the version they assess you on.
03 / Scoping
Scoping the cardholder data environment and segmentation
The cardholder data environment covers the systems that store, process or transmit cardholder data or sensitive authentication data, and the scope extends to systems that connect to it or can affect its security. Segmentation is not a PCI DSS requirement, but it can shrink that scope, which is why PCI DSS asks you to prove it works.
Show details for Scoping the cardholder data environment and segmentation
- Where card data travels. Where card numbers enter, which systems store, process or transmit them, and which parts a payment processor or tokenization service handles for you.
- The boundary of the environment. The systems inside the cardholder data environment, and the ones connected to it or able to affect its security, which belong in scope too.
- Every segmentation control. Firewalls, VLANs, access lists and cloud security groups that keep the environment apart from the rest of the network, so each one is tested.
- Payment-facing applications and APIs. Checkout and payment pages, admin consoles and the interfaces that touch card data, for the application-layer part of the test.
- Merchant or service provider. Which one your assessor treats you as, because service providers that segment owe the six-monthly segmentation test.
- Changes since the last test. New infrastructure, upgrades or application releases, and the previous report, so earlier findings are checked again.
What a segmentation test looks for:
From outside, nothing gets in
From each out-of-scope zone, the test tries to reach systems inside the cardholder data environment on any port or protocol your rules do not explicitly allow.
Every method in use
Each kind of control that separates the environment is tried, from on-premises firewalls to cloud security groups and the links between them.
A result per boundary
The report states, boundary by boundary, which zones could reach which, with a topology diagram of what was tested.
04 / Test types
Which tests cover a PCI DSS scope
Requirement 11.4.1 asks for both network-layer and application-layer testing, so a PCI DSS engagement usually combines a network test with tests of the applications and APIs that handle card data. Each links to its own page.
Show details for Which tests cover a PCI DSS scope
Network: internal and external
The network-layer half of 11.4: the internet-facing perimeter, the internal network and the segmentation between zones, tested in one engagement or as separate ones.
Web applications and payment pages
The application-layer half: checkout flows, payment pages and admin consoles, tested for the attack classes listed in requirement 6.2.4, such as injection and broken access control.
Payment and tokenization APIs
The interfaces that create payments, return card tokens or move settlement data, tried under each role and partner key you give us.
SOC 2 alongside PCI DSS
SOC 2 does not require a penetration test. Its criteria ask for controls that find and manage vulnerabilities, penetration testing is one common way to show that, and your auditor decides what evidence is enough. One test can serve both programs if the scope covers what each assessor expects.
ISO 27001 alongside PCI DSS
ISO/IEC 27001 expects technical vulnerabilities to be managed (Annex A 8.8), so a PCI DSS test of the same systems can also feed your ISO program.
Every other test we run
Mobile apps that take payments, cloud accounts that host the environment, Active Directory behind the back office: the full list sits on one page.
Our VAPT methodology page describes the five phases every engagement goes through; to see how findings are presented for an assessor, open the sample VAPT report.
05 / What you receive
What you get from a PCI DSS penetration test
Every BERRY9 test includes five of the items listed here; one is still to be confirmed. Your engineers use them to fix what was found, and your assessor uses them to see that it was found, fixed and checked again.
Show details for What you get from a PCI DSS penetration test
- An executive report that sets out the scope, what was found and what it means for the business, for management and for your assessor.
- An engineering report giving each finding its reproduction steps, a proof of concept and the fix.
- CVSS 3.1 severity scored for your environment, which feeds the risk ranking that requirement 11.4.4 corrects against.
- A remediation matrix with every finding beside its fix, kept up to date by your team until the last item closes.
- Retest terms, stated with the price further down.
BERRY9 is not a PCI Qualified Security Assessor and not an Approved Scanning Vendor. We do not run ASV scans, sign a Report on Compliance or issue an Attestation of Compliance, and no test report can promise a compliant result: that view is your assessor's.
06 / Who it fits
Who PCI DSS testing from BERRY9 fits
PCI DSS reaches any business that stores, processes or transmits card data, or can affect the security of the systems that do. The four groups below are the usual buyers of a PCI DSS test; the callout after them names the cases where another kind of firm is the right call.
Show details for Who PCI DSS testing from BERRY9 fits
Merchants
Online stores and businesses that take cards in person, whose acquiring bank or the card brands ask for PCI DSS, and whose own systems still touch card data.
Payment aggregators and gateways
Firms that onboard merchants and route their payments, where the cardholder data environment is the core of the business and segmentation often carries the scope.
Fintech companies
Lending, wallet and card-program teams whose platforms store, process or transmit card data, or connect to the systems that do.
SaaS handling card data
Billing, booking and subscription platforms that handle cards for their customers; many are treated as service providers, which brings the six-monthly segmentation test.
Not a fit: if you need a CERT-In empanelled auditor, ASV scans or a QSA. Those jobs need another firm: quarterly ASV scans, an assessment by a QSA, and any audit a regulator requires from a CERT-In empanelled auditor. BERRY9 is not CERT-In empanelled, and says so before any money changes hands.
PCI DSS testing is delivered remotely from our one office in Hyderabad for teams anywhere in India; on-site work, for systems that cannot be reached remotely, is by arrangement.
07 / Price
What a PCI DSS penetration test costs
A PCI DSS penetration test with BERRY9 starts from INR 27,000 + 18% GST. A large environment with many segments costs more than a small one, and your figure is set in a written proposal after scoping, once the hosts, boundaries and applications are known.
PCI DSS penetration test
Starts fromINR 27,000 + 18% GST
Starting price for a manual test of the networks, applications and APIs in your cardholder data environment. Hosts, segments, applications and roles in scope set the final figure.
- Internal, external and segmentation testing
- Proof of concept and CVSS 3.1 per finding
- Executive and engineering reports
What moves the figure
Priced byScope
Three things decide what a PCI DSS test costs:
- Size of the cardholder data environment
- Number of segmentation boundaries
- Payment applications and APIs in scope
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
How each factor moves the price is explained in our VAPT cost guide for India.
08 / Inquiry
Send us your PCI DSS scope and assessment dates
Tell us roughly what sits in your cardholder data environment, whether segmentation is used, whether you are a merchant or a service provider, when your assessment falls and what your assessor has asked for. The written proposal then sets out the scope and timeline.
To talk it through first, call +91 86868 92922 or write to contact@berry9.com.
09 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
Does PCI DSS require penetration testing?
Yes. PCI DSS 4.x requirement 11.4 calls for internal and external penetration testing at least once every 12 months and after any significant change, correction and retesting of what is found, and segmentation testing where segmentation is used to reduce scope. Some self-assessment questionnaires for merchants that fully outsource card handling leave 11.4 out, so confirm with your acquirer or assessor which requirements apply to you. See the section on What PCI DSS requirement 11.4 asks for above.
How often is PCI DSS penetration testing required?
Internal and external tests are due at least once every 12 months and after any significant infrastructure or application upgrade or change. Segmentation tests follow the same 12-month cycle for merchants; service providers that use segmentation test it at least once every six months. Any change to segmentation controls brings a new test. See the section on What PCI DSS requirement 11.4 asks for above.
Does a PCI penetration tester have to be a QSA or an ASV?
No. The standard asks for a qualified internal resource or a qualified external third party with organizational independence, and says the tester does not have to be a QSA or an ASV. BERRY9 is neither. Your assessor judges whether a tester is qualified, so ask them before you book.
Is a PCI penetration test the same as an ASV scan?
No. ASV scans, under requirement 11.3.2, are external vulnerability scans run at least once every three months by an Approved Scanning Vendor listed by the PCI Security Standards Council. A penetration test, under requirement 11.4, is a manual attempt to exploit weaknesses, inside and outside the network. Many organizations need both, depending on how they validate compliance, and BERRY9 provides only the penetration test.
Will your report make us PCI DSS compliant?
No single report can. BERRY9 is not a QSA and does not issue a Report on Compliance or an Attestation of Compliance. Our penetration test report is evidence for requirement 11.4; whether you comply is decided in your assessment, by a QSA, an internal security assessor where your acquirer allows it, or through your self-assessment questionnaire. See the section on What you get from a PCI DSS penetration test above.
What is segmentation testing in PCI DSS?
It is a penetration test of the controls that keep the cardholder data environment apart from the rest of your network. From each out-of-scope zone, the tester tries to reach the environment on any port or protocol your rules do not allow, to confirm the controls work and that out-of-scope systems really are out of scope. See the section on Scoping the cardholder data environment and segmentation above.
What should a PCI penetration test report include?
Your assessor will look for the scope, the method, the findings with their evidence and severity, the corrections and the retest results. A BERRY9 report gives an executive report, an engineering report with a proof of concept and fix per finding, CVSS 3.1 severity and a remediation matrix; segmentation results show, boundary by boundary, which zones could reach which. See the section on What a PCI penetration test report gives your assessor above.
Do payment aggregators in India need a CERT-In empanelled auditor?
Some regulators require one: RBI's directions for payment aggregators, for example, call for PCI DSS and for an annual system and cyber security audit by a CERT-In empanelled auditor. BERRY9 is not CERT-In empanelled. Read the current RBI text with your compliance team, and if your requirement names an empanelled auditor, we tell you before you pay. See the section on Who PCI DSS testing from BERRY9 fits above.
How much does a PCI DSS penetration test cost?
With BERRY9, a PCI DSS penetration test starts from INR 27,000 + 18% GST. The size of the cardholder data environment, the number of segmentation boundaries and the payment applications in scope set the final figure, which comes in a written proposal after scoping; our VAPT cost guide explains each factor. See the section on What a PCI DSS penetration test costs above.
Can you test our cardholder data environment remotely?
Yes. BERRY9 works from a single office in Hyderabad and serves clients anywhere in India remotely. Internal systems and segmentation boundaries are tested through access set up during scoping, such as a VPN account or a jump host, and on-site visits can be arranged where remote access is not possible.