The Reserve Bank of India does not publish a single rulebook called "application security". The obligations sit across four documents, issued years apart, that partly overlap and partly replace one another. An examiner will usually ask for evidence against a specific paragraph number, not a general statement of intent.
Four documents cover application security testing for regulated entities: the 2016 circular on Cyber Security Framework in Banks and its Annex 1 baseline controls; the 2021 Master Direction on Digital Payment Security Controls; the 2023 Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices; and the 2017 Master Direction on the IT Framework for the NBFC Sector, repealed by the 2023 direction for the layers it covers. Every clause below was read directly from the RBI PDF on rbi.org.in, with the paragraph number as printed.
The focus is narrow: VAPT, secure coding and source code review, mobile application security, API security, patch management and third-party code, and precisely which entities each rule applies to.
Which RBI Rules Apply to Your Institution
None of these documents applies to every regulated entity the same way, which is the most common self-assessment mistake.
| Document | Applies to | Status / effective date |
|---|---|---|
| Cyber Security Framework in Banks (circular DBS.CO/CSITE/BC.11/33.01.001/2015-16) | All Scheduled Commercial Banks, excluding Regional Rural Banks | June 2, 2016. Not in the 2023 direction's repeal annex, so still in force. |
| Master Direction on Digital Payment Security Controls | Scheduled Commercial Banks (excluding Regional Rural Banks), Small Finance Banks, Payments Banks, and credit card issuing NBFCs | February 18, 2021. Effective six months after publication on RBI's website. |
| Master Direction on IT Governance, Risk, Controls and Assurance Practices | All banking companies, corresponding new banks and State Bank of India; NBFCs in the Top, Upper and Middle layers; Credit Information Companies; five All India Financial Institutions (EXIM Bank, NABARD, NaBFID, NHB, SIDBI) | November 7, 2023. Effective April 1, 2024. Excludes Local Area Banks and NBFC-Core Investment Companies. |
| IT Framework for the NBFC Sector | Previously NBFCs, split above and below a set asset-size threshold | June 8, 2017. Named in the 2023 direction's repeal annex, so no longer applies to the layers now covered by that direction. |
Note: Base Layer NBFCs are not named in the 2023 direction's applicability clause, and the 2016 circular applies only to banks, never to NBFCs.
VAPT: What RBI Actually Requires and How Often
The 2023 Master Direction sets the current baseline VAPT frequency for banks and for NBFCs in the Top, Upper and Middle layers, under Chapter IV, paragraph 26:
- "For critical information systems and/ or those in the De-Militarized Zone (DMZ) having customer interface, VA shall be conducted at least once in every six months and PT at least once in 12 months." (para 26(a))
- "For non-critical information systems, a risk-based approach shall be adopted to decide the requirement and periodicity of conduct of VA/ PT." (para 26(b))
- "VA/ PT shall be conducted by appropriately trained and independent information security experts/ auditors." (para 26(c))
For digital payment applications, paragraph 24(a) of the 2021 Master Direction sets the same half-yearly VA and yearly PT cadence, and adds a trigger: testing is also required "as and when any new IT Infrastructure or digital payment application is introduced or when any major change is performed."
The 2016 circular's Annex 1, still in force for banks, frames VAPT as a lifecycle control: "Periodically conduct vulnerability assessment and penetration testing exercises for all the critical systems, particularly those facing the internet" (item 18.1), carried out by "professionally qualified" teams (item 18.3), with findings "monitored closely by the Information Security/Information Technology Audit team as well as Senior/Top Management" (item 18.4). The annex also names red teaming as an option, to "simulat[e] the objectives and actions of an attacker" (item 18.5).
A bank running digital payment products needs to evidence VAPT against two overlapping clocks: the general cadence in the 2023 direction, and the payment-application trigger in the 2021 direction.
Book a free scoping call with a certified tester, or compare the tools behind it first.
Secure Coding, Application Security Testing and Source Code Review
The 2016 circular's Annex 1 sets out an "Application Security Life Cycle" section. Item 6.2 asks banks to consider "conducting source code audits by professionally competent personnel/service providers or have assurance from application providers/OEMs that the application is free from embedded malicious / fraudulent code." Item 6.3 adds that "secure coding practices may also be implemented for internally /collaboratively developed applications," and item 6.6 ties the two together: development should be "based on threat modelling, incorporate secure coding principles and security testing based on global standards." Item 6.7 names a baseline: address vulnerabilities "based on best practices baselines such as Open Web Application Security Project (OWASP)."
The 2021 Master Direction is more prescriptive. Paragraph 21 requires security objectives at every phase, including "(d) testing including source code review." Paragraph 24 requires "security testing including review of source code, Vulnerability Assessment (VA) and Penetration Testing (PT) of ... digital payment applications ... Such testing should invariably cover compliance with various standards like OWASP." Sub-clause 24(b) sets a yearly cadence for source code review or certification "if changes/ upgrades have been made to the application during the year," and 24(c) sets the objective: the application should be "developed as per the best secure design/ coding practices and standards, addressing known flaws/threats due to insecure coding."
Evidencing this needs both a testing record and a source-code review record per release. SecOpsTool's VAPT Services combine manual penetration testing with automated scanning, mapped to OWASP Top 10, ISO 27001 and PCI DSS. Checkmarx One covers static application security testing across a wide range of languages, mapped to OWASP Top 10 and PCI DSS presets.
Mobile Application Security Controls
The 2021 Master Direction gives mobile applications their own chapter. Paragraph 56 lists device policy enforcement, secure app download and install, "Deactivating older application versions in a phased but time bound manner (not exceeding six months from the date of release of newer version)," device or application encryption, minimal data collection and app permissions, application sandbox or containerisation, and code obfuscation. Paragraph 63 adds that apps should not store or retain sensitive authentication information such as user IDs and passwords on the device.
The 2016 circular's Annex 1, item 6.8, covers similar ground: banks should consider "installing a 'containerized' apps on mobile/smart phones for exclusive business use that is encrypted and separated from other smartphone data/applications," including a "remote wipe on the containerized app" if the device is lost.
Several supplied tools map onto this chapter. Appknox tests compiled Android and iOS binaries against OWASP Mobile Top 10 2024 and OWASP MASVS v2, the baseline paragraph 24 asks testing to cover. Protectt.ai states the connection directly: "OWASP MASVS controls align closely with RBI's Digital Payment Security Controls, NPCI guidelines, and PCI DSS mobile security requirements," and its runtime protection addresses the tampering and repackaging risks behind paragraph 56's sandboxing and obfuscation controls. Bugsmirror's RunLock product makes a similar claim, stating it helps address "OWASP MASVS, SEBI CSCRF (Cybersecurity and Cyber Resilience Framework), RBI MDDPSC (Master Direction on Digital Payment Security Controls), and NPCI guidelines."
API Security: a Thin but Real Requirement
Of the areas this post covers, API security is where RBI's own text is least developed. Across all three current documents, only one clause names APIs directly: paragraph 31 of the 2021 Master Direction, which states, "The security controls for digital payment applications must focus on how these applications handle, store and protect payment data. The APIs for secure data storage and communication have to be implemented and used correctly in order to be effective." No document sets an API-specific testing frequency or names a standard such as the OWASP API Security Top 10.
In practice, API security must be evidenced under the general application testing and VAPT clauses above, applied to the API layer. Checkmarx One discovers APIs directly from source code and documentation, including undocumented endpoints, mapped to the OWASP API Security Top 10; Burp Suite DAST ingests Postman collections, OpenAPI, SOAP and GraphQL definitions to test live API endpoints, and PortSwigger states its platforms help with compliance against "PCI DSS, HIPAA, NIST 800-53, OWASP Top 10, GDPR, and more." Either approach maps back to paragraph 24's OWASP testing language, even without a dedicated RBI API security clause.
Patch Management
The 2023 Master Direction requires a documented policy: "REs shall put in place documented policy(ies) and procedures for change and patch management to ensure ... the business impact of implementing patches/ changes (or not implementing a particular patch/ change request) are assessed" and that patches "are applied/ implemented and reviewed in a secure and timely manner with necessary approvals" (para 13).
The 2016 circular's Annex 1 is more operational. Item 2.3 requires banks to "continuously monitor the release of patches by various vendors / OEMs, advisories issued by CERT-in and other similar agencies and expeditiously apply the security patches as per the patch management policy of the bank," running an "emergency patch management process" for a patch addressing a vulnerability already being exploited. Item 7.1 asks for "a documented risk-based strategy for inventorying IT components that need to be patched ... so as to minimize the number of vulnerable systems and the time window of vulnerability/exposure."
The 2021 direction ties patching to testing results: vulnerabilities found through VA/PT should be closed "in a time-bound manner" through patching, a compensating control, or a documented and accepted residual risk (para 26). Nessus supports the discovery side: Tenable states the product is built to "find flaws, missing patches, and misconfigurations across OS, devices, and apps," the detection step both documents assume happens before a patch is assessed and applied.
Third-Party and Vendor Code
All three current documents treat vendor-supplied code as a distinct risk, not something covered implicitly by internal secure-coding rules. The 2023 Master Direction requires banks to hold the underlying code, or a fallback: "REs shall obtain the source codes for all critical applications from their vendors. Where obtaining of the source code is not possible, REs shall put in place a source code escrow arrangement or other arrangements" (para 12(f)), backed by "a certificate ... from the application developer or vendor stating that the application is free of known vulnerabilities, malware, and any covert channels in the code" (para 12(g)). Paragraph 10 separately requires a vendor risk assessment process for third-party IT and cyber security arrangements outside RBI's own Outsourcing of IT Services Directions.
The 2021 direction applies the same escrow logic to digital payment applications (para 23), with "penal provisions" required in the vendor contract for any non-compliance (para 24(d)). The 2016 circular's Annex 1 states the underlying principle: "Banks shall be accountable for ensuring appropriate management and assurance on security risks in outsourced and partner arrangements" (item 11.1), backed by "effective due diligence, oversight and management of third party vendors/service providers & partners" (item 11.3) and mandatory "background checks, non-disclosure and security policy compliance agreements" (item 11.9).
Evidencing These Controls Ahead of an Inspection
RBI wants dated, traceable evidence tied to a specific application and clause, not a general assurance that testing happens. A practical evidence pack needs: a VAPT report with a CVSS-scored finding list and a re-test confirming closure; a source code review or SAST report per critical application released or materially changed in the year; a mobile test record covering paragraph 56; an API test record where applications expose APIs; a patch log against the para 13 policy; and vendor certificates or escrow agreements for applications not built in-house.
SecOpsTool's VAPT Services are built to produce the first of those, with manual testing, CVSS scoring, remediation guidance and a re-test. For the application layer, Checkmarx One and Burp Suite cover static and dynamic testing; for mobile, Appknox, Protectt.ai and Bugsmirror cover binary testing, runtime protection and OWASP MASVS alignment; for patch visibility, Nessus finds missing patches and misconfigurations that feed a patch log. Where the requirement is authentication, such as the 2016 circular's call to "provide positive identify verification of bank to customers" (Annex 1, item 9.1), Ashield's device, SIM and user-bound authentication for banking is built for that control.
Map your current evidence against the clauses above by document and paragraph number, identify the gaps, and scope the testing needed to close them before the next inspection cycle. Request a scoping call and we will help match the requirement to the right test.
Questions Buyers Ask
Under the 2023 Master Direction on IT Governance, critical and internet-facing systems need a vulnerability assessment at least every six months and a penetration test at least every 12 months, with non-critical systems assessed on a risk basis. For digital payment applications, the 2021 Master Direction sets the same half-yearly and yearly minimum, plus an extra test whenever a new application or major change is introduced.
Yes, but only to NBFCs in the Top, Upper and Middle layers, alongside all banking companies, State Bank of India, Credit Information Companies and five named All India Financial Institutions. Local Area Banks and NBFC-Core Investment Companies are explicitly excluded, and Base Layer NBFCs are not named in the applicability clause.
The 2021 Master Direction's paragraph 56 lists specific mobile controls, including device policy enforcement, secure app download and install, retiring older app versions within six months of a new release, device or application encryption, minimal data collection and permissions, sandboxing or containerisation, and code obfuscation, with paragraph 63 adding that apps should not store sensitive authentication data such as passwords on the device.
Sources
Primary documents this article is based on. Regulatory clauses and product statements above are taken from these pages.
- Cyber Security Framework in Banks (2016 circular)
- Annex 1: Baseline Cyber Security and Resilience Requirements
- Master Direction on Digital Payment Security Controls, 2021
- Master Direction on IT Governance, Risk, Controls and Assurance Practices, 2023
- Master Direction: IT Framework for the NBFC Sector, 2017
- Appknox: compliance frameworks
- Protectt.ai: OWASP MASVS checklist
- Bugsmirror: RunLock compliance mapping
- Tenable Nessus: compliance checks reference
- Checkmarx: API Security
- PortSwigger (Burp Suite): compliance
- Ashield: banking and financial services