At a glance
The DPDP Act doesn’t carve out a special “sensitive personal data” category the way GDPR or India’s old IT Rules did — health and financial data get the same baseline consent, notice and security rules as any other personal data, not an automatically stricter tier. For a broker, the real risk isn’t a special classification; it’s getting the basics wrong on consequential data — the fix is the same controlled-intake discipline that applies to any client document, applied to policy applications, underwriting detail and claim files.
Educational resource only. This explains how India’s Digital Personal Data Protection Act, 2023 (DPDP Act) applies to the health and financial data insurance brokers handle, and what to put in place when sharing it with insurers; it is not formal legal advice.
The situation
Brokers handling health declarations, medical underwriting reports and financial statements often assume — reasonably, given how other privacy regimes work — that this data sits in a legally stricter category with extra rules attached. The DPDP Act doesn’t work that way, and understanding why matters for where a broker should actually be spending its compliance effort.
Does DPDP treat health and financial data specially?
No — the DPDP Act applies one uniform baseline to all personal data, without a “sensitive personal data” tier. This is a deliberate departure from the earlier IT Rules’ Sensitive Personal Data or Information (SPDI) framework and from GDPR’s special-category model, both of which impose extra rules for health, financial and similar data. Under the Act, a client’s medical history and their name carry the same core duties: notice, a lawful basis, minimisation, security, and the ability to fulfil rights requests. The Act’s children’s-data provisions are the closest thing to a special category, and health/financial data isn’t automatically part of that.
What a broker actually handles
- Health declarations and medical underwriting reports — pre-existing conditions, medical history, sometimes third-party medical records requested for underwriting.
- Financial detail — income proof, bank statements, sometimes investment portfolios for high-value life or investment-linked products.
- Claim files — hospital bills, diagnostic reports, treatment records submitted at claim time, often the most detailed health data in the entire relationship.
- Identity and KYC — PAN, Aadhaar and other ID, standard across financial-services intake.
Sharing data with insurers: the processor question
Passing client data to an insurer for underwriting or claims isn’t a data leak waiting to happen — it’s a designed part of the relationship, but it still needs a clear basis and a defined relationship. The Insurance Regulatory and Development Authority of India’s (IRDAI) own outsourcing framework already expects insurers to govern how third parties (including intermediaries) handle policyholder data on their behalf. Under the DPDP Act, the broker is typically the party first collecting the client’s consent and data, then sharing it onward to the insurer for the purpose the client was told about (obtaining a quote, underwriting, or processing a claim) — a use the client’s original consent should already cover, provided the notice named the insurer-sharing step rather than describing it vaguely. Where a broker also works with a third-party administrator (TPA) for claims processing, that’s an additional party the client’s notice should account for.
Building a broker’s data-handling baseline
Treat health and financial documents with the same controlled discipline as any other sensitive client file — the DPDP Act doesn’t ask for more than that, and the stakes make less than that a bad idea anyway.
- Name every party the data will reach — the specific insurer, any TPA, any co-broker — in the notice at collection, not a generic “third parties” line.
- Route policy applications and claim documents through one controlled channel, not scattered email threads with attachments accumulating over a claim’s lifecycle.
- Limit internal access to the assigned broker/team handling the specific client relationship.
- Set a retention schedule for policy and claim files distinct from general correspondence — IRDAI and insurer-specific record requirements will typically set the floor; delete what’s left over once neither applies.
- Don’t let “it’s for underwriting” become a blanket licence — a client’s health declaration collected for one policy application isn’t automatically reusable for an unrelated cross-sell without fresh notice.
Cashless claims: the hospital-TPA-insurer data flow
A cashless hospitalisation claim moves a client’s health data through more hands, faster, than almost any other transaction a broker touches — hospital, third-party administrator (TPA), and insurer all need access within hours, not days, for pre-authorisation to actually work. The broker isn’t usually in the middle of this specific flow the way it is at policy-application stage — the hospital typically submits pre-authorisation requests directly to the TPA or insurer — but a broker fielding a client’s claim query, or assisting with a claim that’s stuck, ends up handling the same detailed medical and billing information (diagnosis, treatment plan, itemised hospital bill) as part of helping the client. Where a broker does step into that flow — chasing a delayed pre-authorisation, clarifying a query from the TPA — the same notice-and-minimisation discipline applies: the client should know the broker may liaise with the hospital and TPA on their behalf during a claim, and the broker shouldn’t hold onto detailed claim medical records any longer than resolving that specific claim requires. Worth naming to a client at the point they raise a claim issue, rather than assuming the original policy-purchase consent silently covers this later, different-in-character involvement.
FAQ
Does a broker helping with a cashless-claim issue need fresh consent from the client?
Not necessarily fresh consent, but it’s worth being explicit that assisting with a claim means liaising with the hospital and TPA and handling the same detailed medical/billing data — naming that at the point the client raises the claim issue is better practice than assuming the original policy consent silently covers it.
Does the DPDP Act require extra consent steps for health data specifically, beyond what applies to other personal data?
No — the Act applies the same consent and notice baseline to health data as to any other personal data. There’s no separate “sensitive data” consent tier to layer on top.
Is sharing a client’s medical report with the insurer for underwriting a violation under the DPDP Act?
Not if the client’s original notice and consent named that sharing as part of the process — it’s the intended use, not an unauthorised disclosure, provided it was disclosed upfront rather than left vague.
Do brokers need a written agreement with the insurers and TPAs they share data with?
It’s good practice regardless of whether the DPDP Act technically mandates it in every configuration — a written understanding of what each party does with the shared data closes a real accountability gap if something goes wrong downstream.
Why doesn’t the DPDP Act have a “sensitive data” category like GDPR?
It’s a deliberate legislative choice — the Act applies one uniform framework to all personal data rather than layering extra rules onto specific categories, unlike the EU’s approach or India’s earlier SPDI Rules.