Two clocks: why an RBI-regulated payment aggregator tests twice a year and PCI DSS asks once

If you are an RBI-authorised payment aggregator, the twelve-month figure in PCI DSS is the wrong number to build your testing calendar around. Requirements 11.4.2 and 11.4.3 set a floor of one internal and one external penetration test every twelve months. The Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 ask, at Annexure 1 §1.5, for bi-annual Vulnerability Assessment / Penetration Test reports. Both apply to the same entity, the shorter clock governs, and a payment aggregator that has scoped its programme to the standard alone is under-testing against its own regulator while holding a perfectly valid Attestation of Compliance.

That is the answer. The rest is the text each clock comes from, where the two stop lining up, and the one six-month PCI requirement that looks like it closes the gap and does not.

PCI DSS penetration testing frequency, requirement by requirement

PCI DSS v4.0.1 — the only active version of the standard since v4.0 retired on 31 December 2024 — states the cadence inside the requirement text itself. Requirement 11.4.2 (internal penetration testing) and Requirement 11.4.3 (external penetration testing) carry the same bullets:

• “Per the entity’s defined methodology”
• “At least once every 12 months”
• “After any significant infrastructure or application upgrade or change”
• “By a qualified internal resource or qualified external third party”, with “organizational independence of the tester” — and, in the standard’s own parenthesis, “not required to be a QSA or ASV”

Two things in that list get misread. “At least once every 12 months” is a floor, not a schedule — the customised approach objective for both requirements asks for testing “as frequently as needed to address evolving and new attacks and threats”. And the change trigger is a second, independent obligation: an aggregator that ships a new payment channel in month four owes a test in month four, whatever date sits on the annual one.

The rest of Requirement 11 runs on its own clocks — quarterly scanning at 11.3.1 and 11.3.2, segmentation testing at 11.4.5 and 11.4.6 — and the table below sets them out. None of them substitutes for a penetration test: a quarterly scan does not discharge 11.4.2 or 11.4.3, and the three requirements are not interchangeable in either direction.

What the RBI asks of a payment aggregator

The instrument is the Master Direction on Regulation of Payment Aggregators, RBI/DPSS/2025-26/141, CO.DPSS.POLC.No.S-633/02-14-008/2025-26, dated 15 September 2025, cited in its own text as the Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025. Clause 2 makes them “effective immediately unless indicated otherwise for any specific provision herein”.

Clause 9(b) is the hook. A PA “shall ensure adherence to baseline technology-related recommendations as provided in Annexure 1”. The word recommendations does no softening work here: Annexure 1’s own preamble describes them as “for adoption by the PAs (mandatory) and PGs (recommended)”. For a payment aggregator, Annexure 1 is mandatory.

Annexure 1 §1.5, headed Cyber Security Audit and Reports, then reads in full:

“The entities shall carry out and submit to the IT Committee quarterly internal and annual external audit reports; bi-annual Vulnerability Assessment / Penetration Test (VAPT) reports; PCI-DSS including Attestation of Compliance (AOC) and Report of Compliance (ROC) compliance report with observations noted if any including corrective / preventive actions planned with action closure date; inventory of applications which store or process or transmit customer sensitive data; PCI-SSF compliance status of payment applications which stores or processes card holder data.”

One sentence, five deliverables, three cadences. “Bi-annual” is the Direction’s own word. RBI does not define it; it is read here as half-yearly, because the same sentence uses “quarterly” and “annual” where it means them, and a biennial reading would put a payment aggregator below PCI DSS’s own twelve-month floor, and it is not new drafting: the identical sentence sits at Annex 2 §1.5 of the March 2020 Guidelines on Regulation of Payment Aggregators and Payment Gateways. The 2025 recast changed one term in it — PA-DSS became PCI-SSF, PA-DSS having been retired on 28 October 2022 — and left the cadence untouched.

Two neighbouring clauses matter for what the VAPT is not. Clause 9(d) requires “an annual system audit, including cyber security audit, conducted by CERT-In empanelled auditors”, reported to the respective Regional Office of DPSS — a different artefact, a different recipient, and a different exercise from PCI DSS validation. Clause 9(e) points the PA at the Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators (RBI/DPSS/2024-25/123, 30 July 2024), whose clause 18 requires security testing “at adequate frequency (at least on annual basis)”. Where two RBI instruments both bite, you plan to the shorter one: Annexure 1 §1.5. The clause-by-clause reading of the rest of the Direction sits in the companion piece on PCI DSS and the PA Directions.

The clocks, side by side

Where a six-month clock is not the same six-month clock

There is a reading that appears to close the gap. A payment aggregator is a service provider under PCI DSS — the glossary defines one as a “business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data” on behalf of another entity, and says this “includes payment gateways, payment service providers (PSPs), and independent sales organizations (ISOs)”. Requirement 11.4.6 therefore applies, and 11.4.6 is six-monthly. Six months, twice a year, obligation discharged.

It is not. 11.4.6 is conditional and narrow. It bites only “if segmentation is used to isolate the CDE from other networks”, and what it asks for is a penetration test of the segmentation controls, “confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems”. A flat cardholder data environment carries no 11.4.6 obligation at all. And a segmentation test that finds the boundary holding says nothing about the application logic inside it — which, for an aggregator, is where the merchant onboarding flow, the settlement logic and the card vault live. Annexure 1 §1.5 asks for VAPT reports, unqualified. A six-monthly segmentation test is one input to that pack, not the pack.

What running on the shorter clock looks like

Plan the calendar off the RBI cadence and let the PCI floor be satisfied as a by-product. Twice a year, internal and external, scoped to the cardholder data environment as it stands on the day rather than as it stood at the last assessment. Six months of merchant onboarding and infrastructure change moves a CDE further than most aggregators expect, and a scope narrower than the documented CDE is the commonest reason a report comes back. Each half is a re-scope, not a repeat.

Three details survive the calendar:

• The change trigger runs independently of both clocks. 11.4.2 and 11.4.3 fire on significant infrastructure or application change wherever you are in the half. Two scheduled tests a year and no change-driven tests, in a business that ships continuously, is defensible only if nothing significant shipped.
• 11.4.4 makes the retest part of the requirement. Exploitable vulnerabilities are corrected “in accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1”, and “penetration testing is repeated to verify the corrections”. A six-month cycle with no room in it for the retest is a cycle that does not close.
• The reports have a named audience. §1.5 does not ask for a test; it asks for reports submitted to the IT Committee alongside the AOC and ROC, “with observations noted if any including corrective / preventive actions planned with action closure date”. Findings need requirement numbers, owners and closure dates attached when they are written, not reconstructed for a committee pack a month later.

The two clocks are not in conflict; they are in a hierarchy. PCI DSS states the minimum for any entity handling card data. The RBI states what a payment aggregator must do to keep its authorisation, and requires the annual system audit by a CERT-In empanelled auditor under clause 9(d) on top of it. Reading the first as though it were the second is how an aggregator ends up with a clean Attestation of Compliance and a hole in its Annexure 1 pack.