On-Premise Security Testing
Is Not Optional.

Security testing creates a detailed map of your infrastructure's vulnerabilities. That map — the list of exploitable paths, the credential weaknesses, the misconfigured services, the attack chains from perimeter to production — is among the most sensitive data your organisation produces. Where that data goes after the test is not a secondary consideration. For Indian regulated entities, it is a primary compliance requirement.

Two regulatory frameworks establish the data localisation baseline. RBI's 2018 circular on storage of payment system data requires that all payment data be stored only in India, with no copy maintained abroad. The Digital Personal Data Protection Rules notified in November 2025 extend localisation requirements to categories of personal data, with specific provisions for sensitive financial and health data. Security testing that transmits infrastructure vulnerability data to offshore systems sits in direct conflict with both.

What the 2018 RBI circular actually requires

RBI's April 2018 circular on storage of payment system data is specific: "all data (full end-to-end transaction details, information collected, carried and processed as part of the message or payment instruction) relating to payment systems operated in India to be stored in a system only in India." The circular covers payment system operators, not just banks — which means fintechs, payment aggregators, and wallets that process Indian payment data are bound by the same requirement.

The implication for security testing is direct. A testing platform that processes vulnerability data about a payment system's infrastructure in offshore data centres creates a situation where detailed information about that infrastructure's weaknesses is held outside India. Whether that constitutes "payment data" in the narrow technical sense is a question that regulators have not definitively answered. The risk of a regulator taking the view that it does is not one that most regulated entities are willing to accept.

The DPDP Rules and what changed in November 2025

The Digital Personal Data Protection Rules notified in November 2025 operationalise the DPDP Act of 2023. They establish categories of sensitive personal data — financial data, health data, biometric data — for which the data localisation requirements are most stringent. They also establish requirements for data fiduciaries to maintain records of processing activities that would capture the transfer of data to third-party security testing services.

For organisations that hold financial personal data — which includes most banks, NBFCs, fintechs, insurance companies, and wealth management platforms — the DPDP Rules create an additional layer of compliance obligation that sits on top of the sector-specific RBI requirements. A security testing engagement that routes vulnerability data about a financial services system through offshore infrastructure must be evaluated against both.

The on-premise architecture requirement

The compliance-safe architecture for security testing in the Indian regulated sector is one where the testing platform runs entirely within the organisation's own infrastructure. No vulnerability data is transmitted to the testing vendor's systems. No findings are stored in cloud infrastructure that the organisation does not control. The only output is the report, generated within the perimeter and transmitted through normal secure channels.

This requirement significantly narrows the field of compliant security testing options. Traditional VAPT vendors operate their tooling through their own infrastructure and transmit findings to their own systems for analysis and reporting. Cloud-based continuous testing platforms store data in their own cloud infrastructure. Neither architecture satisfies the on-premise requirement for regulated entities subject to RBI's data localisation rules.

The open-core model and auditability

An additional consideration for regulated entities is the auditability of the testing platform itself. CERT-In's empanelment requirements and RBI's IT governance framework both create expectations that the tools used for security assessment can be reviewed and validated. A testing platform with an MIT-licensed open-source core allows regulated entities and their auditors to inspect the assessment logic, verify that it operates as documented, and confirm that no data exfiltration is occurring within the tool itself.

Proprietary testing platforms that operate as black boxes create an audit challenge: the regulated entity is asserting compliance based on a process it cannot independently verify. For organisations subject to RBI oversight, the ability to demonstrate that the testing methodology is sound and that the tool operates within the perimeter is increasingly a requirement of the compliance attestation, not just a nice-to-have.

What procurement decisions need to change

The practical implication of the data sovereignty requirement is that the procurement criteria for security testing services must include architecture as a primary filter, not just scope, methodology, and price. A security testing platform that cannot be deployed entirely on-premise, within the organisation's own infrastructure, is not compliant with the requirements that apply to most Indian regulated financial entities.

This rules out the majority of cloud-based security testing platforms and continuous testing services that route data through offshore infrastructure. It creates a compliance case for on-premise deployment that is independent of the security case — though the security case for keeping vulnerability data within the perimeter is also strong. An attacker who can access the vulnerability report from a cloud-based testing platform has a complete map of your exploitable paths without needing to breach your systems at all.