SAR Audit: System Audit Report Requirements in India

SAR is the full form of System Audit Report — a formal audit of an entity's systems and controls, submitted to the regulator or network operator that requires it. It is not a single standard but a family: the RBI requires system audits for payment system data storage and for payment aggregator, payment gateway and prepaid instrument licences; NPCI requires them for UPI participants and third-party application providers; and SEBI requires them of market intermediaries. CyberSigma is CERT-In empanelled and PCI QSA authorised (CEMEA, Asia Pacific and the USA).

The SAR family — which one applies to you

'SAR audit' is used loosely to mean several different regulator-mandated audits. Identifying which one binds you is the first and most consequential step:

• RBI payment system data storage — the audit evidencing that payment system data is stored in India as the RBI requires, historically submitted through the entity's regulator-facing channel.
• Payment Aggregator and Payment Gateway — system audit obligations attaching to PA/PG authorisation and its continuation.
• Prepaid Payment Instruments — system audit expectations for PPI issuers.
• BBPOU — Bharat Bill Payment Operating Units under the Bharat Bill Payment System.
• NPCI / UPI — audits required of UPI participants and third-party application providers operating on the network.
• SEBI market intermediaries — system audits for stock brokers, depository participants and other regulated entities, alongside the CSCRF obligations.
• The scope, the submitting entity and the destination differ in each case. A report written for one will not satisfy another.

What a system audit examines

Across the family the underlying questions are consistent, even where the reporting format differs:

• Where regulated data physically resides, and whether storage and any permitted processing outside India match what the rule allows.
• Application and infrastructure security of the systems handling transactions, tested rather than reviewed on paper.
• Access control and segregation of duties over production systems and regulated data, including privileged and vendor access.
• Transaction integrity, reconciliation and the logging that would let you reconstruct a disputed transaction.
• Change management, so that what was audited resembles what is running.
• Business continuity and disaster recovery, with recovery objectives that have been tested rather than documented.
• Incident response, including how the incident would reach the regulator and within what window — which is where the CERT-In six-hour obligation intersects.

Getting a report the regulator accepts

Most rejected or queried submissions we see fail for procedural reasons rather than security ones:

• The audit was scoped against the wrong mandate, so the report answers questions nobody asked.
• The auditor's qualification or empanelment did not meet what the mandate required — several of these audits specify a CERT-In empanelled auditor.
• Findings were listed but closure was not evidenced, and the regulator asked for the re-test that was never done.
• The submission missed its window because remediation time was not built into the plan.
• Scope excluded an outsourced component that the regulator considers squarely in scope.

How we run it

We start by establishing exactly which mandate binds you and what the submitting format and deadline are, because that determines everything else. We then scope, test technically rather than by interview, and produce the report in the form your regulator or network operator expects. Remediation is planned inside your submission window, and we re-test so closure is evidenced. Where you carry more than one of these obligations — a PA licence and NPCI participation, say — we scope a single evidence exercise and produce each report from it rather than auditing the same estate twice.

What is the full form of SAR in banking and payments?

In this context SAR stands for System Audit Report — a regulator-mandated audit of an entity's systems and controls, submitted to the regulator or network operator that requires it. Note that SAR is also used elsewhere for Suspicious Activity Report under anti-money-laundering rules; the two are unrelated, and it is worth confirming which your counterparty means.

Who needs a System Audit Report?

Entities across the regulated financial ecosystem: those storing payment system data under RBI requirements, payment aggregators and payment gateways, prepaid payment instrument issuers, Bharat Bill Payment Operating Units, UPI participants and third-party application providers under NPCI, and SEBI-regulated market intermediaries. Which mandate binds you determines the scope and the submission route.

Does the auditor have to be CERT-In empanelled?

For several of these mandates, yes — the requirement specifies a CERT-In empanelled auditor, and a report from a non-empanelled firm will be rejected. CyberSigma is empanelled. If you are unsure what your specific mandate requires, send us the clause and we will confirm before you commit.

How often is a system audit required?

Typically annually, with additional audits triggered by material change — a new platform, a significant integration, or a change in the licence or participation you hold. The exact cadence follows the mandate that binds you, which we confirm during scoping.

How is a SAR different from a SEBI CSCRF assessment?

A System Audit Report is a regulator-mandated system audit with a defined scope and submission route. CSCRF is SEBI's cybersecurity and cyber resilience framework that regulated entities are assessed against. For SEBI entities the two are related and the evidence overlaps considerably, so we often scope them together.

What if we hold more than one of these obligations?

That is common — a payment aggregator that is also an NPCI participant, for example. The underlying estate is the same, so we run one evidence-gathering exercise and produce each report from it, rather than auditing the same systems twice and charging you for both.