A System Audit Report is the annual document a regulated financial entity files with the Reserve Bank of India to evidence that its technology, data handling and security controls hold up under independent examination.
The short answer
A System Audit Report, usually shortened to SAR, is the output of an independent technology audit that the RBI requires from banks, non-banking financial companies, payment aggregators, prepaid instrument issuers and other payment system operators. It must be produced by a CERT-In empanelled auditor, approved by the board, and submitted to the regulator. You cannot self-certify it, and the auditor who writes it is not permitted to fix what they find.
That last constraint is the one that catches teams out. The audit surfaces gaps and stops there. Everything before it is your problem.
On this page
What a System Audit Report is
The RBI supervises technology risk in regulated entities partly through periodic independent audit. The System Audit Report is the artefact that carries the result. It is not a certificate and it is not a pass mark. It is a documented assessment, with evidence attached, that the regulator reads.
Two distinct strands travel under the same name. The first comes from the RBI directive of 6 April 2018 on storage of payment system data, which requires payment data to be held only in India. The second is the entity-specific system and cyber security audit written into individual licence frameworks. Many companies file a report that covers both.
Who has to file one
| Entity | Why the System Audit Report applies |
|---|---|
| Payment aggregators | The payment aggregator Directions require an annual system and cyber security audit report filed with the RBI |
| Prepaid instrument issuers, bill payment operators, card networks and other payment system operators | Licence conditions and the payment data storage directive both bite |
| Banks and non-banking financial companies | Information systems audit obligations, weighted by where the company sits in the NBFC regulatory layers |
| Cross-border payment aggregators | Payment data localisation plus foreign exchange handling both fall inside scope |
| Software vendors to any of the above | Not filers, but reachable through the third-party sections of someone else’s report |
What the audit covers
Scope varies by licence, but the recurring domains are consistent enough to prepare against.
| Domain | What the auditor looks for |
|---|---|
| Payment data storage and residency | Where data physically sits, end-to-end flows, and evidence that anything processed abroad was purged there and returned to India within the permitted window |
| System architecture and network design | Current diagrams that match reality, segmentation, and documented interfaces |
| Access management | Least privilege, multi-factor authentication, privileged account handling and joiner-mover-leaver evidence |
| Cryptographic controls | Encryption in transit and at rest, key management, and no plaintext card credentials |
| Vulnerability assessment and penetration testing | VAPT across in-scope applications and infrastructure, with findings mapped to requirements and a retest attached |
| Logging, monitoring and incident management | Correlated logging with retention, plus a response plan that has actually been exercised |
| Backup, restoration and business continuity | Recovery targets that were measured rather than asserted |
| Third-party and outsourcing risk | Due diligence records, contractual audit rights and exit planning for material providers |
Why first submissions fail
A System Audit Report engagement typically runs three to nine weeks, and most of that variance is remediation, not testing. The audit finds the same things repeatedly.
Documentation that lags the build
Architecture diagrams and data flow maps describe last year’s system. The auditor cannot certify what nobody can accurately describe.
Gaps found during, not before
Open vulnerabilities and missing logs surface inside the engagement, so the clock is already running while you fix them.
Evidence that does not exist yet
Controls may work in practice but leave no trail. An auditor cannot sign off on a process without records of it operating.
The submission is not the end of it
Findings and their closure status are visible to the supervisor, and RBI supervisory workflow now runs through platforms such as DAKSH. An open finding carried into the next cycle is a pattern the regulator can see. Non-compliance on payment data localisation in particular has drawn business restrictions, not just correspondence.
If you are a vendor inside the scope
Most technology companies never file a System Audit Report of their own. They land inside a customer’s. If a regulated entity processes payment data on your platform, or your software sits in the settlement path, the third-party and data-flow sections of their report reach you.
In practice that means answering where data is stored, producing a current penetration test, showing how your staff access the environment, and committing to an incident notification timeline that lets your customer meet its own. Getting asked mid-audit is the expensive version. The same pattern shows up in escrow account controls and in ordinary enterprise vendor review.
How Osto gets you audit-ready
Osto covers the technical half of a System Audit Report by default rather than as separate purchases. Expert-led VAPT and continuous scanning find what the auditor would find, with retests attached. Cloud posture management and API discovery close the configuration and endpoint gaps that dominate findings. Correlated logging produces the retention and audit trail the report asks you to demonstrate.
The evidence layer is purpose-built for exactly this. One control set answers the RBI reviewer, a regulated customer’s vendor questionnaire, SOC 2 and ISO 27001 at once. Osto prepares your evidence and gets you through the review. The audit itself is performed by the CERT-In empanelled auditor, and that separation is deliberate on both sides.
Free security assessment
Walk into the audit with nothing left to find
Osto finds and fixes what an empanelled auditor would flag, then holds the evidence. VAPT, cloud posture, code security, logging and compliance in one platform.
Get a free security assessment Book a platform walkthroughAudit-ready in days · RBI, SEBI and DPDP mapped · One platform, everything
Frequently asked questions
What is a System Audit Report?
A System Audit Report is the documented result of an independent technology and security audit that the Reserve Bank of India requires from regulated entities. It covers architecture, payment data handling, access controls, testing, logging and continuity, and is submitted to the regulator after board approval.
Who can prepare a System Audit Report?
A CERT-In empanelled auditing organisation. The lead auditor is commonly expected to hold the Certified Information Systems Auditor credential. An internal team, a general financial auditor or a non-empanelled security firm cannot issue it for RBI submission.
How often must a System Audit Report be submitted?
Annually for most regulated entities, and additionally whenever the Reserve Bank of India asks for one. Some licence frameworks also trigger a fresh audit on material change to systems or on authorisation.
What is the difference between a System Audit Report and a penetration test?
A penetration test is one input. The System Audit Report is a wider assessment covering governance, data residency, access management, cryptography, logging, continuity and third-party risk, with the test results forming one section of it.
What happens if the audit finds problems?
Findings are recorded with severity and a remediation plan, and the auditor typically revalidates closure. Unresolved items carry into the report the regulator reads. Sustained non-compliance, particularly on payment data localisation, has previously led to restrictions on onboarding new customers.