PCI DSS v4.0.1 Penetration Testing (Requirement 11.4): A Guide for Indian Payment Aggregators, Fintechs and E-commerce
PCI DSS v4.0.1 Requirement 11.4 explained for Indian payment aggregators, fintechs and e-commerce: who can test, how often, segmentation and RBI rules.
PCI DSS v4.0.1 Penetration Testing (Requirement 11.4): A Guide for Indian Payment Aggregators, Fintechs and E-commerce
PCI DSS v4.0.1 Requirement 11.4 explained for Indian payment aggregators, fintechs and e-commerce: who can test, how often, segmentation and RBI rules.
PCI DSS v4.0.1 Requirement 11.4 asks any business in scope to run an internal and an external penetration test at least once every 12 months, and again after any significant infrastructure or application change. The tester must be qualified and organisationally independent, but does not need to be a QSA or an ASV. Every exploitable finding must be fixed and then tested again to prove the fix works.
In India, RBI adds its own layer for payment aggregators. That is where most confusion starts, so let us clear it up first.
Four different checks, four different jobs
Indian fintech teams often use "PCI audit", "VAPT" and "security audit" as if they mean the same thing. They do not. Here are the four checks a payment business may face, and who is allowed to do each one.
| Check | What it is | Who can do it |
|---|---|---|
| PCI DSS assessment (ROC or SAQ) | Checks compliance with all 12 PCI DSS requirements | QSA for a Report on Compliance; self-assessment where your acquirer allows an SAQ |
| ASV scan (Req. 11.3.2) | Quarterly external vulnerability scan | PCI-approved scanning vendor (ASV) |
| Penetration test (Req. 11.4) | Hands-on attempt to break in and prove impact | Qualified, independent tester; QSA or ASV not required |
| RBI annual system audit (payment aggregators, para 9(d)) | Annual system audit, including cyber security audit, sent to RBI | CERT-In empanelled auditors |
The penetration test is the one people most often buy from the wrong place, or skip because they think the QSA covers it. A QSA checks that you did a pentest. The QSA does not usually do it for you.
Requirement 11.4 decoded, line by line
Here is what each part of 11.4 asks for, in plain English.
11.4.1 Methodology
You need a defined, documented and implemented testing method. It must include both application-layer and network-layer testing. A scanner report alone does not meet this.
11.4.2 Internal test
Test from inside your network at least every 12 months and after significant changes, following your methodology.
11.4.3 External test
Same rhythm, from the internet side. Passing one does not cover the other.
11.4.4 Fix and retest
Correct exploitable findings based on the risk they pose, then repeat the testing to verify the corrections. No retest, no evidence.
11.4.5 Segmentation testing
If you use segmentation to keep systems out of PCI scope, test that the segmentation actually works.
11.4.6 Segmentation for service providers
Service providers must test segmentation at least every six months and after changes to segmentation controls.
11.4.7 Multi-tenant service providers
If you host several customers on shared infrastructure, you must support your customers' external penetration testing.
SecurityLit's VAPT covers the two layers 11.4.1 asks for: network testing, internal and external, with lateral movement and privilege escalation checks, and web application testing including APIs.
What applies to you in India
Payment aggregators
RBI's Payment Aggregator Directions, 2025 ask aggregators to implement data security standards such as PCI DSS and to make sure merchant infrastructure is PCI DSS compliant where applicable. The baseline technology controls in Annex 1, which are mandatory for aggregators, also ask for bi-annual VAPT reports and your PCI DSS Attestation of Compliance and Report on Compliance to go to the IT Committee. On top of that, the annual system audit must be done by CERT-In empanelled auditors. So an aggregator usually needs all four checks in the table above.
Fintechs that handle card data for others
If you store, process or transmit card data on behalf of other businesses, you are likely a service provider under PCI DSS. That means the six-monthly segmentation test in 11.4.6 applies to you, not only the yearly pentest. If you run shared infrastructure, 11.4.7 applies too.
E-commerce merchants
RBI's baseline controls say card credentials must not be stored in the database or server accessed by the merchant. Many Indian merchants use a payment aggregator's hosted checkout and tokenisation, which can shrink their PCI scope a lot. Your acquirer or QSA decides which validation path you follow. If anything in your environment still touches card data, 11.4 applies to that part.
Payment gateways
RBI's Directions do not cover payment gateways that only provide technology without handling funds, but they encourage gateways to adopt the same baseline controls.
This is general information, not legal advice. Confirm your category with your acquirer, QSA or legal team.
The step most teams miss: "significant change"
The yearly test is easy to diarise. The harder rule is testing after any significant infrastructure or application upgrade or change. A new payment flow, a move to a new cloud account, or a rebuilt checkout all count.
Fast-moving fintech teams rarely ship once a year. If you release every sprint, continuous pentesting lets testing follow your releases, with retesting on fixes built in.
If your cardholder data environment runs in the cloud, check the cloud setup itself as well. Misconfigured storage, keys and network rules can break segmentation without anyone noticing. Learn more about cloud security assessments.
Example: one year of testing for an Indian payment aggregator
Here is how the pieces can fit together for an aggregator that is also a PCI DSS service provider. It is an illustration, not a prescribed plan.
Internal and external penetration test under 11.4.2 and 11.4.3, plus segmentation testing under 11.4.6.
Fix findings and retest under 11.4.4.
VAPT report for the IT Committee, the first of two that year under RBI's baseline controls.
Second segmentation test, because service providers test every six months.
Annual system and cyber security audit by a CERT-In empanelled auditor.
Second VAPT report for the IT Committee.
A new checkout flow or infrastructure move goes live, so the affected systems are tested again.
What a PCI-ready pentest report should contain
Your QSA or acquirer will look for evidence, not a certificate. Before you accept a report, check that it shows:
- The methodology used, matching the 11.4.1 elements
- The scope: which systems, networks and applications were tested, internal and external
- Who tested, their qualifications, and why they are independent of the team running the systems
- Each finding with its risk rating and proof of impact
- Retest results showing which fixes were verified
- Segmentation test results, if you rely on segmentation
SecurityLit reports include a risk-based ranking of findings, remediation timelines and retest validation planning, with an executive summary for leadership and technical detail for engineers.
Getting ready before the assessor arrives
If your PCI assessment is a few months away, a gap check first is cheaper than failing later. SecurityLit's compliance pre-assessment can show where your controls stand against PCI DSS before the formal assessment.
Then plan the order: gap check, fixes, pentest, retest, and only then the QSA assessment. Testing after fixes means your report shows a clean retest instead of a long list of open issues.
Frequently Asked Questions
Q1. Does a PCI DSS penetration test have to be done by a QSA?
No. Requirements 11.4.2 and 11.4.3 say the tester must be a qualified internal resource or qualified external third party with organisational independence, and state that a QSA or ASV is not required.
Q2. How often is PCI DSS penetration testing required?
At least once every 12 months for both internal and external testing, and after any significant infrastructure or application upgrade or change. Service providers must also test segmentation at least every six months.
Q3. Is an ASV scan the same as a penetration test?
No. An ASV scan is a quarterly automated external scan under Requirement 11.3.2. A penetration test under 11.4 is a hands-on attempt to exploit weaknesses at both the network and application layers.
Q4. Do Indian payment aggregators need a CERT-In empanelled auditor?
For the annual system audit, including the cyber security audit, yes. RBI's Payment Aggregator Directions, 2025 require it to be done by CERT-In empanelled auditors. That requirement is separate from the PCI DSS penetration test.
Q5. Does tokenisation remove PCI DSS for an e-commerce merchant?
It can reduce scope a lot, because the merchant no longer stores card numbers. It does not remove every obligation. Your acquirer or QSA decides what still applies.
Need a PCI DSS 11.4 penetration test with a retest built in?
Book a free scoping call with SecurityLit or get an instant estimate for your network and applications.
PCI DSS v4.0.1 Requirement 11.4 asks any business in scope to run an internal and an external penetration test at least once every 12 months, and again after any significant infrastructure or application change. The tester must be qualified and organisationally independent, but does not need to be a QSA or an ASV. Every exploitable finding must be fixed and then tested again to prove the fix works.
In India, RBI adds its own layer for payment aggregators. That is where most confusion starts, so let us clear it up first.
Four different checks, four different jobs
Indian fintech teams often use "PCI audit", "VAPT" and "security audit" as if they mean the same thing. They do not. Here are the four checks a payment business may face, and who is allowed to do each one.
| Check | What it is | Who can do it |
|---|---|---|
| PCI DSS assessment (ROC or SAQ) | Checks compliance with all 12 PCI DSS requirements | QSA for a Report on Compliance; self-assessment where your acquirer allows an SAQ |
| ASV scan (Req. 11.3.2) | Quarterly external vulnerability scan | PCI-approved scanning vendor (ASV) |
| Penetration test (Req. 11.4) | Hands-on attempt to break in and prove impact | Qualified, independent tester; QSA or ASV not required |
| RBI annual system audit (payment aggregators, para 9(d)) | Annual system audit, including cyber security audit, sent to RBI | CERT-In empanelled auditors |
The penetration test is the one people most often buy from the wrong place, or skip because they think the QSA covers it. A QSA checks that you did a pentest. The QSA does not usually do it for you.
Requirement 11.4 decoded, line by line
Here is what each part of 11.4 asks for, in plain English.
11.4.1 Methodology
You need a defined, documented and implemented testing method. It must include both application-layer and network-layer testing. A scanner report alone does not meet this.
11.4.2 Internal test
Test from inside your network at least every 12 months and after significant changes, following your methodology.
11.4.3 External test
Same rhythm, from the internet side. Passing one does not cover the other.
11.4.4 Fix and retest
Correct exploitable findings based on the risk they pose, then repeat the testing to verify the corrections. No retest, no evidence.
11.4.5 Segmentation testing
If you use segmentation to keep systems out of PCI scope, test that the segmentation actually works.
11.4.6 Segmentation for service providers
Service providers must test segmentation at least every six months and after changes to segmentation controls.
11.4.7 Multi-tenant service providers
If you host several customers on shared infrastructure, you must support your customers' external penetration testing.
SecurityLit's VAPT covers the two layers 11.4.1 asks for: network testing, internal and external, with lateral movement and privilege escalation checks, and web application testing including APIs.
What applies to you in India
Payment aggregators
RBI's Payment Aggregator Directions, 2025 ask aggregators to implement data security standards such as PCI DSS and to make sure merchant infrastructure is PCI DSS compliant where applicable. The baseline technology controls in Annex 1, which are mandatory for aggregators, also ask for bi-annual VAPT reports and your PCI DSS Attestation of Compliance and Report on Compliance to go to the IT Committee. On top of that, the annual system audit must be done by CERT-In empanelled auditors. So an aggregator usually needs all four checks in the table above.
Fintechs that handle card data for others
If you store, process or transmit card data on behalf of other businesses, you are likely a service provider under PCI DSS. That means the six-monthly segmentation test in 11.4.6 applies to you, not only the yearly pentest. If you run shared infrastructure, 11.4.7 applies too.
E-commerce merchants
RBI's baseline controls say card credentials must not be stored in the database or server accessed by the merchant. Many Indian merchants use a payment aggregator's hosted checkout and tokenisation, which can shrink their PCI scope a lot. Your acquirer or QSA decides which validation path you follow. If anything in your environment still touches card data, 11.4 applies to that part.
Payment gateways
RBI's Directions do not cover payment gateways that only provide technology without handling funds, but they encourage gateways to adopt the same baseline controls.
This is general information, not legal advice. Confirm your category with your acquirer, QSA or legal team.
The step most teams miss: "significant change"
The yearly test is easy to diarise. The harder rule is testing after any significant infrastructure or application upgrade or change. A new payment flow, a move to a new cloud account, or a rebuilt checkout all count.
Fast-moving fintech teams rarely ship once a year. If you release every sprint, continuous pentesting lets testing follow your releases, with retesting on fixes built in.
If your cardholder data environment runs in the cloud, check the cloud setup itself as well. Misconfigured storage, keys and network rules can break segmentation without anyone noticing. Learn more about cloud security assessments.
Example: one year of testing for an Indian payment aggregator
Here is how the pieces can fit together for an aggregator that is also a PCI DSS service provider. It is an illustration, not a prescribed plan.
Internal and external penetration test under 11.4.2 and 11.4.3, plus segmentation testing under 11.4.6.
Fix findings and retest under 11.4.4.
VAPT report for the IT Committee, the first of two that year under RBI's baseline controls.
Second segmentation test, because service providers test every six months.
Annual system and cyber security audit by a CERT-In empanelled auditor.
Second VAPT report for the IT Committee.
A new checkout flow or infrastructure move goes live, so the affected systems are tested again.
What a PCI-ready pentest report should contain
Your QSA or acquirer will look for evidence, not a certificate. Before you accept a report, check that it shows:
- The methodology used, matching the 11.4.1 elements
- The scope: which systems, networks and applications were tested, internal and external
- Who tested, their qualifications, and why they are independent of the team running the systems
- Each finding with its risk rating and proof of impact
- Retest results showing which fixes were verified
- Segmentation test results, if you rely on segmentation
SecurityLit reports include a risk-based ranking of findings, remediation timelines and retest validation planning, with an executive summary for leadership and technical detail for engineers.
Getting ready before the assessor arrives
If your PCI assessment is a few months away, a gap check first is cheaper than failing later. SecurityLit's compliance pre-assessment can show where your controls stand against PCI DSS before the formal assessment.
Then plan the order: gap check, fixes, pentest, retest, and only then the QSA assessment. Testing after fixes means your report shows a clean retest instead of a long list of open issues.
Frequently Asked Questions
Q1. Does a PCI DSS penetration test have to be done by a QSA?
No. Requirements 11.4.2 and 11.4.3 say the tester must be a qualified internal resource or qualified external third party with organisational independence, and state that a QSA or ASV is not required.
Q2. How often is PCI DSS penetration testing required?
At least once every 12 months for both internal and external testing, and after any significant infrastructure or application upgrade or change. Service providers must also test segmentation at least every six months.
Q3. Is an ASV scan the same as a penetration test?
No. An ASV scan is a quarterly automated external scan under Requirement 11.3.2. A penetration test under 11.4 is a hands-on attempt to exploit weaknesses at both the network and application layers.
Q4. Do Indian payment aggregators need a CERT-In empanelled auditor?
For the annual system audit, including the cyber security audit, yes. RBI's Payment Aggregator Directions, 2025 require it to be done by CERT-In empanelled auditors. That requirement is separate from the PCI DSS penetration test.
Q5. Does tokenisation remove PCI DSS for an e-commerce merchant?
It can reduce scope a lot, because the merchant no longer stores card numbers. It does not remove every obligation. Your acquirer or QSA decides what still applies.
Need a PCI DSS 11.4 penetration test with a retest built in?
Book a free scoping call with SecurityLit or get an instant estimate for your network and applications.