DPDP compliance for Fintech, Health & EdTech

Why Regulated Companies Face a Harder DPDP Problem

If you operate in fintech, healthtech, or edtech in India, you already live under sector-specific regulators: RBI for fintech, NMC and ABDM for health, and an evolving set of guidelines for edtech. The DPDP Act does not replace these regulatory frameworks. It layers on top of them.

This creates a compound compliance problem. You must satisfy both your sector regulator AND the DPDP Act simultaneously - and where they conflict or create ambiguity, you need a defensible position on how you reconcile them.

The second problem is that regulated companies are the most likely to be designated as Significant Data Fiduciaries (SDFs). The government has not published the SDF list yet, but the Act specifies designation criteria: volume of personal data processed, sensitivity of data, risk to Data Principals, and potential impact on sovereignty and public order. Fintech companies processing millions of financial transactions, healthtech companies processing patient records, and edtech companies processing children's data tick multiple boxes.

SDF designation triggers enhanced obligations: mandatory India-based DPO, annual independent data audit, Data Protection Impact Assessments for high-risk processing, and algorithmic accountability if you use AI/ML for decisions. These are not light lifts.

Fintech: Where DPDP Meets RBI

If you are an NBFC, payment aggregator, lending platform, insurance distributor, or any entity regulated by RBI, SEBI, or IRDAI, your DPDP compliance sits inside a pre-existing regulatory stack.

The key overlaps and conflicts:

Data localisation: RBI already requires payment data to be stored in India (RBI circular on Storage of Payment System Data, 2018). DPDP's cross-border transfer restrictions add another layer - but if you are already RBI-compliant on data localisation, you are partially ahead.

Breach notification: RBI requires reporting significant cybersecurity incidents within 6 hours (RBI Master Direction on IT Framework, 2023). DPDP requires reporting personal data breaches to the DPBI within 72 hours. You must satisfy both timelines - which means your incident response workflow needs to trigger two parallel notification tracks.

KYC and consent: Fintech companies collect extensive KYC data (Aadhaar, PAN, bank statements, income proofs) under regulatory mandate. For KYC processing, you can rely on the "legitimate use" exception under Section 7(a) - consent is not required when processing is necessary for compliance with a legal obligation. But for any processing beyond KYC - marketing, cross-selling, credit scoring, behavioural analytics - you need explicit consent under DPDP.

This is where fintech companies trip up: they assume the KYC consent covers all processing. It does not. KYC consent covers identity verification and regulatory compliance. Using that same data for credit risk modelling, product recommendations, or marketing requires separate, purpose-specific consent.

Lending and automated decisions: If your lending platform uses AI/ML models for credit scoring or loan approval, DPDP creates transparency obligations. Data Principals have the right to know that automated processing is being used and to understand the logic involved. If you are designated an SDF, you may face formal algorithmic accountability requirements including bias testing and fairness documentation.

What fintech companies need to implement: - Dual breach notification workflow: RBI (6 hours) + DPBI (72 hours), triggered simultaneously - Consent architecture that separates KYC processing (legitimate use - no consent required) from commercial processing (explicit consent required) - DPA clauses with all banking and payment partners, including UPI infrastructure partners - Data principal rights portal that can handle requests from loan applicants, including deletion of KYC data after the statutory retention period - If using AI/ML for credit decisions: documentation of model logic, fairness testing, and ability to provide meaningful information to Data Principals about automated decisions

Healthtech: Where DPDP Meets Patient Privacy

Health data is the most sensitive category of personal data under any privacy framework. Under DPDP, there is no separate "sensitive personal data" category (unlike GDPR), but health data processing carries heightened risk and is more likely to trigger SDF designation and DPIA requirements.

The key healthcare-specific issues:

Patient consent: Medical professionals processing data for providing healthcare services can rely on the "legitimate use" exception under Section 7(i) - consent is not required for medical emergencies or when providing health services where obtaining consent is not practicable. But for processing beyond direct care - research, marketing, sharing with insurance companies, analytics, telemedicine platform features - explicit consent is required.

ABDM integration: If your healthtech platform integrates with the Ayushman Bharat Digital Mission (ABDM) / ABHA ecosystem, you process health data through a government digital health infrastructure. ABDM has its own consent framework (Health Data Management Policy). You need to ensure your DPDP consent architecture is compatible with ABDM's consent artefact model.

Electronic health records: Patient records must be accessible to the patient under DPDP's right of access. If your system stores records across multiple providers (as health information exchanges do), you need a mechanism to compile a complete record for a single patient across all sources - within the prescribed timeframe.

Children's health data: If your platform serves paediatric patients, you are processing children's data (under 18) AND health data. This is the highest-risk category under DPDP: verifiable parental consent is required, behavioural tracking is prohibited, and DPIA is almost certainly necessary.

What healthtech companies need to implement: - Consent architecture that separates direct care (legitimate use) from research, marketing, and secondary uses (explicit consent) - Patient data rights portal that can compile records across all integrated systems - DPIA for any processing that involves health data at scale, automated health decisions, or children's health data - DPA with every clinical partner, laboratory, pharmacy, and insurance company that receives patient data - De-identification and anonymisation protocols for research use cases (if data is truly anonymised, it may fall outside DPDP's scope - but the anonymisation must be irreversible and verified) - Breach notification that accounts for both DPBI (72 hours) and any sector-specific requirements (NMC, state health department notification if applicable)

EdTech: Where DPDP Meets Children's Data

If your users include students under 18, you face the strictest set of DPDP obligations. Section 9 of the Act creates specific requirements for processing children's data that go beyond the general framework.

The non-negotiable requirements:

Verifiable parental consent: Before processing any personal data of a child (under 18), you must obtain verifiable consent from the parent or legal guardian. "Verifiable" means a checkbox claiming "I am over 18" or "I have my parent's permission" is not sufficient. You need an actual verification mechanism - OTP to the parent's registered phone number, government ID verification, video verification, or another method appropriate to your risk level.

No behavioural tracking: You cannot track, monitor, or profile children's online behaviour for advertising or any other commercial purpose. This means: no analytics tracking of individual student behaviour for anything other than core educational functionality, no retargeting ads to students, no sharing student data with advertising platforms, and no building student behavioural profiles for commercial use.

No targeted advertising: You cannot serve targeted advertisements to children based on their personal data. If your platform is ad-supported and serves users under 18, you can only show contextual ads (based on page content), not behavioural ads (based on user data).

Data minimisation: Collect only what is strictly necessary for the educational purpose. Student name, age, grade, and learning progress are necessary. Device fingerprints, location data, and browsing behaviour outside the learning context are not.

What edtech companies need to implement: - Age-gating: verify the user's age at registration. If under 18, trigger the parental consent flow. - Parental consent mechanism: a real verification system, not a checkbox. Options include OTP to parent's phone, email verification loop, or video verification for high-risk platforms. - Parental dashboard: parents must be able to see what data is collected about their child, for what purpose, and exercise rights (access, correction, deletion) on the child's behalf. - Behavioural tracking audit: scan your entire platform for any tracking that could constitute behavioural monitoring of children. Disable it for under-18 users. - Advertising audit: if your platform serves ads, ensure no behavioural targeting is applied to under-18 users. Switch to contextual-only for this segment. - DPIA: mandatory. Processing children's data at scale is high-risk processing that requires a Data Protection Impact Assessment before the processing begins.

SDF Readiness: The Extra Layer for All Three Sectors

If you are designated a Significant Data Fiduciary, these additional obligations apply on top of everything above:

Data Protection Officer: You must appoint a DPO who is based in India, is the point of contact for the DPBI, and oversees all compliance activities. The DPO can be an existing employee with this added responsibility, or a dedicated hire. Budget: ₹12–30 lakh/year for a qualified DPO.

Annual independent data audit: An independent auditor (not your internal team, not your regular CA firm unless they have data protection expertise) must audit your DPDP compliance annually and submit a report to the DPBI. Budget: ₹5–15 lakh/year.

Data Protection Impact Assessment: Before launching any new processing activity that is high-risk (large-scale health data, financial data, children's data, automated decision-making, systematic monitoring), you must conduct a DPIA. See our Compliance Template Pack for a DPIA template.

Algorithmic accountability: If you use AI/ML for decisions that significantly affect individuals (credit scoring, insurance pricing, medical diagnosis recommendations, student performance predictions), you may need to document the logic, test for bias, and be able to explain decisions to affected individuals.

The Budget for Regulated Companies

For a regulated company with 50–500 employees:

One-time setup: ₹20–60 lakh - Legal gap analysis (sector-specific + DPDP): ₹5–15 lakh - Consent architecture redesign: ₹3–8 lakh - Data mapping and DPIA: ₹3–8 lakh - DPO recruitment or appointment: ₹2–5 lakh (recruitment cost) - Engineering: rights portal, consent management, audit logging: ₹5–15 lakh - Compliance platform: ₹3–8 lakh/year

Recurring annual: ₹15–40 lakh - DPO salary/allocation - Annual independent audit - Platform subscription - Ongoing DPIA for new processing activities - Sector-specific compliance updates - Staff training (including clinical/field staff for healthtech)

These numbers are higher than D2C or generic SaaS because the regulatory complexity is higher, the data sensitivity is higher, and the SDF probability is higher. But the penalty exposure is also higher - and for regulated companies, a DPBI enforcement action can trigger cascading scrutiny from RBI, SEBI, IRDAI, or NMC.

Regulated Sector FAQ

Q: We already comply with RBI's cybersecurity framework. Is that enough for DPDP? A: RBI cybersecurity covers security safeguards, which partially addresses DPDP Section 8(4). But DPDP adds consent management, data principal rights, breach notification to a different regulator (DPBI, not RBI), and data retention/deletion obligations that RBI's framework does not cover. Think of RBI compliance as covering ~30% of DPDP requirements.

Q: Can we use the "legitimate use" exception for all patient data processing? A: Only for direct healthcare provision and medical emergencies. Research, analytics, marketing, insurance data sharing, and any processing beyond direct care requires explicit consent.

Q: Our edtech platform is used by schools. Is the school the Data Fiduciary or are we? A: Typically, the school is the Data Fiduciary (they determine purpose and means of processing student data) and you are the Data Processor. But if you process student data for your own purposes (analytics, product improvement, marketing), you become a Data Fiduciary for that processing. Most edtech companies are dual-role, similar to SaaS companies.

Q: How do we handle parental consent at scale for 500,000 student users? A: Automated verification. OTP-based parental consent at registration is the most scalable approach: student registers → system asks for parent's phone number → OTP sent to parent → parent reviews consent notice and confirms. This can be implemented in 2–3 engineering sprints and handles scale.

Getting Started

Regulated companies have the most at stake and the most complex compliance requirements. ComplyDP's free Readiness Scan at complydp.com/scan covers all 43 DPDP controls with sector-specific context - it will flag both your general DPDP gaps and the areas where sector-specific obligations create additional risk.