From IT Act to DPDP Act: Why Brokers Must Reset Data Practices
Indian personal-data practice for two decades operated under the Information Technology Act 2000 and its successor IT (Reasonable Security Practices and Procedures and Sensitive Personal Data) Rules 2011. The framework imposed broad obligations on body corporates handling sensitive personal data but lacked structured consent rules, defined data-principal rights, or a dedicated enforcement body. Insurance brokers processing client KYC documents, policy schedules, claims medical records, and beneficiary information operated under this regime with varying levels of formality.
The Digital Personal Data Protection Act 2023, notified in August 2023, replaces the IT Act personal-data provisions with a structured regime. The Act introduces defined roles (data fiduciary, data processor, data principal, significant data fiduciary), specific obligations (notice, consent, purpose limitation, data minimisation, accuracy, retention, security, breach reporting), and enforcement through the Data Protection Board of India with penalties of up to INR 250 crore for specified breaches.
The DPDP rules were progressively notified through 2024 to 2025, with the operational compliance window now closed for most provisions. Insurance brokers must operate under the DPDP regime in 2026 with documented compliance evidence rather than implicit conformance with prior practice. IRDAI inspection has visibly added DPDP-themed observations across 2025 broker inspections, and the Data Protection Board has begun preliminary inquiries against intermediaries reported for consent or data-sharing defects.
For commercial brokers handling policyholder data, beneficiary data, and claims data, the DPDP shift is operationally material. The data volumes are large (a mid-market broker handles personal data of tens of thousands of policyholder employees, dependants, and named insureds at any time), the data sensitivity is high (medical records on health claims, financial information on D&O claims, identification data on every individual covered), and the cross-border flows are routine (international reinsurer information, multinational programme data sharing, global insurer counterparty exchanges). DPDP compliance is now a core operating capability rather than a peripheral compliance topic.
Data Fiduciary or Data Processor: The Broker's Role
The DPDP Act distinguishes between data fiduciaries (who determine the purpose and means of processing) and data processors (who process data on behalf of a data fiduciary). The distinction matters because obligations differ. A data fiduciary carries the primary statutory obligations on notice, consent, purpose limitation, and data principal rights. A data processor's obligations flow through the contractual arrangement with the data fiduciary plus the residual statutory requirements on security and processing limitation.
For an Indian commercial insurance broker, the role analysis is layered. The broker is a data fiduciary when:
- Collecting individual personal data directly from the data principal (employee KYC, beneficiary information, named insured data on placement).
- Determining the use of personal data within the broker's own systems (risk profile analysis, advisory recommendations, internal reporting).
- Sharing personal data with insurers, reinsurers, or other counterparties on the broker's own initiative (rather than purely as a processor for the client).
- Retaining personal data for the broker's own purposes (commission records, regulatory recordkeeping, audit trail).
The broker is a data processor when:
- Acting on the client's specific instruction to share data with a named insurer or counterparty.
- Operating on a specific contractual processing scope set by the client.
- Not determining the purpose or means of processing beyond the client's instruction.
In practice, most commercial brokers in 2026 operate as data fiduciaries for most of their personal-data processing. The data-processor role applies to specific bilateral arrangements typically with large corporate clients that have their own DPDP compliance programmes and treat the broker as a processor under detailed processing agreements. Smaller commercial clients and almost all retail clients place the broker firmly in the data-fiduciary role.
Consent Architecture for KYC, Underwriting, and Claims
Consent is the principal lawful basis for personal-data processing under the DPDP Act for most insurance broker activities, with limited exceptions for legitimate uses defined in Section 7 of the Act (employment-related processing, specified state-function processing, medical emergency, and certain compliance and fraud-prevention purposes). Consent must be free, specific, informed, unconditional, and unambiguous, given by a clear affirmative action.
The broker's consent architecture must address three primary data flows.
KYC and onboarding consent
KYC processing covers PAN, Aadhaar (with the specific Aadhaar-related restrictions under the Aadhaar Act 2016 as amended), proof of address, financial information for premium financing arrangements, and beneficial ownership data for corporate clients. The DPDP notice and consent at KYC stage must specify:
- The categories of personal data collected and the source.
- The specific purpose of processing (placement, advisory, regulatory recordkeeping, audit).
- The categories of recipients (insurers, reinsurers, regulators, auditors).
- The retention period or criteria for determining retention.
- The data principal's rights and the contact for exercising them.
- Cross-border transfer where applicable, with the destination categories.
KYC consent must be captured in a form that supports later evidence requirements. Common implementations include digital consent capture with structured logging, electronic signatures on physical or scanned consent documents, and verifiable consent flows integrated with KYC workflow systems.
Underwriting and risk-profile consent
Processing for underwriting and risk profiling often involves more granular personal data than KYC (employee health information for group medical, claims history for management liability, financial data for credit-related covers). Consent at underwriting stage should specifically address:
- The additional data categories beyond KYC scope.
- The processing for risk assessment, including any automated decision-making or scoring.
- The recipients including insurer underwriting teams and reinsurer underwriters where applicable.
- The interaction with prior consent (whether the underwriting consent supersedes or supplements the KYC consent).
Claims processing consent
Claims processing covers some of the most sensitive personal data in the insurance value chain, particularly health, financial-loss, and incident-specific information. Consent for claims processing must address:
- Sharing with the insurer's claims team, surveyors, third-party administrators, and forensic teams.
- Sharing with reinsurers for claims above retention.
- Sharing with regulators where required.
- Use for fraud prevention with potential sharing across the insurance industry per IRDAI's industry-wide initiatives.
- Retention through the regulatory recordkeeping period (typically 10 years for claims-related records).
Claims consent typically appears in policy documents and claim forms, but the DPDP standard requires that the consent be evident and specific rather than buried in policy fine print. Brokers should review the consent language in policy documents and claim forms of their counterparty insurers, and supplement with broker-issued consent capture where needed.
Cross-Border Transfer: The Negative List and Practical Mechanics
The DPDP Act allows cross-border personal-data transfer by default, subject to the Central Government's power to restrict specific country transfers through notification of a negative list. As of mid-2026, the negative list has not been formally notified, but draft consultations indicate the list will likely cover specific country categories with regulatory concerns rather than a broad restriction.
For commercial brokers in 2026, the practical cross-border data flows include:
- Insurer counterparty transfers where the insurer is a foreign entity or operates through a foreign branch (London market placements, Lloyd's syndicates, Bermuda reinsurers).
- Reinsurance facultative submissions to reinsurers operating internationally with personal data of named insureds included in submission packages.
- Multinational programme data sharing for global insurance programmes managed centrally from outside India.
- Global broker network sharing for international brokers operating with India offices that share data with overseas affiliates.
- Service-provider processing where the broker uses cloud, analytics, or other services with processing locations outside India.
Each cross-border flow must be supported by a lawful basis (typically consent), a specific purpose, and where the destination is on the negative list when notified, the appropriate restriction. Brokers should map their cross-border flows now to anticipate the negative list impact.
Interaction with sector-specific requirements
The DPDP Act applies in parallel with sector-specific data restrictions. For insurance brokers, the relevant overlays include:
- The IRDAI Information Security Guidelines 2023 with specific data-residency expectations for certain insurance data.
- The Reserve Bank of India data localisation directions for payment-related data (relevant to premium and claims payment flows through banking channels).
- The Sarbanes-Oxley and similar overseas regulations for clients with US, UK, or other-jurisdiction reporting requirements.
- The EU GDPR for data of EU data subjects processed in connection with EU operations of multinational clients.
The overlay creates situations where the DPDP standard, the IRDAI standard, and a foreign-law standard each apply concurrently. Brokers operating in such situations should document the layered compliance position and apply the most restrictive standard across all applicable regimes.
Data Principal Rights and the Operational Response
The DPDP Act creates four primary rights for data principals (the individuals whose personal data is processed): the right to access, the right to correction and erasure, the right to grievance redressal, and the right to nominate. Brokers as data fiduciaries must operationalise the rights with structured response capability.
Right to access
A data principal can request a summary of personal data processed and the categories of recipients, the processing activities, and the contact for redressal. Brokers must respond within the timeframe specified in the rules (typically 30 days). Response should include:
- Categories of personal data held about the data principal.
- The purposes for which the data is processed.
- The recipients with whom data has been shared.
- The retention status.
- The contact for exercising further rights.
The operational implementation requires the broker to retrieve personal data across the firm's systems (case-management, communications, financial systems, archives) and assemble a coherent response. Brokers without integrated data retrieval capability face access-request friction and potential breach observations.
Right to correction and erasure
Data principals can request correction of inaccurate or incomplete personal data and erasure of personal data that is no longer necessary for the purpose for which it was collected, subject to retention requirements under other laws. Brokers must implement correction across all systems where the personal data is held. Erasure is constrained by IRDAI recordkeeping rules (typically 7 to 10 years for insurance-related records), so brokers should document the legal basis for retention when declining an erasure request.
Right to grievance redressal
The broker must designate a Data Protection Officer (DPO) for significant data fiduciaries or an equivalent grievance contact for other data fiduciaries. The DPO or contact handles data principal grievances with prescribed timelines and escalation to the Data Protection Board where unresolved. Brokers should publish the contact in privacy notices and policy documents, train customer-facing staff on routing grievances to the contact, and maintain a grievance register for inspection-readiness.
Right to nominate
Data principals can nominate another individual to exercise rights in the event of death or incapacity. Brokers should integrate the nomination capture with policy and beneficiary processes, with appropriate verification mechanisms.
Vendor Contracts and the RFP-to-Onboarding Cycle
Brokers rely on multiple vendors for processing personal data: case-management SaaS, communications and document storage, financial systems, third-party administrators for group health and other claims, analytics and reporting providers, and external advisory firms. Each vendor receiving personal data must be a contracted data processor with specific obligations under the DPDP Act and the Data Processing Agreement (DPA) standards emerging from market practice.
The broker's vendor lifecycle should integrate DPDP compliance at four points.
RFP and selection
RFP documents for any vendor processing personal data should include specific DPDP-related questions:
- The vendor's role as data processor and conformance with the DPDP Act.
- Data-security controls including ISO 27001, SOC 2, or equivalent certifications.
- Sub-processor disclosure and approval mechanics.
- Breach notification capability with timelines aligned to DPDP requirements.
- Audit rights for the broker as data fiduciary.
- Data-handling on contract termination including return or deletion mechanics.
Vendor responses should be evaluated for both the regulatory conformance and the practical operational evidence. A vendor with strong contractual undertaking but weak operational evidence is a risk that comes due only at the time of a breach or audit.
Contract drafting and DPA execution
The Data Processing Agreement must address the matters required under DPDP and any sector-specific requirements. Standard DPA topics include:
- Categories of personal data, categories of data principals, processing purposes.
- Vendor obligations on confidentiality, security, sub-processor management.
- Breach notification mechanics with specific timelines.
- Data-principal rights support (forwarding access and correction requests).
- Audit and inspection rights.
- Cross-border processing constraints aligned to applicable restrictions.
- Termination and return or deletion of personal data.
- Liability and indemnification for breach.
Brokers should maintain DPA templates aligned to their specific compliance framework and update them as the DPDP rules and market practice evolve.
Onboarding and ongoing monitoring
Vendor onboarding should verify operational implementation of contractual commitments. Ongoing monitoring should cover periodic re-attestation of compliance, breach notifications received and handled, sub-processor changes notified, and audit findings.
Termination and data return
Contract termination triggers structured data return or deletion. Brokers should document the deletion or return evidence, verify completeness, and update the personal-data map to reflect the termination.
For a mid-market broker with 30 to 60 vendors handling personal data, the DPDP-aligned vendor lifecycle work represents a sustained operational commitment. Brokers without dedicated vendor management or compliance capacity face material gaps that surface at inspection or breach time.
Incident Reporting: The 72-Hour Discipline
The DPDP Act and rules require data fiduciaries to report personal-data breaches to the Data Protection Board and to affected data principals within prescribed timelines. The rules notified through 2024 to 2025 establish a 72-hour reporting window to the Board for most breach categories, with notification to data principals within timelines that vary with breach severity and data-principal-impact magnitude.
For brokers, the operational reality of 72-hour reporting requires preparation well before any incident.
Detection capability
The broker must have technical capability to detect personal-data breaches across:
- Unauthorised access to case-management or other broker systems.
- Data exfiltration through legitimate or unauthorised channels.
- Vendor breaches affecting personal data held by processors.
- Email and communication mishandling (incorrect recipient, accidental disclosure).
- Physical-document mishandling (lost laptops, misplaced files, improper disposal).
Detection typically combines technical monitoring (SIEM, endpoint detection, vendor breach notifications) and procedural reporting channels (employee training to report incidents, customer complaint processing identifying potential breaches).
Assessment and decision
On detection, the broker must assess scope (data categories, data-principal count, severity, business impact), determine reportability under DPDP and other applicable regimes, and decide on notification action. The assessment must happen within a window that allows reporting within 72 hours, requiring rapid escalation and decision capability.
Reporting mechanics
Reporting to the Data Protection Board uses the prescribed format covering:
- Breach particulars including time, type, scope, and detection method.
- Personal data affected with categories and data-principal count.
- Likely consequences for data principals.
- Mitigation actions taken or planned.
- Contact for further coordination.
Notification to data principals uses formats appropriate to the breach severity and the data-principal contact mechanics available.
Post-incident review
Following the reporting cycle, the broker should conduct a structured root-cause analysis, implement corrective action, and document the action evidence for inspection-readiness. Repeated breaches with inadequate root-cause action attract Board sanctions including substantial monetary penalty (up to INR 250 crore for serious breaches under the DPDP Act).
IRDAI Information Security Guidelines Interaction and 2026 Roadmap
The DPDP Act applies in parallel with the IRDAI Information Security Guidelines 2023, which prescribe sector-specific data-security and operational-resilience requirements for insurers and intermediaries. The two regimes overlap in scope but are not identical, and brokers must satisfy both.
The IRDAI Guidelines specifically address:
- Governance with board-level oversight of information security and named senior executive responsibility.
- Risk management with structured information-security risk assessment and treatment.
- Asset management including classification of information assets.
- Access control with privileged-access management and segregation of duties.
- Operations security including change management, system development life cycle, and capacity management.
- Communications security including network controls and data-in-transit protection.
- Incident management with detection, response, and reporting.
- Continuity and recovery with documented business continuity planning.
- Compliance including legal and regulatory mapping and internal audit.
- Cloud and third-party including specific cloud-services controls and third-party risk management.
The DPDP Act covers a different scope, focused on personal-data lifecycle from collection through deletion. The IRDAI Guidelines cover the broader information-security context within which personal data is one category of information.
For brokers, the practical compliance framework integrates both regimes:
- Personal-data mapping anchored to the DPDP Act applies to all personal data with specific rights and obligations.
- Information-asset inventory anchored to the IRDAI Guidelines covers all information categories including personal data, commercial data, regulatory data, and operational data.
- Risk assessment is conducted on both axes (personal-data-specific risks and broader information-security risks).
- Controls are designed to satisfy the more restrictive of the two regimes for any given risk.
- Reporting addresses both DPDP breach reporting and IRDAI incident reporting per the respective timelines and formats.
- Audit by both internal and external functions covers both regimes.
The integration is operationally efficient because the two regimes share many controls (governance, access management, incident response). The integration also surfaces overlap and gaps that single-regime compliance work would miss.
Practical roadmap: where brokers should be by end-2026
Building on the IRDAI Guidelines integration above, brokers without complete DPDP implementation should sequence the work across three quarters of focused effort.
Q3 2026: Foundation
- Complete personal-data mapping across all broker systems, vendors, and processes.
- Identify data-fiduciary and data-processor roles for each processing activity.
- Document the lawful basis for each processing activity (consent, legitimate use, employment, regulatory).
- Refresh privacy notices and consent capture mechanics aligned to DPDP standards.
- Designate the DPO or grievance contact and publish the details.
- Build the data-principal-rights response capability with documented procedures.
Q4 2026: Operational rollout
- Execute vendor DPA refresh for all vendors processing personal data.
- Implement breach detection, decision, and 72-hour reporting capability with documented runbooks.
- Integrate DPDP compliance reporting with the broader IRDAI compliance reporting cadence.
- Train staff across customer-facing, claims, and operational functions on DPDP discipline.
- Run a tabletop exercise on data-principal rights response and breach reporting.
- Document compliance evidence in a form ready for IRDAI and Data Protection Board inspection.
Q1 2027: Continuous improvement
- Run the first formal internal audit of DPDP compliance.
- Track the negative-list notification when issued and implement cross-border-transfer adjustments.
- Refresh vendor and sub-processor inventory.
- Update the personal-data map to reflect operational changes.
- Establish the year-ahead roadmap for continuous DPDP integration as the rules and Board enforcement evolve.
Investment scale
For a mid-market broker with annual revenue of INR 25 crore to INR 100 crore, the DPDP implementation investment lands at INR 60 lakh to INR 2 crore across the implementation period, covering personal-data mapping, system upgrades, vendor DPA refresh, training, documentation, and external advisory. Ongoing operational cost runs INR 25 lakh to INR 75 lakh annually for compliance maintenance, training refresh, and audit activity. Larger brokers scale proportionately, often at INR 3 crore to INR 8 crore for initial implementation.
The investment is significant but the alternative is exposure to Data Protection Board penalties up to INR 250 crore for serious breaches, IRDAI inspection observations on intersection with the Information Security Guidelines, and the reputational and client-retention exposure that breach incidents produce.