RBI System Audit Report (SAR) & Data Localisation

Introduction: RBI System Audit Report (SAR) & Data Localisation

The Reserve Bank of India (RBI) is the sovereign regulator of India's banking and payment-system landscape, and it has progressively raised the bar on the technology-risk posture of every regulated entity that touches money. The System Audit Report (SAR) regime and the accompanying data-localisation mandate sit at the centre of this expectation. In plain terms, if you operate a payment system, issue prepaid instruments, run a payment aggregator or gateway, provide payment-related services, or are a scheduled commercial bank, small finance bank, payments bank, urban co-operative bank, NBFC or a Non-bank Financial Company operating a payment system, then a periodic, independent System Audit is not optional — it is a licensing and continuance condition.

This guide is written for the person who actually has to sit in the audit chair — the CISO, the head of IT, the compliance lead, the internal auditor and the external empanelled auditor. It walks through what the SAR actually is, who must produce one, how it is structured, and — most importantly — a master assessment checklist that enumerates every control family the RBI expects an auditor to examine, together with the evidence a QSA-grade reviewer would demand. It also covers the closely bound obligation of storing payment-system data only within India (the Data Storage / Data Localisation directive of April 2018), because in practice the SAR must confirm compliance with it.

Two distinct but overlapping instruments drive this: (1) the RBI circular DPSS.CO.OD.No.2785/06.08.005/2017-2018 dated 6 April 2018 on 'Storage of Payment System Data', and (2) the requirement embedded across the Payment Aggregator / Payment Gateway (PA-PG) guidelines, the Master Directions on Prepaid Payment Instruments (PPIs), the RBI Master Direction on Digital Payment Security Controls (2021), and the general licensing conditions under the Payment and Settlement Systems Act, 2007 (PSS Act) for a periodic System Audit. The SAR is the deliverable through which an entity demonstrates conformance to all of them.

What is the RBI System Audit (SAR)?

A System Audit is an independent, evidence-based examination of the information systems, technology infrastructure, information-security controls and operational processes of an RBI-regulated payment or financial entity, conducted by an external auditor who is empanelled with CERT-In (the Indian Computer Emergency Response Team) or is a qualified independent professional acceptable to RBI. The output of that examination is the System Audit Report — the SAR — a formal, signed document submitted to RBI (and retained for inspection) confirming whether the entity's systems are secure, resilient, compliant and, specifically for payment operators, whether payment-system data is stored only in India.

The SAR is not a one-off certification. For most payment operators it is an annual (or as-specified) recurring obligation. For a Payment Aggregator seeking authorisation, an initial SAR is a condition of the in-principle-to-final licence progression; thereafter an annual SAR must be submitted. The audit must be forward-looking — it covers the design and operating effectiveness of controls over the review period, not merely a point-in-time snapshot.

The SAR combines several audit disciplines: an IS (information systems) audit, an information-security / cyber-security review, a business-continuity and disaster-recovery assessment, an application-security review of payment applications, a data-localisation compliance verification, and — for PA/PGs — merchant-onboarding and settlement-control testing. The auditor issues an opinion, lists observations by risk severity, and confirms closure of prior-period findings.

How the SAR differs from a general IT audit

• It is regulator-mandated and regulator-submitted — RBI is the audience, not just the board.
• It carries statutory weight under the PSS Act, 2007; adverse findings can jeopardise the authorisation to operate a payment system.
• It must be performed by a CERT-In empanelled auditor or an RBI-acceptable independent professional, not merely an internal team.
• It has a mandatory data-localisation verification component that a generic ISO 27001 audit would not include.
• Findings must be tracked to closure and re-verified in the next cycle; open high-risk items must be reported.

Who must comply

The obligation to obtain a System Audit and submit a SAR is triggered by the nature of the licence or authorisation held. The data-localisation directive of April 2018 applies to all 'system providers' and their participants, service providers, intermediaries, payment gateways, third-party vendors and other entities in the payment ecosystem. The table below summarises the principal categories.

• Any entity that stores, processes or transmits payment-system data — even if outsourced — is in scope for the data-localisation verification.
• Cross-border transaction data may be processed abroad but the data must be brought back and stored only in India, with any foreign copy deleted within a defined window (commonly cited as 24 hours from payment processing).
• Fintechs partnering with a regulated entity are covered transitively; the regulated principal remains accountable.
• Group entities and cloud / co-location providers used by the regulated entity fall within audit scope.

Structure of the RBI System Audit (SAR)

There is no single monolithic 'control catalogue' number range as in PCI DSS or NIST; instead, the SAR is structured around control domains drawn from the applicable RBI Master Directions and circulars. In practice a competent auditor organises the SAR into the domains below. This structure aligns the SAR with the RBI Master Direction on Digital Payment Security Controls (2021) and the PA-PG baseline technology recommendations, which are the most detailed control sources.

Master assessment checklist

This is the operational heart of the SAR. Below, each domain is expanded into what the auditor must verify and the typical evidence a CERT-In empanelled auditor or PCI QSA would collect. Nothing here should be skipped; where a domain is not applicable (for example, merchant onboarding for a non-PA entity), the auditor must formally record it as 'not applicable with justification' rather than omit it.

D1 — Governance, Risk & Board Oversight

D2 — Information Security Policy & Standards

D3 — Network Security & Segmentation

D4 — Application Security (payment applications)

D5 — Authentication & Access Control

D6 — Cryptography & Key Management

D7 — Data Localisation & Data Governance

D8 — Fraud Risk Management & Transaction Monitoring

D9 — Merchant Onboarding & KYC (Payment Aggregators / Gateways)

D10 — Settlement, Escrow & Nodal Account Controls

D11 — Vendor / Outsourcing & Third-party Risk

D12 — Incident Response & Reporting to RBI / CERT-In

D13 — Business Continuity & Disaster Recovery

D14 — Logging, Monitoring & Audit Trails

D15 — Change & Patch Management

D16 — Vulnerability Management & Penetration Testing

Scoping

Accurate scoping determines the credibility of the SAR. The auditor must first establish the payment-data footprint: every system, application, database, network segment, interface, API, cloud tenancy and third party that stores, processes or transmits payment-system data. Under-scoping is the single most common reason RBI rejects a SAR or issues an adverse continuance direction.

• Define the in-scope environment by following the data: trace the full transaction lifecycle from customer initiation to settlement and archival.
• Include all supporting systems — authentication, key management, logging, monitoring, backup and DR — even if they do not process transactions directly.
• Include outsourced components: cloud hosting, managed SOC, payment-processor connections and merchant-integration layers.
• Explicitly document out-of-scope systems with the justification for exclusion (e.g. segmentation that isolates them).
• For data localisation, scope must cover every copy of payment data including backups, DR, analytics stores, logs and reporting systems.
• State the review period covered by the SAR (typically the preceding 12 months for an annual audit).

Implementation approach (phased)

Entities that treat the SAR as a last-minute compliance scramble invariably fail. A phased programme, ideally spanning three to four months before the submission deadline, produces a defensible report and, more importantly, genuinely secure systems.

Phase 1 — Initiation & Scoping (Weeks 1-2)

• Activities: appoint a CERT-In empanelled auditor; agree scope, review period and methodology; hold kick-off; collect prior SAR and closure status; build the data-flow and asset inventory.
• Deliverables: signed engagement letter; agreed scope document; audit plan; data-flow diagrams; asset register.

Phase 2 — Control Design Review (Weeks 3-5)

• Activities: review policies, standards, architecture and process documents against each domain; identify design gaps; map controls to RBI Master Directions.
• Deliverables: control-design assessment; preliminary gap list; requests-for-information tracker.

Phase 3 — Control Operating-Effectiveness Testing (Weeks 6-10)

• Activities: sample-based testing of evidence, log reviews, configuration reviews, VAPT, segmentation testing, data-localisation verification, escrow reconciliation checks.
• Deliverables: test working papers; VAPT report; data-localisation verification memo; provisional findings.

Phase 4 — Remediation & Re-test (Weeks 10-13)

• Activities: management remediates high-risk findings; auditor re-tests; residual risk assessed; closure of prior-period items confirmed.
• Deliverables: remediation evidence; re-test results; updated findings register.

Phase 4b — Reporting & Submission (Weeks 13-14)

• Activities: draft SAR with opinion and risk-rated observations; management responses obtained; auditor sign-off; board / audit-committee review; submission to RBI.
• Deliverables: signed System Audit Report; management action plan; RBI submission acknowledgement.

Maturity / capability scoring model

While RBI does not prescribe a formal maturity scale, a capability-maturity model is invaluable for tracking progress cycle-on-cycle and prioritising remediation. CyberSigma applies the following five-level model, aligned to CMMI-style thinking, to each control domain.

A target maturity of Level 3 (Defined) is the minimum for a clean SAR; regulated entities of systemic importance should aim for Level 4 across the payment-critical domains (D3-D7, D10, D12-D14).

Assessment and audit approach

1. Confirm the auditor's independence and CERT-In empanelment (or RBI-acceptable status) and document the engagement scope and review period.
2. Obtain and study the prior SAR, closure tracker, and any RBI correspondence or inspection findings.
3. Build a complete asset and data-flow inventory; validate the boundary and, where claimed, test segmentation.
4. Perform control-design review against each of the sixteen domains, mapping to the relevant RBI Master Direction or circular.
5. Perform operating-effectiveness testing on a risk-based sample: configuration reviews, log analysis, VAPT, escrow reconciliation and data-localisation verification.
6. Specifically verify data localisation: trace every payment-data element, confirm India-only storage, and validate deletion of any permitted foreign copy within the stipulated window.
7. Risk-rate each observation (Critical / High / Medium / Low) with impact and likelihood rationale.
8. Present provisional findings to management; obtain responses and remediation commitments; re-test remediated high-risk items.
9. Draft the SAR with an overall opinion, domain-level conclusions, the findings register and management action plan.
10. Obtain auditor sign-off, board / audit-committee review, and submit the signed SAR to RBI within the prescribed timeline, retaining working papers for inspection.

Evidence request list

The following categorised list is what an auditor will request. Assembling it in advance dramatically accelerates the engagement.

• Governance: board/committee minutes, IT & security strategy, CISO appointment, risk register, org charts, SoD matrix.
• Policies & standards: information-security policy, hardening baselines, data-classification schema, acceptable-use policy, exception register.
• Network: architecture and data-flow diagrams, firewall rule exports, segmentation test results, VPN and wireless configs.
• Application: SDLC policy, code-review records, SAST/DAST reports, API and mobile security test results, release checklists.
• Access & authentication: RBAC/PAM configs, access-review reports, MFA enrolment, joiner-mover-leaver tickets.
• Cryptography: TLS scan output, encryption/tokenisation configs, HSM/KMS logs, PCI DSS AoC/RoC.
• Data localisation: hosting/DC location certificates, data-element mapping, foreign-copy deletion logs, cloud-region configs, third-party contracts.
• Fraud & monitoring: FRM policy, fraud-engine rules, alert logs, dispute/chargeback MIS.
• Merchant & settlement (PA/PG): onboarding policy, KYC records, escrow statements, settlement reports, reconciliations.
• Vendor: outsourcing policy, vendor risk assessments, contracts with audit/RBI-inspection clauses.
• Incident & continuity: IR plan, CERT-In/RBI incident submissions, BCP/DR plans, DR test reports, backup and restore logs.
• Logging & monitoring: SIEM configuration, retention policy, sample logs, SOC runbooks and alert samples.
• Change & vulnerability: change tickets, patch reports, VA/VAPT reports and remediation/re-test evidence.

Roles and responsibilities

KPIs to track

• Percentage of prior-period SAR observations closed before the next cycle.
• Number of open Critical/High findings and mean time to remediate.
• Patch SLA adherence rate by criticality.
• VAPT findings trend (open vs closed) cycle-on-cycle.
• Percentage of payment data verified as India-only storage (target 100%).
• Foreign-copy deletion compliance rate within the stipulated window.
• MFA and PAM coverage of privileged accounts.
• Escrow reconciliation break count and resolution time (PA/PG).
• Incident reporting timeliness to CERT-In (within 6 hours) and RBI.
• DR test success rate against RTO/RPO targets.
• Security awareness training completion and phishing-simulation failure rate.
• Maturity score by domain versus target (Level 3/4).

Readiness checklist

• CERT-In empanelled auditor engaged and scope agreed
• Prior SAR observations closed and evidenced
• Complete asset and payment-data-flow inventory prepared
• Segmentation between payment and corporate zones proven
• All payment-system data confirmed stored only in India
• Foreign-copy deletion within stipulated window evidenced
• Board-approved security and fraud-risk policies in force
• MFA and PAM deployed for privileged and remote access
• Card data tokenised / PCI DSS compliance evidenced
• Latest VAPT completed and high-risk findings remediated
• Escrow / nodal account reconciled and within timelines (PA/PG)
• Merchant KYC and onboarding records complete (PA/PG)
• Incident-response plan tested and CERT-In reporting path ready
• BCP/DR plan tested with DR site inside India
• SIEM logging with required retention and monitoring operational
• Vendor contracts include RBI inspection and audit rights
• Management action plan drafted for residual findings

Common gaps

• Payment data replicated to a foreign DR/backup or analytics store, breaching data localisation.
• Foreign-leg processing where the returned data is not deleted within the stipulated window (no deletion logs).
• Unproven segmentation claims that improperly narrow scope.
• Prior SAR observations left open across cycles without closure evidence.
• Weak or absent MFA on administrative and remote access.
• Full card data / CVV storage or absence of RBI-mandated tokenisation.
• Escrow commingling or settlement delays beyond regulatory timelines (PA/PG).
• Inadequate merchant KYC and onboarding of prohibited merchant categories.
• Incident-reporting timelines to CERT-In (6 hours) not met or not evidenced.
• Insufficient log retention (below the CERT-In requirement) or non-time-synchronised logs.
• Vendor contracts lacking RBI inspection / audit-right and exit clauses.
• VAPT findings not remediated or not re-tested before the SAR.

RBI System Audit (SAR) mapped to other frameworks

Frequently asked questions

Need help with RBI System Audit (SAR)?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.