Ch IPreliminary
S.1 Short title and commencementS.2 DefinitionsS.3 Application and scopeCh IIObligations of Data Fiduciary
S.4 Grounds for processingS.5 NoticeS.6 ConsentS.7 Certain legitimate usesS.8 Data Fiduciary obligationsS.9 Children’s dataS.10 Significant Data FiduciaryCh IIIRights and duties of Data Principal
S.11 Right to accessS.12 Correction and erasureS.13 Grievance redressalS.14 Right to nominateS.15 Duties of the Data PrincipalCh IVSpecial provisions
S.16 Transfer outside IndiaS.17 ExemptionsCh VData Protection Board of India
S.18 Establishment of the BoardS.19 Composition of the BoardS.20 Salary and term of officeS.21 DisqualificationsS.22 Resignation and vacanciesS.23 Proceedings of the BoardS.24 Officers and employeesS.25 Members as public servantsS.26 Powers of the ChairpersonCh VIBoard powers and procedure
S.27 Powers and functions of the BoardS.28 Procedure followed by the BoardCh VIIAppeal and dispute resolution
S.29 Appeal to the Appellate TribunalS.30 Tribunal orders as a decreeS.31 Alternate dispute resolutionS.32 Voluntary undertakingCh VIIIPenalties
S.33 Penalties and the ScheduleS.34 Penalties to Consolidated FundCh IXMiscellaneous
S.35 Good-faith protectionS.36 Power to call for informationS.37 Blocking of accessS.38 Consistency with other lawsS.39 Bar of jurisdictionS.40 Power to make rulesS.41 Laying of rules before ParliamentS.42 Power to amend the ScheduleS.43 Power to remove difficultiesS.44 Amendments to other ActsHow Non-Banking Financial Companies reconcile the Digital Personal Data Protection Act, 2023 with the RBI, KYC/PMLA, digital-lending and cybersecurity obligations that continue to apply alongside it.
The DPDP Act governs an NBFC's processing of digital personal data and applies in addition to, not in place of, RBI, PMLA/KYC, CERT-In and outsourcing rules (DPDP Act, s.38). Its main operational duties are scheduled to commence on 13 May 2027, though some institutional provisions began on 13 November 2025. The priorities are notice and lawful-basis mapping, consent where it is the basis, Data Principal rights and grievance handling, retention aligned to KYC law, processor and LSP governance, security safeguards and breach readiness. An NBFC is not automatically a Significant Data Fiduciary.
The practical question for an NBFC is not whether the DPDP Act applies — it does, to the extent you process digital personal data — but how to run it alongside the RBI, PMLA/KYC and CERT-In obligations that continue to apply under Section 38.
Last updated: 31 August 2026 · Primary authorities reviewed: DPDP Act · DPDP Rules · RBI · PMLA/KYC · CERT-In
Yes, to the extent an NBFC processes digital personal data. An NBFC will ordinarily act as a Data Fiduciary for borrower and customer personal data, because it determines why and how that data is processed. The DPDP Act applies in addition to RBI, PMLA/KYC and other sector rules, which are not displaced (DPDP Act, s.38).
The Digital Personal Data Protection Act, 2023 regulates the processing of digital personal data. An NBFC that decides the purpose and means of processing borrower or customer data is a Data Fiduciary for that processing, and carries the Act's primary duties: lawful basis, notice, security, retention limits, rights and grievance handling.
Classification is activity-specific, not entity-wide. Third parties involved in lending, KYC, collections, cloud hosting or distribution may be Data Processors acting on the NBFC's instructions, independent Data Fiduciaries determining their own purposes, or separately regulated entities. The Act's role definitions turn on that factual analysis, not on the label used in a contract.
DPDP does not switch off existing obligations: RBI directions on KYC, digital lending, outsourcing and cyber incidents, and the recordkeeping duties under the Prevention of Money Laundering Act, continue to apply alongside it. How the two frameworks interact under Section 38 is set out in the DPDP × RBI crosswalk below.
Reading "DPDP applies to NBFCs" as "every NBFC activity now needs fresh DPDP consent." Applicability is not a single lawful basis; much NBFC processing continues under existing law with DPDP obligations layered over it.
The four frameworks an NBFC must satisfy at once
Under s.38, the DPDP Act applies in addition to, not in place of, the sector frameworks.
There is no single "DPDP deadline." Commencement is phased: institutional provisions (Sections 18–26) began on 13 November 2025; Consent Manager registration provisions begin on 13 November 2026; and the main Data Fiduciary duties and most operative Rules are scheduled to commence on 13 May 2027. Existing RBI, PMLA/KYC and CERT-In duties already apply now.
Plan against the operating model that must be ready by 13 May 2027, notice, lawful basis, rights, grievance, security, breach response, processor contracts, retention and (if notified) SDF duties, while recognising that many privacy-adjacent obligations are already live under sector law.
| Date | Regulatory event | What NBFCs should have completed |
|---|---|---|
| 13 Nov 2025 | Sections 18–26 in force DPDP Act | Awareness of the Board framework; begin the processing inventory and gap review. |
| 13 Nov 2026 | Section 6(9), 27(1)(d), Rule 4 DPDP Rules | Decide whether Consent Manager arrangements are relevant; design consent capture and records. |
| 13 May 2027 | Main Data Fiduciary duties; Rules 3, 5–16 DPDP Act DPDP Rules | Operating model live: notice, lawful-basis mapping, rights and grievance, security safeguards, breach runbook, processor contracts, retention/erasure, children's-data controls, and SDF duties if notified. |
The exact commencement instruments (Gazette notification G.S.R. 843(E) and DPDP Rules, Rule 1(2)) should be checked against the current MeitY text before any dated public claim, and any provision-specific change after 31 August 2026 confirmed.
Map your DPDP obligations against RBI, KYC and digital-lending rules in about 10 minutes.
Check your DPDP readinessPersonal data enters an NBFC at every stage of the loan, and each stage carries a different privacy risk and a different regulatory overlay. Mapping the lifecycle is the fastest way to see where DPDP duties, RBI rules and KYC retention actually bite.
| Lifecycle stage | Typical personal data | Main privacy risk | Applicable overlay | Priority control |
|---|---|---|---|---|
| Lead | Name, mobile, email, campaign/ad source | Marketing use without a clear basis; lead provenance | RBI conduct/communications | Separate enquiry from marketing consent; lead-source register |
| Application | Identity, address, income, employment, bank, declarations | Over-collection; unclear lawful basis; retention | RBI KYC/DLD PMLA | Field-by-field purpose review; application data dictionary |
| KYC / CKYC | PAN, ID documents, photo, address, customer ID | Assuming a single "consent" basis; excess collection | RBI KYC PMLA | Legal-basis register per field; access restriction; retention lock |
| Underwriting | Bureau, bank, income, device, alternative data | Purpose creep; accuracy; automated decisions | RBI credit/DLD | Input allow-list; model governance; human escalation; decision evidence |
| Approval / KFS | Decision data, Key Fact Statement acknowledgement | Privacy notice buried inside loan terms | RBI KFS/DLD | Keep privacy notice separate from the loan agreement and KFS |
| Disbursement | Bank details, loan account, transaction data | Third-party processing; storage location | RBI DLD/payment (where applicable) | Payment-data segregation; India-storage analysis in the DLD context |
| Servicing | Account, repayment, communications, complaints | Service vs marketing purpose separation; rights | RBI conduct/KYC refresh | Role-based access; channel-preference management |
| Collections | Contact, repayment status, field/call notes | Excessive disclosure; harassment risk | RBI recovery/fair-practices | Need-to-know data packs; no contact-list misuse; agent monitoring |
| Closure | Identity, loan and repayment records, NOC | Erasure request vs statutory retention | RBI KYC PMLA | Closure-triggered retention clock; segregated archive; marketing suppression |
| Retention / Deletion | Records under statutory retention or legal hold | Deleting records a law requires kept, or keeping data with no basis | PMLA/KYC DPDP s.8(7) | Retention schedule by authority; delete non-required data; legal-hold override |
Not every NBFC uses every stage or data category; treat this as a mapping template, not a claim about a specific lender.
They operate concurrently. An NBFC generally has to satisfy both frameworks; RBI obligations are not displaced by the DPDP Act. DPDP s.8(7) expressly accommodates retention required by other laws, and DPDP s.38 states the Act applies in addition to and not in derogation of other laws. Only where an actual conflict exists does s.38(2) make DPDP prevail, and then only to the extent of that conflict. Most differences between RBI and DPDP are not conflicts.
DPDP and RBI often regulate the same processing for different reasons: DPDP for personal-data protection, RBI for prudential, conduct and financial-integrity purposes. The crosswalk below maps common issues, and names which regulator creates each obligation. RBI Digital Lending Directions apply to digital-lending activity, not to every NBFC operation.
How the layers stack
| Processing issue | DPDP position | RBI / other position | Practical NBFC control | Authority |
|---|---|---|---|---|
| Notice | Clear notice for processing, once Rules operative | Digital lending: DLA/LSP must publish a privacy policy | Keep the DPDP notice separate from the loan agreement | Rule 3 RBI DLD |
| Consent | Where consent is the basis, meet the s.6 conditions | Digital lending: prior and explicit borrower consent with audit trail for DLA data collection | Build a consent record meeting RBI's requirement; separately confirm the DPDP basis | s.6 RBI DLD |
| Contacts, call logs, files | No DPDP list of prohibited phone permissions | Digital lending: DLAs must not access contacts, call logs, files/media or telephony functions | Technically block these permissions in the DLA; verify SDKs and third-party code | RBI DLD |
| Camera, microphone, location | Lawful, purpose-limited processing; no general one-time-access rule | Digital lending: one-time access only where necessary for onboarding/KYC, with explicit consent | Just-in-time permission screens; no background or persistent access | RBI DLD |
| LSP data storage | Fiduciary is responsible for processing carried out by a processor | Digital lending: LSP may store only minimal borrower data per the NBFC–LSP agreement | Document permitted fields, location, retention and deletion; prohibit shadow databases | s.8 RBI DLD |
| India storage | No general localisation; s.16 permits transfer unless restricted | Digital lending: DLA/LSP data on servers in India; payment-system rules where the entity/activity is covered | Map production, backups, logs, support and sub-processors; attest the architecture | s.16 RBI DLD |
| KYC retention | s.8(7) permits retention necessary for compliance with law | RBI KYC / PMLA: five-year retention baselines | Retention schedule by authority; restrict access to retained records | s.8(7) RBI KYC/PMLA |
| Grievance handling | Effective grievance mechanism and a published contact | RBI borrower grievance and escalation framework | Keep DPDP privacy grievances and RBI lending grievances distinguishable but coordinated | s.8, s.13 RBI |
| Recovery conduct | Purpose and security constraints on processing | RBI recovery-agent and fair-practices expectations | Minimise shared data; prohibit contact-list misuse; monitor agents | s.8 RBI |
| Security | Reasonable security safeguards; Rule 6 detail once operative | RBI outsourcing / IT / cyber standards | Map each control to its source; do not claim a control is DPDP-mandated when it is good practice | s.8(5) Rule 6 RBI |
| Breach reporting | Notify Board and affected persons once Rule 7 operative | CERT-In 6-hour reporting for covered incidents; RBI reporting in outsourcing/cyber contexts | One runbook with a separate clock per regulator | Rule 7 CERT-In RBI |
| Cross-selling | Separate purpose; consent and withdrawal where consent is relied on | RBI conduct and fair-practice requirements | Separate opt-in; no coercive bundling; propagate withdrawal downstream | s.4, 6, 8 RBI |
Attributing RBI's device-permission and India-storage rules to the DPDP Act. Those are RBI Digital Lending Directions requirements that apply to digital-lending activity. The DPDP Act does not itself prohibit an app from accessing contacts or mandate India-only storage.
A fast reference for the situations NBFC teams meet most often. It shows which framework drives each obligation, so responsibility is assigned to the correct regulator rather than defaulting everything to "DPDP."
| Situation | DPDP Act | RBI | PMLA/KYC | CERT-In | What the NBFC should do |
|---|---|---|---|---|---|
| Collecting borrower KYC | Lawful basis via s.4/s.7; notice | — | Required due diligence and records | — | Map the DPDP basis (often s.7, not consent); keep records per PMLA/KYC |
| Loan-app device permissions | Lawful, purpose-limited only | Prohibits contacts/logs/files; one-time cam/mic/location | — | — | Follow RBI DLD in the DLA; DPDP does not create these permission rules |
| Credit underwriting | Purpose limit; accuracy; automated-decision governance | Credit / digital-lending rules | — | — | Allow-list inputs; document decisions; enable correction |
| LSP receives borrower data | Fiduciary stays responsible (s.8) | LSP oversight and minimal storage (digital lending) | — | — | Assess the role; contract and audit; do not assume "processor" automatically |
| Marketing / cross-selling | Separate purpose; consent and withdrawal | Conduct / fair-practice | — | — | Separate opt-in; suppress on withdrawal |
| Borrower requests erasure | Erase when purpose ends, unless law requires retention (s.8(7)) | — | Five-year retention may apply | — | Delete non-required data; retain and restrict what a law requires |
| Loan closes | Re-evaluate retention under s.8(7) | — | Retention clock starts | — | Start the closure retention clock; suppress marketing; archive the minimum |
| Security incident | Reasonable-safeguards duty | Outsourcing/cyber expectations | — | 6-hour report if a covered incident | Assess CERT-In coverage; follow applicable RBI incident expectations |
| Personal-data breach | Notify Board and affected persons (Rule 7) | Context-dependent (outsourcing/cyber) | — | 6-hour if covered | Run every applicable clock in parallel; one deadline does not cover all |
| Overseas cloud / vendor | s.16 transfer unless restricted | India storage (digital lending); payment rules if covered | — | — | Localisation analysis by workload; DPA and sub-processor controls |
Not automatically. KYC is usually performed because RBI and PMLA require customer due diligence, so the NBFC should first identify the DPDP lawful basis for the exact activity, often a certain legitimate use under s.7 or consent under s.6, rather than assuming consent is the only route. A regulatory obligation to perform KYC explains why data is collected; it does not by itself create a standalone DPDP lawful basis. Where consent is relied on, for optional or non-required data, it must meet s.6. RBI's digital-lending consent rules apply separately to app data collection.
Under s.4, personal data may be processed for a lawful purpose either with consent (s.6) or for a certain legitimate use (s.7). Analyse three layers separately for any NBFC workflow, and do not collapse them into one "I agree" checkbox.
| Layer | What it answers | Source |
|---|---|---|
| Initial processing basis | Why the NBFC may process the data under DPDP (s.6 consent or s.7 legitimate use, by activity) | DPDP s.4, 6, 7 |
| Regulatory requirement | Why the NBFC is required to collect or verify the information | RBI KYC PMLA |
| Retention | Why the NBFC may keep the information even after the original basis changes | DPDP s.8(7) |
Where consent is relied on, keep it unbundled. Different processing has different necessity, legal basis and withdrawal consequences.
| Keep separate | From | Why |
|---|---|---|
| Privacy notice | Loan agreement / KFS | The notice must be understandable on its own; burying it in contract terms defeats that |
| Loan-agreement acceptance | Marketing permission | Acceptance needed for the loan must not force optional promotional processing |
| Mandatory KYC acknowledgement | Optional data / device permissions | Required onboarding data and optional data have different necessity and withdrawal effects |
| Marketing / cross-sell consent | Core loan servicing | Withdrawing marketing consent must not impair servicing of the existing loan |
| Account Aggregator consent artefact | General privacy notice | AA consent is purpose-, data-, recipient- and time-specific within the AA ecosystem |
One bundled "I agree" covering the notice, the loan contract, marketing and device permissions. It muddles the lawful basis, breaks withdrawal, and conflicts with the separation RBI's digital-lending framework expects for app permissions.
No, not where a law requires the data to be kept. DPDP s.8(7) requires erasure when consent is withdrawn or the purpose is served, unless retention is necessary for compliance with law. RBI KYC Directions require transaction records for at least five years from the transaction date, and customer-identification and address records for at least five years after the business relationship ends. Retained data should be access-restricted and not repurposed; non-required data should be deleted.
Erasure request — what to do
| Record | Why retained | Legal / regulatory basis | Minimum / required period | DPDP treatment after purpose ends |
|---|---|---|---|---|
| Transaction records | Reconstruct transactions; AML | RBI KYC para 46(a); PMLA | ≥ 5 years from transaction date | Retain under s.8(7); restrict access |
| Identity / address records | Customer due diligence | RBI KYC para 46(b); PMLA | ≥ 5 years after relationship ends | Do not delete solely on an erasure request while the clock runs |
| PAN / ID documents / photos | Identification | RBI KYC; PMLA | Within identity-record analysis | Restrict; never repurpose for marketing |
| Loan agreement / repayment evidence | Contract, limitation, tax, litigation | PMLA + limitation/tax/contract | Data-by-data schedule | Map each category to an authority; no single "financial data" bucket |
| Credit-bureau enquiry / report | Underwriting, audit, dispute | CICRA/CIC + contract | Purpose / necessity based | Keep enough for audit and dispute; not indefinite by default |
| Account Aggregator data | Consented underwriting/servicing | RBI AA framework + s.8(7) | Consent + legal retention | No reuse beyond the consented purpose |
| Marketing preferences / consent evidence | Honour withdrawal | DPDP (no PMLA rule) | Minimal do-not-contact token | Delete after a defensible period; keep only the suppression token |
| Device / behavioural / analytics | Fraud, security, analytics | DPDP s.8(7) + design | Short unless fraud/legal basis | Delete when the purpose ends and no hold applies |
DPDP erasure does not require deleting records that another law requires the NBFC to retain. Retain only what the law requires, restrict access and reuse, document the basis and period, and delete or irreversibly de-identify the rest once no continuing purpose or legal obligation exists.
Older sources may state a ten-year KYC/PMLA retention period. The current RBI KYC baseline is five years as described above; validate against the consolidated RBI KYC Directions and PML Rules current for your NBFC category before publishing a period.
The NBFC remains responsible. Under DPDP, a Data Fiduciary is responsible for processing carried out on its behalf by a Data Processor, so contractual recovery from an LSP does not remove the NBFC's regulatory exposure. RBI's digital-lending and outsourcing directions also place independent oversight duties on the NBFC. Whether a given party is a processor, an independent Data Fiduciary, or a separately regulated entity depends on what it actually determines and does, not on the label in a contract.
Do not classify every counterparty as a processor. Role follows function: some parties process only on the NBFC's instructions, others determine their own purposes, and some are separately regulated.
| Third party | Likely DPDP role | Key risk | Required NBFC governance |
|---|---|---|---|
| NBFC | Data Fiduciary (usually) | Owns the lending journey | Full programme: basis, notice, rights, security, breach, contracts |
| Lending Service Provider | Processor or independent Fiduciary | Reuse or independent decisions change the role | Role assessment; DLD minimal-storage terms; audit and access controls |
| DSA | Processor, Fiduciary, or both | May source and use leads independently | Lead provenance; permitted-use terms; no unauthorised reuse |
| Recovery agency | Usually processor | Accesses debtor data | Minimum data pack; conduct rules; call/field monitoring; deletion on assignment end |
| Cloud / SaaS provider | Usually processor | Independent telemetry, analytics, data location | DPA; sub-processor approval; India-storage review; encryption; exit/deletion |
| KYC provider | Processor or independent Fiduciary | May run its own regulated service | Purpose restriction; authentication/audit evidence; retention terms |
| Credit Information Company | Usually separate/independent Fiduciary | Has its own statutory purposes | Clear notices; lawful sharing; route disputes to the CIC process |
| Account Aggregator | Separate regulated entity | Manages consent artefacts and FI-data flow | Consent-artefact validation; minimisation; retention limits |
| Co-lending partner | Separate or joint Fiduciary | Makes independent lending decisions | Role-allocation schedule; rights routing; breach protocol |
RBI outsourcing directions require the NBFC to preserve the confidentiality and security of customer information with providers, restrict access on a need-to-know basis, monitor provider controls, and be told of breaches, with immediate RBI notification for security or confidentiality breaches. Outsourcing does not remove NBFC accountability.
Contract controls (permitted purpose, no reuse, India-storage where DLD applies, MFA/logging, sub-processor approval, incident notice, deletion at termination, audit rights) are implementation controls informed by DPDP processor accountability and RBI oversight, not word-for-word DPDP text.
No. An NBFC is not automatically a Significant Data Fiduciary because of its size, digital-lending model or use of financial data. SDF status arises only when the Central Government notifies a Data Fiduciary, or a class, after assessing the s.10 factors: volume and sensitivity of data, risks to Data Principals' rights, and risks to sovereignty, electoral democracy, state security and public order. If notified, extra duties apply.
Section 10 lists the factors the Central Government weighs. It does not say all NBFCs, all large NBFCs, or all entities processing financial data are SDFs. Size and financial-data processing may be relevant to a risk assessment, but neither is an automatic trigger.
Once notified, an SDF must appoint an India-based Data Protection Officer answerable to its board, appoint an independent data auditor, and run periodic Data Protection Impact Assessments and audits (at least once every 12 months under Rule 13). A non-SDF Data Fiduciary does not need a statutory DPO, but must publish the contact of a person able to answer questions about its processing (s.8).
Declaring that a particular large NBFC "is" or "will be" an SDF. Use SDF exposure and readiness language; designation is a Central Government decision that has not been made merely because an entity is big or digital.
Handle each request as: DPDP requirement, then regulatory limitation, then operational workflow. Keep DPDP personal-data rights distinct from RBI consumer-grievance routes, even if a single portal collects both.
| Request | DPDP treatment | RBI / other overlay | Operating response |
|---|---|---|---|
| Access to information | Provide a summary of data, processing and recipients | CIC/AA disclosure mechanics may be separate | Central rights workflow; identify categories, purpose and recipients |
| Correction | Correct, complete or update | KYC update; CIC dispute is a separate process | Verify; update source systems; notify processors/recipients |
| Credit-bureau dispute | Accuracy request may intersect the CIC process | CICRA/CIC dispute mechanism | Route to the formal CIC dispute process; preserve evidence |
| Erasure during active loan | Data may remain necessary for servicing and regulation | RBI KYC/PMLA; active contract | Explain retained categories and basis; delete optional data |
| Erasure after closure | Evaluate each dataset; preserve required records | Five-year KYC/PMLA baseline | Archive the minimum; erase the rest; confirm transparently |
| Grievance | Effective grievance mechanism required | RBI grievance/ombudsman may apply independently | Separate privacy case type; clear escalation pathway |
| Nomination | Recognised under DPDP | Estate/succession rules affect actual servicing | Capture/verify nomination separately from any loan nominee |
| Withdraw marketing consent | Stop consent-based marketing | Service communications may continue | Suppress across CRM, SMS, WhatsApp and LSP systems |
| Withdraw optional app permission | Cease optional collection; assess necessity | RBI DLD governs permitted permissions | Stop optional collection; explain any KYC/onboarding impact |
Separate what the law requires from what is good practice. DPDP sets a duty of reasonable security safeguards; the Rules add detail once operative; RBI adds sector controls; and everything else is implementation practice that helps satisfy those duties.
| Requirement | Status / source |
|---|---|
| Protect personal data by taking reasonable security safeguards to prevent a breach | DPDP s.8(5) |
| Prescribed safeguards: encryption/masking, access control, logging and monitoring, backups, incident-response, processor-contract safeguards | DPDP Rule 6 (from 13 May 2027) |
| Notify the Board and affected Data Principals of a breach in the manner/time prescribed | DPDP s.8(6) Rule 7 |
| Preserve confidentiality/security with providers; need-to-know access; monitoring; breach disclosure | RBI outsourcing |
| NBFC/LSP technology and cybersecurity standards for digital lending | RBI DLD |
| Report designated cyber incidents within six hours; retain logs | CERT-In |
| Zero trust, MFA, DLP, red-team testing, tabletop exercises, data classification, independent assurance | Implementation / good practice |
Presenting a specific control (for example a named encryption standard or MFA everywhere) as individually mandated by the DPDP Act. The Act requires reasonable safeguards; the specific control is usually a sensible way to meet that duty, not statutory text.
There is no single deadline; multiple clocks can run at once. Once DPDP Rule 7 is operative, notify affected Data Principals and the Data Protection Board without delay, with a detailed Board report generally within 72 hours unless extended. CERT-In requires covered cyber incidents within six hours. RBI reporting depends on the applicable outsourcing or cyber direction and the NBFC's category. Run each applicable clock in parallel.
| Authority | Trigger | Initial notification | Follow-up | Source |
|---|---|---|---|---|
| Data Protection Board of India | Personal-data breach | Without delay after becoming aware | Detailed report within 72 hours, unless extended by the Board | DPDP Rule 7 |
| Affected Data Principals | Personal-data breach | Without delay, in clear and plain language | Ongoing updates as appropriate | DPDP Rule 7 |
| CERT-In | Covered cyber incidents (Annexure I) | Within 6 hours of noticing or being made aware | Cooperation as sought; retain logs as directed | CERT-In Directions 2022 |
| RBI | Security/confidentiality breach; applicable incidents | Context-dependent (outsourcing: immediate; certain directions: a six-hour vendor-to-NBFC escalation) | Per the applicable RBI direction and NBFC category | RBI outsourcing/cyber |
There is no single "RBI breach deadline" for every NBFC. The applicable RBI clock depends on the specific instrument and the class or activity of the NBFC.
The breach clocks run in parallel
Do not publish a universal RBI six-hour external-reporting deadline for every NBFC incident. RBI supports immediate notification for security/confidentiality breaches in outsourcing contexts and a vendor-to-NBFC six-hour escalation in certain directions; confirm the exact clock against your NBFC category and the current RBI instrument.
No. The DPDP Act does not impose general India-only storage. Section 16 permits cross-border transfer unless the Central Government restricts destinations. Separate RBI rules do the localising: the Digital Lending Directions require India-server storage for covered digital-lending data, and the payment-system data direction requires India storage for covered payment-system providers. Applicability turns on the entity and activity, not on being an NBFC.
| Question | Position | Source |
|---|---|---|
| Does DPDP require all NBFC data in India? | No; s.16 permits transfer unless the Central Government restricts destinations | DPDP s.16 / Rule 15 |
| Must digital-lending data be stored in India? | Yes for covered digital-lending data; an RBI requirement, not a general DPDP rule | RBI DLD |
| Are payment-system data India-stored? | Yes for covered payment-system providers; applicability turns on being such a provider | RBI payment-system direction |
| Can an NBFC use foreign cloud/SaaS? | Requires an activity-, data-, role- and regulator-specific analysis | Assessment |
| Do backups, monitoring and support count? | Yes; map production, backups, DR, logs, support access, analytics and sub-processors | Implementation |
Applying payment-system localisation to an NBFC simply because payments occur during a loan. Payment-system storage rules apply to relevant authorised or approved payment-system providers, and must be assessed against the entity and activity.
The DPDP Schedule sets different maximum penalties for different failures. A flat "250 crore" figure is wrong: that is the maximum for a security-safeguards failure resulting in a breach, decided by the Board (s.33) after a process, not an automatic fine for any lapse.
| Failure type | Maximum penalty | NBFC relevance | Qualification |
|---|---|---|---|
| Failure to take reasonable security safeguards resulting in a breach | Up to ₹250 crore | Cyber, vendor governance, cloud/DLA/LSP access, breach prevention | Maximum, not automatic; the Board determines the penalty |
| Failure to notify a breach | Up to ₹200 crore | Incident response and notification readiness | Applies to breach-notification failure |
| Failure re children's data | Up to ₹200 crore | Where the NBFC processes children's data | Not universal to standard adult lending |
| Failure re SDF additional obligations | Up to ₹150 crore | Only after SDF notification | Does not apply to all NBFCs |
| Failure re other Act/Rules provisions | Up to ₹50 crore | Notice, rights, grievance, processor obligations | Provision and facts matter |
| Data Principal breach of duties | Up to ₹10,000 | Not central to NBFC exposure | Do not use this to discourage complaints |
An incident can create parallel exposure under DPDP enforcement, RBI outsourcing/digital-lending/cyber supervision, CERT-In directions, PMLA/KYC duties, payment-system requirements where applicable, and contractual or consumer claims. Compliance with one regulator does not resolve another's requirements.
An operating checklist in eight phases. Each control is labelled by its source so responsibility is assigned to the right framework, and nothing good-practice is mistaken for statutory text.
A printable version of the eight-phase checklist, labelled by DPDP, RBI, PMLA/KYC and CERT-In.
Request the checklistYes, to the extent an NBFC processes digital personal data. An NBFC is ordinarily a Data Fiduciary for borrower and customer data because it decides why and how that data is processed, and it carries the Act's duties in addition to RBI, PMLA/KYC and other sector rules (s.38).
Yes, and it is phased. Institutional provisions began on 13 November 2025 and Consent Manager registration provisions begin on 13 November 2026, but the main Data Fiduciary duties and most operative Rules are scheduled to commence on 13 May 2027. RBI, PMLA/KYC and CERT-In duties already apply now.
Not automatically. KYC is performed because RBI and PMLA require it, so the NBFC should identify the DPDP basis for the specific activity, often a certain legitimate use under s.7 or consent under s.6, rather than assuming consent is the only route. A duty to perform KYC does not by itself create a standalone DPDP lawful basis.
Not where a law requires retention. DPDP s.8(7) requires erasure once consent is withdrawn or the purpose is served, unless retention is necessary for compliance with law. RBI KYC and PMLA require records for at least five years, so the NBFC retains and restricts those records and deletes non-required data.
Generally no. Under s.38 the DPDP Act applies in addition to, not in derogation of, other laws. Both frameworks usually operate together. Only where there is an actual conflict does s.38(2) make DPDP prevail, and then only to the extent of that conflict.
No. SDF status arises only when the Central Government notifies a Data Fiduciary or class after assessing the s.10 factors. Size, a digital-lending model or the use of financial data may be relevant to that assessment but do not trigger designation automatically.
No. A DPO is a statutory requirement for a notified SDF, who must appoint an India-based DPO answerable to the board. A non-SDF NBFC does not need a statutory DPO but must publish the contact of a person who can answer questions about its processing.
Not automatically. An LSP may be a processor, an independent Data Fiduciary or another relationship depending on what it decides and does. Either way, the NBFC remains responsible under DPDP for processing carried out on its behalf, and RBI oversight duties also apply.
There is no single deadline. DPDP Rule 7 requires notifying affected people and the Board without delay, with a detailed Board report generally within 72 hours unless extended. CERT-In requires covered incidents within six hours. RBI reporting depends on the applicable direction and NBFC category. Run each clock in parallel.
For digital lending, RBI's Digital Lending Directions prohibit lending apps from accessing contacts, call logs and files/media, and allow one-time access to camera, microphone or location only where necessary for onboarding or KYC and with consent. This is an RBI requirement; the DPDP Act does not itself create these permission rules.
The DPDP Act does not impose general India-only storage; s.16 permits transfer unless the Central Government restricts destinations. India storage comes from RBI rules: the Digital Lending Directions for covered digital-lending data, and the payment-system data direction for covered payment-system providers.
This guide is written for compliance, legal, risk, technology and product teams at NBFCs preparing for the DPDP Act alongside their existing RBI, PMLA/KYC and CERT-In obligations. The editorial approach is to label every requirement by source, separate statutory duties from good practice, and name the specific regulator behind each obligation rather than blending them.
Last updated: 31 August 2026. Primary authorities reviewed: DPDP Act, 2023; DPDP Rules, 2025; RBI directions (KYC, digital lending, outsourcing, payment-system data); PMLA and PML (Maintenance of Records) Rules; and CERT-In Directions. Each material statement is classified as a DPDP Act requirement, a DPDP Rules requirement, another regulator's requirement (RBI, PMLA/KYC or CERT-In), or an implementation recommendation.
Confirm the following against current official texts before this page is published or relied upon:
Turn this into a mapped remediation plan with a DPDP compliance assessment for your NBFC.
Start with an assessmentRelated sector: DPDP Act compliance for banks · Fintech & BFSI hub
Consultant-led and partner-backed.