RBI digital lending security requirements govern how regulated entities, Lending Service Providers and Digital Lending Apps collect borrower data, request device permissions, store information, share it with third parties and prove that the complete lending journey is secure.
TL;DR
Under the RBI (Digital Lending) Directions, 2025, borrower data collected through a DLA must be need-based, backed by prior and explicit consent and supported by an audit trail. DLAs must not access files, media, contacts, call logs or telephony functions. Camera, microphone, location or another facility necessary for onboarding or KYC may be accessed once, with explicit consent.
Borrowers must be able to control consent, disclosure, retention and deletion. LSPs may retain only basic minimal personal data needed for their contracted service. Data must be stored on servers in India; data processed abroad must be deleted there and returned to India within 24 hours. The regulated entity remains responsible for ongoing customer-data privacy and security.
Who is responsible for digital lending security?
The regulated entity, or RE, may operate its own DLA or engage an LSP that operates one. That operating model changes who performs the work, but it does not remove the RE’s regulatory responsibility. RBI requires the RE to ensure that its LSPs and both RE-owned and LSP-owned DLAs comply.
Seven RBI digital lending security requirements
1. Need-based collection with an audit trail
Every field, document, device signal and derived data point should have a defined purpose. The RE must ensure that collection through its DLA or an LSP’s DLA is need-based and occurs only after prior and explicit borrower consent. Record the consent text, purpose, timestamp, DLA version and borrower action so the decision can be reconstructed later.
2. Granular borrower choice
The borrower must be able to allow or deny use of specific data, restrict disclosure to third parties and control retention. The journey must also support revocation of previously granted consent and, where requested, deletion or forgetting of personal data by the RE or LSP. The purpose of consent should be disclosed at every relevant interface stage, rather than hidden in a single broad acceptance.
3. Restricted mobile permissions
A DLA must not access phone resources such as files and media, the contact list, call logs or telephony functions. RBI allows one-time access to camera, microphone, location or another facility necessary for onboarding or KYC, but only with explicit consent. Product convenience is not enough; the access must be necessary for the permitted purpose.
4. Controlled third-party sharing
Personal information requires explicit borrower consent before it is shared with a third party unless the disclosure is required by law or regulation. The privacy policy should identify third parties that may collect personal information through the DLA. Maintain an accurate data-flow map so product, compliance and security teams can see where information goes after the borrower taps “allow.”
5. Minimal LSP storage and defined deletion
An LSP should not retain borrower personal information beyond basic minimal data needed to deliver the contracted service, such as name, address and contact details where required. Storage policies must define data types, retention periods, use restrictions, destruction procedures and security-breach handling, and these policies must be prominently disclosed on the relevant websites and DLA.
6. Biometric restrictions and data localisation
The RE must ensure that it and its LSP do not collect or store biometric data unless permitted under applicable statutory guidelines. Digital lending data should be stored only on servers located in India. If processing occurs outside India, the data must be deleted from those foreign servers and brought back to India within 24 hours of processing.
7. Current cybersecurity standards
The 2025 directions do not treat “cybersecurity” as a one-line app-security test. The RE must ensure that it and its LSP comply with technology and cybersecurity requirements stipulated by RBI and other relevant agencies. The exact control set therefore depends on the RE’s category and other applicable directions, including the 2026 entity-specific cybersecurity framework.
What can a Digital Lending App access?
Enforce this rule technically, not only through policy. Review Android and iOS manifests, permission prompts, SDK behaviour and runtime calls. A third-party analytics, fraud or marketing SDK can create a compliance issue even if the DLA’s own code never requests the prohibited resource.
Technical security controls behind RBI compliance
| Control area | What to implement | What proves it |
|---|---|---|
| Consent | Granular purpose-level consent, withdrawal and deletion workflows | Versioned consent text, timestamps, user action and fulfilment logs |
| Application security | Secure SDLC, SAST, dependency review, API testing, mobile VAPT and release gates | Test scope, findings, remediation tickets, retest and release approval |
| Identity and access | MFA, least privilege, privileged access monitoring and periodic reviews | Access approvals, configuration snapshots, logs and signed reviews |
| Data protection | Encryption in transit and at rest, key management, DLP and secure deletion | Configuration, key rotation, DLP alerts and destruction records |
| Infrastructure | Cloud posture management, hardening, patching, segmentation, WAF and API protection | Asset inventory, posture reports, patch evidence and alert records |
| Third parties | SDK inventory, vendor due diligence, contract controls and continuous monitoring | Assessments, data-flow map, contracts, exceptions and review records |
| Incidents | Detection, triage, containment, forensics, notification and recovery | Incident timeline, decisions, reports, lessons and corrective action |
| Localisation | India-hosted storage and controlled foreign processing | Architecture, region settings, data-transfer and deletion logs |
Testing must cover more than the user interface. Mobile, web, API, cloud and network surfaces have different weaknesses; Osto’s guide to the types of VAPT explains how to scope them. Maintain an SBOM for visibility into software components and an up-to-date risk assessment connecting technical weaknesses to borrower and business impact.
RBI digital lending security compliance checklist
- Map the operating model. Identify the RE, every LSP, every DLA, each lender relationship, third-party SDK and data processor.
- Build the data inventory. Record every field and device signal, purpose, consent basis, recipient, storage location, retention and deletion method.
- Remove prohibited permissions. Inspect app manifests, runtime requests and embedded SDKs for files, media, contacts, call logs and telephony access.
- Redesign consent where needed. Make it prior, explicit, granular, purpose-specific and auditable; add restriction, revocation and deletion workflows.
- Validate storage and localisation. Reduce LSP-held data to the contracted minimum and verify India storage plus the 24-hour foreign-processing return rule.
- Secure the complete stack. Protect mobile, web, APIs, cloud, endpoints, identities, source code, data and administrative consoles.
- Test and remediate. Run secure code analysis, dependency scanning, configuration reviews and independent VAPT; verify closure.
- Prepare CIMS certification evidence. Ensure DLA details, links, grievance information, data practices and regulatory compliance are supportable before certification.
- Monitor continuously. Reassess after releases, SDK changes, new data uses, LSP changes, incidents and regulatory updates.
Evidence the RE should retain
The CCO or board-designated official certifies DLA information submitted through RBI’s CIMS portal, including compliance of DLA data collection and storage. Certification should be backed by retrievable evidence, not a last-minute email confirmation from the LSP.
| Requirement | Evidence examples |
|---|---|
| Consent | Consent ledger, purpose, text version, timestamp, borrower choice, withdrawal and deletion completion |
| Permissions | Manifest review, screenshots, runtime test, SDK assessment and release approval |
| Data minimisation | Field-level inventory, necessity justification and approved data-flow diagram |
| LSP storage | Contract scope, data schema, retention configuration and deletion reports |
| India storage | Cloud-region settings, architecture, storage logs and foreign-processing deletion proof |
| Security testing | SAST/SCA results, VAPT report, cloud review, remediation and independent retest |
| Privacy disclosure | Published policy version, third-party list, change approval and archived copies |
| CIMS reporting | DLA inventory, certification pack, approval, submission and update history |
Common failures to avoid
- Using one bundled consent for every purpose.
- Keeping a prohibited permission because an SDK requests it by default.
- Assuming an LSP’s contract transfers responsibility away from the RE.
- Storing full borrower records at the LSP when only minimal data is necessary.
- Listing an India cloud region while backups, logs or analytics data remain abroad.
- Publishing a privacy policy that does not match the DLA’s actual data flows.
- Running annual VAPT without testing after a major release or architecture change.
- Certifying DLA compliance on CIMS without a traceable evidence pack.
Secure the DLA, the stack and the evidence.
Osto is a one-stop platform for cybersecurity and compliance. Its 21+ native modules—including WAF, EDR, CSPM, IAM, DLP and SAST—help regulated entities and digital lenders protect applications, APIs, cloud, endpoints, identities, code and data while keeping the related compliance evidence visible.
Bring application testing, cloud posture, access control, data protection, remediation and regulatory evidence into one operating view. That unified approach is why Osto is becoming the default for cybersecurity and compliance.
Book a demo →Frequently asked questions
What are RBI digital lending security requirements?
They are the technology and data obligations governing consent, device permissions, third-party sharing, storage, localisation, privacy, cybersecurity and DLA reporting under the RBI Digital Lending Directions, 2025 and other applicable cybersecurity instructions.
Can a digital lending app access contacts or call logs?
No. RBI requires DLAs of the RE and LSP to desist from accessing files and media, contact lists, call logs and telephony functions.
Can a DLA access camera, microphone or location?
Only once where the facility is necessary for onboarding or KYC, and only with the borrower’s explicit consent.
Where must digital lending data be stored?
Data must be stored only on servers located in India. If it is processed outside India, it must be deleted from the foreign server and brought back to India within 24 hours of processing.
Can an LSP store borrower personal data?
Only basic minimal personal data required to perform its operations or service within the RE-LSP agreement. The RE remains responsible for ongoing privacy and security of customer personal information.
Who is responsible if an LSP-operated DLA is non-compliant?
The regulated entity remains responsible for ensuring that the LSP and its DLA comply. Outsourcing the activity does not outsource the RE’s regulatory accountability.