RBI Data Localization Audit — the System Audit Report (SAR)
RBI requires the entire payment data of every payment system operated in India to be stored only in India — and the way you prove it is an annual System Audit Report by a CERT-In empaneled auditor. As a CERT-In empaneled assessor, Intect conducts that SAR, and we trace your actual data flows to confirm where payment data really lives — so the board-approved report you file with RBI proves compliance rather than merely asserting it.
CERT-In Empaneled. Aligned to RBI's "Storage of Payment System Data" directive (April 2018) and the 2019 FAQ. We trace the data, not just the diagram.
Payment data stays in India — and the SAR is how you prove it
On 6 April 2018, the Reserve Bank of India directed that the entire data relating to payment systems operated in India must be stored in a system only in India. The rule is deliberately broad: it covers the full end-to-end transaction details — the information collected, carried and processed as part of every payment instruction — including customer data, payment-sensitive account details, payment credentials and the transaction record itself. There is a single, narrow exception for cross-border transactions, and a strict rule on bringing any data processed abroad back home. Beyond that, the data lives in India.
This is not a controls framework you interpret loosely; it is a specific, mandated obligation with a specific form of proof. Compliance is evidenced through a System Audit Report — a SAR — conducted by a CERT-In empaneled auditor, approved by your Board and submitted to RBI. The directive applies to every authorised payment system provider and the banks, payment aggregators, gateways and third-party vendors that participate in or service their systems. If you operate, participate in, or build on India's payment rails, the SAR is how you demonstrate, to the regulator, that your payment data has never left the country it is required to stay in.
"A data-flow diagram is a claim about where your payment data lives. A traced and tested data flow is proof. For data localization, the regulator is asking for proof."
The rule, in three parts
RBI's localization requirement comes down to three clear rules — where payment data must stay, the one exception for cross-border transactions, and what happens to any data processed abroad. The SAR tests all three.
The entire end-to-end payment data — collected, carried and processed as part of the payment instruction — is stored only in India.
For a cross-border transaction, the foreign-leg (foreign component) may be stored abroad; a copy of the domestic component may also be stored abroad if required.
Where payment data is processed abroad, it must be deleted from systems abroad and brought back to India — not later than one business day or 24 hours from payment processing, whichever is earlier.
The SAR exists to evidence each of these three rules against your real systems — not to restate them on paper.
Who is in scope
The directive reaches across the entire payment ecosystem. It binds the operators RBI authorises directly, and it follows the payment data downstream to everyone who participates in or services those systems. We scope every engagement to the role you play in the payment chain.
Payment System Operators (PSOs)
Entities authorised by RBI to operate a payment system — card networks, ATM networks, wallets, money-transfer and clearing systems.
Payment Aggregators & Gateways
PAs and PGs that collect, route and process payment instructions on behalf of merchants.
Banks as Participants
Banks operating or participating in authorised payment systems, as operators or members.
Third-Party Vendors & Service Providers
Technology and processing vendors engaged by an authorised entity to provide payment services.
Whatever your role, the localization rule and the SAR follow the payment data — so where your systems touch it, they are in scope.
How a SAR runs
A disciplined, evidence-led path from scoping to RBI submission — built so your team always knows where the audit stands and what to act on next.
FIG. 02 — SAR audit lifecycle · 01–03 scoping & mapping · 04 technical validation of storage & flows (the offensive edge) · 05–07 gap analysis, Board approval & submission
What the SAR covers
Per RBI, the System Audit Report must — among other things — cover data storage, maintenance of the database, data backup and restoration, and data security. We examine each against your real systems, and add the localization-specific controls the directive turns on:
01 Data storage location Where the entire payment data physically and logically resides — primary databases, application stores and every system that holds end-to-end transaction details — confirmed to be only in India.
02 Database maintenance How payment databases are administered, replicated and accessed, and whether any replication, mirroring or managed-service arrangement places data outside India.
03 Data backup & restoration Where backups are written and restored, including cloud and third-party backup destinations and disaster-recovery copies — so localization holds for resilience data too, not only production.
04 Data security Access controls, encryption, segregation and monitoring over payment data wherever it rests, and the controls that prevent it from leaving India.
05 Cross-border handling For cross-border transactions, that only the foreign-leg (foreign component) is stored abroad — and the domestic component is governed correctly.
06 Deletion & repatriation of foreign-processed data Where any payment data is processed abroad, that it is deleted from systems abroad and brought back to India within RBI’s required window.
07 Third-party & cloud arrangements That vendors, processors and cloud regions in your payment path keep data in India, with contractual and technical controls that bind them to the same rule.
We don't certify the diagram. We trace where the data actually goes.
A localization attestation says payment data is in India. An attacker — and a regulator after an incident — cares about where it actually is. We close that gap.
The attestation-only audit
A document-only SAR reviews architecture diagrams, data-flow documentation and management's representations, and confirms that, on paper, payment data is stored in India. It is necessary work — and it is where many audits stop. But a diagram is a description of intent, and the difference between intent and reality is exactly what a misconfigured backup, an overlooked log sink, a default cloud region or a chatty third-party vendor quietly creates.
The traced-and-validated SAR
Intect comes from offensive security, so we don't take the data-flow diagram on trust — we trace and technically validate the actual flows and storage. We follow payment data through applications, databases, logs, backups, replication and cloud regions, and inspect the systems themselves to confirm where it really rests. You get a SAR backed by evidence that localization holds end to end — including in the backups, logs and vendor systems where data most often slips abroad unnoticed — so the report you put before your Board and the regulator is earned, not assumed.
We are CERT-In empaneled, so the SAR is the audit RBI requires — and we come from offensive security, so we prove where your payment data lives instead of taking the diagram's word for it. That combination is the point.
DATA TRACED — NOT TAKEN ON TRUSTWhat you receive
Every engagement produces the System Audit Report RBI expects — plus the underlying evidence your team and your Board can stand behind.
System Audit Report (SAR)
The board-approvable report in RBI's expected form, covering data storage, database maintenance, backup and restoration, and data security, with the localization conclusion clearly evidenced.
Verified data-flow & storage map
A documented, validated map of where payment data is collected, carried, processed, stored, backed up and replicated across your systems and vendors.
Localization gap analysis & remediation roadmap
Each finding mapped to the directive and the FAQ, with severity, risk and specific, prioritized remediation guidance — not generic advice.
Technical validation evidence (the offensive edge)
Evidence from the systems themselves — storage locations, cloud-region configurations, backup destinations, replication and logs — confirming where data really lives.
Executive & Board summary
The localization posture and state of compliance in plain language for the Board approval the SAR requires.
RBI submission & re-audit support
Support through submission of the SAR to RBI, and re-verification of remediated findings so closure is evidenced.
Why payment system entities choose Intect
CERT-In Empaneled — The SAR must come from a CERT-In empaneled auditor. Intect is CERT-In empaneled — so we can conduct it, and the report is accepted where it counts.
We trace, not assume — We come from penetration testing and red teaming, so we follow payment data through the systems that actually hold it — including the backups, logs and vendor links a paper review misses.
Researcher-led, not checklist-led — Engagements are run by practitioners who understand both the directive and the architecture — so the SAR is accurate, contextual and defensible.
Delhi-based, regulator-fluent — An India-based team fluent in RBI's payment-system directions and Indian financial-sector supervision, available to your team through the engagement.
Frequently asked questions
What exactly is the RBI Data Localization audit?
It is the System Audit Report (SAR) that evidences compliance with RBI’s "Storage of Payment System Data" directive of 6 April 2018, which requires the entire payment data of systems operated in India to be stored only in India. The SAR is conducted by a CERT-In empaneled auditor, approved by your Board, and submitted to RBI. It is a specific, mandated audit — narrower than a full IS audit.
What counts as "payment data" that has to stay in India?
RBI's 2019 FAQ is explicit: the full end-to-end transaction details — the information collected, carried and processed as part of the payment instruction. That includes customer data (name, mobile, email, Aadhaar, PAN, etc.), payment-sensitive data (customer and beneficiary account details), payment credentials (OTP, PIN, passwords, etc.) and the transaction data itself. In short, the entire payment data.
Can any payment data be stored abroad?
Only in one narrow case. For a cross-border transaction — one with a foreign component and a domestic component — a copy of the domestic component may also be stored abroad if required, and the foreign-leg data may be stored in the foreign country. Where payment data is processed abroad, RBI's FAQ requires it to be deleted from the systems abroad and brought back to India not later than one business day or 24 hours from payment processing, whichever is earlier. For domestic transactions, the data stays in India.
Who is required to do this?
All payment system providers authorised by RBI, and the banks, payment aggregators, payment gateways and third-party vendors that operate, participate in or service those systems. If your systems touch payment data on India’s rails, the localization rule — and the SAR — follow that data to you.
Who is allowed to conduct the SAR?
RBI requires the SAR to come from a CERT-In empaneled auditor. Intect is CERT-In empaneled, so we can conduct it and provide the technical validation behind it.
How is this different from the RBI IS audit?
The SAR is narrow and specific: it certifies that payment-system data is stored in India, per the 2018 directive. The RBI IS audit is broad — it examines IT governance, security, resilience, third-party risk and application controls across your regulated functions. They are complementary; we offer both, on separate pages.
How often is the SAR required?
The SAR is a recurring, periodic obligation for payment system operators — it is filed annually, not once. We help you set a cadence that satisfies RBI’s expectation and time the engagement to your compliance calendar.
Do you just review our data-flow diagrams, or actually check the systems?
We do both — and the second is the point. We map your data flows and then trace and technically validate them against the actual systems, inspecting storage locations, cloud regions, backups, replication and logs. That is how we surface payment data sitting abroad in a backup, a log sink or a vendor system that a diagram-only review would never catch.
Related RBI assurance
RBI compliance spans several distinct audits. This page covers the narrow, mandated data-localization SAR; for the broader audits below, see the dedicated pages.
Prove your payment data stays in India.
Tell us the payment systems you operate or service and where you are in your SAR cycle, and we'll scope a System Audit Report that fits — or connect you directly with an assessor.