RBI rules: assess your mobile banking app before and after every release.
The RBI's July 2026 directions for commercial banks require vulnerability assessments at least every six months and penetration tests at least once a year for critical, internet-facing systems, mobile applications included. They carry forward the mobile payment app controls first set out in 2021, from device policy enforcement and root and jailbreak checks to device binding and keeping sensitive data off the phone. The 2025 authentication directions add two factors, at least one dynamic, from 1 April 2026. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the mobile app and the APIs it calls, on the build your customers download
- Tests login, one-time codes, step-up checks and session handling with your test accounts
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Commercial banks first: the 2026 directions cover banking companies, corresponding new banks and the State Bank of India. Similar entity-specific directions were issued for small finance banks, payments banks, urban co-operative banks, NBFCs, all India financial institutions and credit information companies
- Key date
- 31 July 2026: both consolidated directions for commercial banks apply immediately. The authentication directions had to be complied with by 1 April 2026
- Focus
- Vulnerability assessment and penetration testing of critical, internet-facing mobile apps, mobile payment app controls, two-factor authentication and data protection
- Main reference
- RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026
The RBI texts behind your mobile channel
The 2026 directions consolidate and replace earlier RBI instructions for banks, and similar entity-specific directions cover other regulated entities. The dates below are for the texts cited on this page.
- 2 June 2016
Cyber Security Framework in Banks
RBI issues RBI/2015-16/418, the first dedicated cyber security framework for banks: a Board-approved cyber security policy, a Security Operations Centre and a Cyber Crisis Management Plan. The 2025 digital banking channels directions still cite it as a reference.
- 18 February 2021
Digital payment security controls
The Master Direction on Digital Payment Security Controls sets the first dedicated mobile payments application chapter: device policy enforcement, root and jailbreak checks, device binding, re-authentication and no sensitive data on the device.
- 7 November 2023
IT governance directions
The Master Direction on IT Governance, Risk, Controls and Assurance Practices applies from 1 April 2024 and sets VA at least once every six months and PT at least once in 12 months for critical systems and for DMZ systems with a customer interface.
- 8 May 2025
Digital lending directions
The Digital Lending Directions, 2025 restrict what lending apps may access on a phone, require digital lending data to be stored on servers in India, and require compliance with the RBI cybersecurity standards.
- 25 September 2025
Authentication directions
The Authentication Mechanisms for Digital Payment Transactions Directions, 2025 require at least two factors of authentication for domestic digital payment transactions, at least one of them dynamic or non-replicable, with compliance by 1 April 2026.
- 28 November 2025
Digital banking channels directions
The Digital Banking Channels Authorisation Directions, 2025 apply from 1 January 2026 and reference the RBI cybersecurity and digital payment security texts as the security baseline for internet and mobile banking.
- 13 November 2025
DPDP Rules, 2025
MeitY notifies the Digital Personal Data Protection Rules, 2025 under the DPDP Act, 2023: security safeguards such as encryption, obfuscation and masking, logs kept for one year, and breach intimation to data principals and to the Data Protection Board.
- 31 July 2026
The 2026 directions
RBI issues the Commercial Banks cybersecurity and digital payment security directions, effective immediately. They carry the six-month VA and annual PT cadence, provide for red teaming exercises, require cyber incidents to be reported within six hours on the DAKSH platform, and repeal the earlier cybersecurity framework and IT governance instructions for commercial banks.
The RBI's rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team. Paragraph references are to the July 2026 directions unless another text is named.
- RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphs 149 to 161
Test critical, internet-facing apps at fixed intervals
What the text says
Conduct VA and PT exercises periodically for all critical and internet-facing systems, and periodically conduct VA and PT of critical, internet-facing web and mobile applications throughout their lifecycle, including pre-implementation, post implementation and after changes. For critical information systems, and for systems in the DMZ with a customer interface, conduct VA at least once every six months and PT at least once in 12 months; for other systems, adopt a risk-based approach. Post-implementation testing is performed on the production environment, or on a test environment that resembles production with any deviation documented and approved. Fix identified vulnerabilities in a time-bound manner, and put the closure status to the IT Strategy Committee and the Information Security Committee at least quarterly.
What it means for your mobile app
Your mobile app is a critical, internet-facing application with a customer interface. It needs a twice-yearly VA, an annual PT, and testing after every change, not only once at launch.
How Ostorlab helps
Mobile SAST analyses the binary, including embedded SDKs, and Mobile DAST tests the running app; both run in CI/CD. The AI-agent pentest tests the app and its APIs behind login, with a working exploit you can replay for each AI-agent finding.
What stays with you
Setting the scope and frequency for servers and network components, appointing the VA and PT auditors, and reporting closure to the committees.
- RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraph 68; Master Direction on Digital Payment Security Controls, 18 February 2021, Chapter IV, for the earlier wording
Apply the mobile payments application controls
What the text says
The mobile payments application controls require the bank to be able to verify the app version before transactions are enabled, and to implement device policy enforcement based on the bank's risk assessment, including checks for a vulnerable operating system, vulnerable or malicious applications and insecure Wi-Fi configurations; application sandboxing or containerisation and encryption; minimal data collection and permissions; identifying remote access applications and prohibiting login from them; and code obfuscation. Older app versions must be deactivated in a phased, time-bound manner, not exceeding six months from the release of a newer version. The bank must host the checksum of the current active version on a public platform, implement device binding, require re-authentication after a period of inactivity and on each launch, and identify connections from unsecured networks. The bank may also validate the security and compatibility of the device, operating system and application, and may check whether a device is rooted or jailbroken before installation and prevent the app from installing or running if it is.
What it means for your mobile app
These are controls your app either has or does not have, and each one is testable on the build customers download: root and jailbreak checks, remote access detection, obfuscation, version checks and device binding.
How Ostorlab helps
Mobile Shielding Scan tests root and jailbreak detection, anti-tampering and pinning at runtime, and shows which protections held and which were bypassed. Ostorlab also reports the app version, permissions and network connections it observes.
What stays with you
Writing the device policy, hosting the checksum, keeping the device binding records and notifying customers of new device registrations.
- RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphs 27 to 39; Cybersecurity Directions, 2026, paragraphs 83 to 87
Build security in and test before and after release
What the text says
Follow a secure by design approach and embed security across the application lifecycle: security objectives at the requirements, design, development, testing, implementation and decommissioning phases; threat modelling; secure coding practices; and security testing aligned with global standards, including OWASP and OWASP MASVS. Conduct security testing, including source code review, VA and PT, of digital payment applications: VA at least half-yearly, PT at least annually, and both whenever a new application or infrastructure is introduced or a major change is made. Where the source code is not owned by the bank, obtain a certificate from the application developer that the application is free of known vulnerabilities, malware and covert channels. Compare results with earlier scans to confirm there is no recurrence, and fix vulnerabilities in a time-bound manner. The cybersecurity directions add application security testing of web and mobile applications throughout their lifecycle, in an environment resembling production.
What it means for your mobile app
Every release is a change to an internet-facing channel. Automated testing in the pipeline covers the before; scans of store releases cover the after.
How Ostorlab helps
Ostorlab runs automated scans from your CI/CD pipeline on every build and monitors store releases without manual triggers. Mobile SAST works on the APK, AAB or IPA, with no source code needed.
What stays with you
Security requirements, threat models, secure coding standards, source code reviews and release approval.
- RBI (Authentication mechanisms for digital payment transactions) Directions, 2025, paragraphs 6, 8 and 9
Two factors, one of them dynamic
What the text says
All digital payment transactions must be authenticated by at least two distinct factors, unless exempted, and for transactions other than card present transactions at least one factor must be dynamically created or proven, meaning the proof sent as part of the transaction is unique to that transaction. The factor must be robust: compromise of one factor must not affect the reliability of the other. Issuers may offer a choice of factors, may add risk-based checks based on behaviour and context such as location and device attributes, and must ensure the robustness and integrity of the mechanism before deployment. If a loss arises from a transaction that did not comply, the issuer must compensate the customer in full without demur. Compliance was required by 1 April 2026.
What it means for your mobile app
The second factor has to be enforced by the server on every payment, and it has to be dynamic. SMS OTP is one option, but the directions allow others, such as device binding, biometrics or PKI.
How Ostorlab helps
Authenticated testing completes SMS, email or TOTP one-time codes with your test accounts and tests MFA enforcement, step-up flows and the API calls behind payments.
What stays with you
Choosing the factors, the exemption analysis, customer communication and the compensation process.
- RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphs 107, 110 and 115; Digital Payment Security Controls Directions, 2026, paragraph 46
Authenticate customers and privileged users
What the text says
The bank must implement an authentication framework that ensures positive identity verification for customers accessing its services across all delivery channels, and act as the identity provider for customer access to partner systems using secure authentication technologies. Based on a risk assessment, it must implement two-factor or multi-factor authentication, including mandatory MFA for privileged users of critical information systems and for critical activities, and protect user credentials such as logon user IDs, authentication information and tokens against leakage and attacks. The digital payment security directions add MFA and alerts for all payment transactions, including debits and credits, new account linkages, changes to account details and revisions to fund transfer limits.
What it means for your mobile app
Login, withdrawals, beneficiary changes and limit changes are all moments where the backend must demand the right factor. Token handling on the device is part of the same control.
How Ostorlab helps
Ostorlab finds API keys, tokens and credentials in the app package and validates whether they work, and tests the APIs for broken authorization (BOLA, BFLA, IDOR) and misuse of tokens and sessions.
What stays with you
Identity proofing, privileged access management, access reviews and the choice of authentication technologies.
- RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphs 48 to 51
Sessions, failed attempts and alerts
What the text says
An authenticated session and its encryption protocol must remain intact throughout the interaction; if there is interference, or the customer closes the application, the session must be terminated and affected transactions resolved or reversed out, with the customer notified promptly. The bank must set the maximum number of failed login or authentication attempts after which access is blocked, have a secure reactivation procedure and notify the customer of failed attempts. It must also implement measures against man-in-the-middle, man-in-the-browser and man-in-the-application attacks, so that data in transit is secured and transactions are authenticated only from a genuine source or process.
Source:RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphs 48 to 51
What it means for your mobile app
Session handling is testable behaviour: timeouts, token refresh, invalidation on logout or app close, lockout after failed attempts, and the API calls behind each of them.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and lockout, together with the API calls behind them, and reports reproduction steps for each finding.
What stays with you
Alert channels, the reactivation process and the fraud monitoring rules that consume the alerts.
- RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphs 22, 24 and 68(10) to 68(13); Digital Lending Directions, 2025, paragraphs 12 and 13
Protect data on the device and in transit
What the text says
Web applications must not store sensitive information in HTML hidden fields, cookies or other client-side storage. Cryptographic controls must use strong key lengths, algorithms, cipher suites and protocols that are not deprecated or demonstrated insecure. The mobile application must not store or retain sensitive personal or authentication information such as user IDs, passwords, keys, hashes or hard-coded references on the device, and must securely wipe sensitive customer information from memory when the customer exits. It must limit what is written to temp files and secure anything that is, avoid raw SQL queries and SQL injection, and refuse to load web content when SSL or TLS negotiation errors are detected. Sensitive information written to the app database must be encrypted. For lending apps, the Digital Lending Directions prohibit access to phone resources such as files and media, contact lists, call logs and telephony functions, and require digital lending data to be stored on servers in India.
What it means for your mobile app
Passwords, tokens and personal data should never sit in clear text on the phone, in temp files, logs or screenshots, and should never travel unprotected to the backend.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs, temp files and screenshots, checks for misconfigurations that weaken transport and session protections, and captures file system evidence showing what was written, where and when.
What stays with you
Data classification, key management, backups, privacy notices and data loss prevention.
- RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphs 47 and 126 to 135; Digital Payment Security Controls Directions, 2026, paragraph 32
Know your components and third parties
What the text says
Maintain an up-to-date inventory of information assets, including business applications, supporting IT infrastructure, hardware, software and services, indicating their business criticality. The digital payment security directions require the bank to obtain a certificate or written confirmation from the application developer or vendor that the application is free of known vulnerabilities, malware and covert channels, whenever material changes to the code are made, and to put source code escrow or other arrangements in place for third-party licensed applications. Third-party arrangements need a vendor risk assessment proportionate to the assessed risk and materiality, due diligence and oversight, agreements that provide for audit rights, and attention to the geographic location of infrastructure and cross-border movement of data.
What it means for your mobile app
A mobile banking app bundles third-party SDKs that talk to their own backends. They belong in your asset inventory, your SBOM and your third-party risk view.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, maps them to known vulnerabilities release to release, and shows what the app and its SDKs exchange with backends over the network.
What stays with you
The asset ledger, vendor due diligence, supplier certificates, escrow arrangements and contracts.
- RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphs 37, 98 to 103 and 153
Manage vulnerabilities and patches with deadlines
What the text says
Put in place documented change and patch management policies that assess the business impact of patches, apply them securely and in a timely manner with necessary approvals, and provide a way to recover from failed deployments. Adopt a documented, risk-based strategy for maintaining an inventory of components that require patching, identifying applicable patches and applying them in time to minimise the number of vulnerable systems and the duration of exposure. Monitor software end-of-support dates and avoid outdated or unsupported software. Fix identified vulnerabilities in a time-bound manner and check that known vulnerabilities, such as those in the CVE database, do not recur.
What it means for your mobile app
The libraries and SDKs inside your app are software you ship. Each one needs a known version, a severity when a vulnerability appears, and a fix deadline you can prove.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
Patching servers and infrastructure, vendor maintenance contracts and risk acceptance decisions.
- RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraph 182; CERT-In directions No. 20(3)/2022-CERT-In, 28 April 2022; Digital Personal Data Protection Rules, 2025, rules 6 and 7
Report incidents and breaches, keep logs in India
What the text says
Cyber incidents must be reported within six hours of detection on the DAKSH platform, RBI's advanced supervisory monitoring system, and the bank must also notify CERT-In. Under the CERT-In directions of 2022, specified incidents must reach CERT-In within six hours of being noticed, ICT logs must be kept securely for a rolling 180 days within Indian jurisdiction, and system clocks must be synchronised to NIC or NPL time. Under the DPDP Rules, 2025, a personal data breach must be intimated to affected data principals without delay and to the Data Protection Board without delay, with detailed information within 72 hours, and security logs must be retained for one year.
What it means for your mobile app
A breach found through the app or an API is on the clock. The six-hour and 72-hour windows start from detection, and the evidence has to be ready.
How Ostorlab helps
Ostorlab does not report incidents to RBI, CERT-In or the Data Protection Board. It gives you the technical evidence, replayable exploits and request and response logs, that your incident and legal teams need for the report.
What stays with you
Detection and monitoring, the DAKSH and CERT-In filings, breach notification and the legal assessment.
Summary of public RBI, MeitY and CERT-In texts, checked on 27 September 2026. The July 2026 directions apply to commercial banks; RBI issued similar entity-specific directions for other regulated entities, and the 2021 and 2023 texts cited here were repealed for commercial banks on 31 July 2026. This page is not legal advice.
RBI rules, control by control
The controls the RBI texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Vulnerability assessment of critical, internet-facing mobile applicationsCybersecurity Directions 2026 para 150 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Annual penetration test of critical systemsCybersecurity Directions 2026 para 151 | Tests the app and its APIs throughout their lifecycle, including after changes, on the production or production-like build. Details | Pentest report per cycle with reproduction steps for each finding |
| Mobile payments application controlsDigital Payment Security Controls Directions 2026 para 68 | Tests root and jailbreak detection, anti-tampering, pinning, remote access detection and app version checks at runtime. Details | Which protections held and which were bypassed, on the build you ship |
| Two factors, at least one dynamic, on paymentsAuthentication Directions 2025 para 6 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind payments. Details | Findings on login and step-up flows, with reproduction steps |
| Sessions, failed attempts and lockoutDigital Payment Security Controls Directions 2026 paras 48 to 51 | Tests login and logout, token refresh, timeouts, session invalidation and lockout after failed attempts. Details | Session and token findings, with request and response logs |
| Data on the device and in transitDigital Payment Security Controls Directions 2026 paras 22 and 68(10) | Looks for tokens and personal data in storage, caches, logs, temp files and screenshots, and checks transport protections. | File system evidence showing what was written, where and when |
| APIs behind the appDigital Payment Security Controls Directions 2026 para 39 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
| Components, versions and supplier certificatesDigital Payment Security Controls Directions 2026 para 32; Cybersecurity Directions 2026 para 47 | Lists the SDKs and native libraries in each release with their versions, and maps them to known vulnerabilities. Details | Component identity, version and location in the app bundle, per release |
| Secrets and keys on the deviceDigital Payment Security Controls Directions 2026 para 68(10) | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| Testing before and after changes, fixes on a deadlineCybersecurity Directions 2026 paras 98, 150 and 153 | Mobile SAST and DAST in CI/CD on every build, tickets in the platform or in Jira and ServiceNow, and retests after the fix. Details | Scan results per build, and ticket history and retest result for each finding |
Ostorlab tests controls in the app and its APIs. CSOC monitoring, incident response and reporting, red teaming, backups and recovery, governance, vendor contracts and IS audit stay with your teams.
RBI controls to test in your mobile app
A practical list for security and system risk teams, based on the July 2026 directions, the authentication directions of 2025, the CERT-In directions and the DPDP Rules.
Scope and cadence
Put the mobile app and its APIs in the VA and PT scope with a six-month VA and an annual PT, and test after every major change.
Before and after release
Run automated tests on every build and scan each store release, in an environment that resembles production.
Mobile app controls
Check device policy enforcement, root and jailbreak detection, remote access application detection, obfuscation and version retirement.
Data on the device
Look for user IDs, passwords, keys and hard-coded references in storage, temp files, logs and memory, and verify the encryption of the app database.
Authentication and sessions
Verify two factors with one dynamic on payments, and test session termination, lockout and failed-attempt notifications.
Components and deadlines
Keep a versioned list of the SDKs and libraries in each release, with supplier certificates and fix deadlines by severity.
Evidence for the committees
Keep VA and PT reports, fix timelines and retest results, and report closure status to the IT Strategy and Information Security Committees quarterly.
Incidents and logs
Prepare the six-hour DAKSH and CERT-In reporting path, keep 180 days of ICT logs in India, and the breach intimation steps under the DPDP Rules.
A suggested list, not an RBI template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026RBI/DoS/2026-27/410, DoS.CO.CSITEG.4/31.01.015/2026-27, 31 July 2026, effective immediately. Baseline cybersecurity and resilience requirements, including application security testing, MFA for privileged users, VA and PT periodicity, red teaming, incident reporting on DAKSH within six hours, and IS audit. Repeals the earlier cybersecurity framework and IT governance instructions for commercial banks
- Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026RBI/DoS/2026-27/411, DoS.CO.CSITEG.5/31.01.015/2026-27, 31 July 2026, effective immediately. Application security lifecycle (paragraphs 27 to 39), authentication framework (paragraphs 41 to 51) and mobile payments application controls (paragraph 68). Repeals the digital payment security controls instructions for commercial banks
- Master Direction on Information Technology Governance, Risk, Controls and Assurance PracticesDoS.CO.CSITEG/SEC.7/31.01.015/2023-24, 7 November 2023, effective 1 April 2024. Paragraph 26 set VA at least once every six months and PT at least once in 12 months for critical systems and DMZ systems with a customer interface. The control was carried into the 2026 directions, and the Master Direction stands repealed for commercial banks
- Master Direction on Digital Payment Security ControlsDoS.CO.CSITE.SEC.No.1852/31.01.015/2020-21, 18 February 2021. Chapter IV set the mobile payments application controls: device policy enforcement, root and jailbreak checks, device binding, re-authentication and no sensitive data on the device. Repealed for commercial banks by the 2026 directions
- Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025RBI/2025-26/79, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, 25 September 2025. Minimum two factors of authentication for domestic digital payment transactions, at least one dynamically created or proven, to be complied with by 1 April 2026
- Reserve Bank of India (Digital Lending) Directions, 2025RBI/2025-26/36, DOR.STR.REC.19/21.07.001/2025-26, 8 May 2025. Paragraph 12 restricts what lending apps may access on a phone, paragraph 13 requires digital lending data to be stored on servers in India, and paragraph 15 requires compliance with RBI cybersecurity standards
- Directions under section 70B(6) of the Information Technology Act, 2000 (CERT-In directions)No. 20(3)/2022-CERT-In, 28 April 2022, effective 27 June 2022. Cyber incidents reportable to CERT-In within six hours, ICT logs kept securely for a rolling 180 days within Indian jurisdiction, and system clocks synchronised to NIC or NPL time
- Digital Personal Data Protection Rules, 2025MeitY, G.S.R. 846(E), 13 November 2025, under the Digital Personal Data Protection Act, 2023 (Act 22 of 2023). Rule 6 security safeguards, including encryption, masking, access control and logs kept for one year, and rule 7 breach intimation: affected data principals without delay, the Data Protection Board within 72 hours
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Assess your mobile banking app the way the RBI describes it
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.