Blockchain and DPDP compliance do not come easily together — and that tension is one of the least-discussed compliance risks in India today.
Blockchain promises transparency, tamper-resistance, and decentralised trust. The DPDP Act, 2023 promises individuals the right to have their personal data erased. These two commitments point in opposite directions. The ledger wants to remember everything. The law says individuals have the right to be forgotten.
As organisations across India deploy blockchain in finance, supply chains, healthcare records, and identity verification, this conflict moves from theoretical to urgent. The full compliance deadline under the DPDP Act is 13 May 2027. Moreover, if your organisation’s blockchain architecture stores personal data today, the design decisions you make now will be far harder to reverse later.
Follow us to know more about this in the coming days.
Suresh runs the technology operations of a growing e-commerce company in Chennai. Two lakh registered customers. Three cloud vendors — one handles transactions and payments, one runs the analytics and recommendation engine, and one powers the customer support chatbot.
Each vendor has a copy of customer personal data. Some overlap. Some don’t. Suresh has never mapped exactly which data lives where.
One afternoon, a customer sends a formal email invoking her right to erasure under the DPDP Act. She has deleted her account. She wants confirmation that all her personal data has been erased.
Suresh opens his systems. He can delete her record from the primary database. He can see her in the analytics platform. He thinks she might be in the support chatbot’s conversation history. He is not sure whether the payment processor retains her card data or whether the analytics engine has derived any insights about her that are stored independently.
He has 48 hours before he must confirm erasure. He does not know where to start.
The multi-cloud erasure problem under DPDP
Section 8(7)(b) of the DPDP Act, 2023 creates the cascade obligation: when erasure is triggered — whether by purpose completion, consent withdrawal, or Data Principal request under Section 12 — the Data Fiduciary must erase the personal data and cause its Data Processors to erase the personal data made available to them.
The word “cause” is important. The obligation is not to request. It is to cause — to ensure that erasure actually occurs across every downstream processor. Suresh cannot discharge this obligation by sending an email to three vendors and hoping they comply. He must have a contractual mechanism — and a technical verification mechanism — that confirms the data has been erased.
IS Audit Module 6 identifies multi-tenancy as a specific cloud privacy risk: in a shared cloud environment, data from different customers may be commingled, creating scenarios where erasure of one customer’s data requires careful isolation to avoid affecting other tenants’ data — and equally, to ensure complete deletion rather than merely marking a record as inactive.
The Data Processor contract that Suresh does not have
Rule 6(1)(f) of the DPDP Rules requires the contract between the Data Fiduciary and every Data Processor to include appropriate provisions for taking reasonable security safeguards — which, by extension of the Act’s overall framework, includes the ability to execute erasure on instruction.
Suresh’s three vendor agreements are standard subscription contracts. None of them include a clause that obligates the vendor to erase personal data on a specific Data Principal’s request within a specified timeframe. None of them include an API endpoint for automated erasure triggering. None of them require the vendor to confirm deletion with an audit record.
Without these contractual provisions, Suresh’s erasure obligation is practically unenforceable against his own vendors. He is accountable to the Data Principal — and he has no mechanism to discharge that accountability.
The technology architecture Suresh needed to build
A DPDP-compliant multi-cloud environment for a Data Fiduciary requires a data mapping inventory — a live register of which personal data categories sit with which Data Processor, updated as the technology stack evolves. Without this map, Suresh cannot identify all the locations that must be cleared when an erasure request arrives.
It requires Data Processor contracts that include specific erasure API or webhook obligations — technical hooks that allow the Data Fiduciary’s erasure workflow to send a deletion instruction directly to each processor’s system and receive a timestamped confirmation.
It requires an erasure orchestration layer — a workflow engine that receives the Data Principal’s erasure request, identifies every processor in the data map holding that individual’s data, dispatches deletion instructions simultaneously, collects confirmations, and generates an audit trail of the completed erasure.
IS Audit Module 6 identifies cloud migration risks including insufficient planning and processes as a leading cause of cloud security failures. Suresh’s situation is exactly this: the cloud architecture was expanded incrementally without a corresponding expansion of data governance. Each new vendor added a compliance obligation that was never mapped, never contracted for, and never operationalised.
What the customer actually has the right to
Under Section 12 of the DPDP Act, Suresh’s customer has the right to erasure of her personal data unless retention is required by law. Under Section 11, she has the right to know the identities of all Data Processors with whom her data was shared. She does not need to know that Suresh has three cloud vendors — but she is legally entitled to find out.
Under Rule 8(3), personal data and processing logs must be retained for at least one year — so complete immediate erasure across all systems is not always possible. But the customer’s primary profile data, her transaction history shared with analytics, and her support conversations must be erased on schedule, with the one-year minimum applying only to logs.
The distinction between what must be retained for compliance and what must be erased on request requires data classification — another element of governance Suresh has not yet built.
The cloud is not one system. Neither is the compliance obligation.
Every Data Processor your organisation engages creates a branch of the same compliance obligation. Consent. Security safeguards. Breach notification. Erasure on instruction. Data Principal rights access. Each branch must be contractually formalised, technically implemented, and operationally testable.
The cloud makes personal data processing faster, cheaper, and more scalable. The DPDP Act ensures that those efficiencies do not come at the cost of Data Principal rights — regardless of how many cloud vendors the efficiency requires.
Sources: DPDP Act 2023 | ICAI IS Audit 3.0 Course
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.
Dutch Microsoft Issue: A Business Perspective for Indian Enterprises
A recent incident in the Netherlands has sent a quiet but unmistakable signal to boardrooms and policy corridors around the world — including in India. Microsoft reportedly shared documents containing the names of Dutch civil servants, who were working with Dutch regulators, with the United States House of Representatives. The documents included emails, meeting minutes and official invitations. Dutch authorities said they needed to investigate further before drawing conclusions.
For Indian businesses, the lesson is not about the Netherlands. It is about the nature of cloud dependency — and what it means when the infrastructure your enterprise runs on is ultimately governed by a foreign legal system.
1. Data Residency vs. Data Sovereignty: A Critical Distinction
Many Indian companies believe they have addressed their data risk by choosing a cloud provider’s Mumbai or Hyderabad region. That belief is dangerously incomplete. There is a fundamental difference between two concepts that are often conflated:
Concept
What It Actually Means
Data Residency
Where the server physically sits. Your data may be stored in Mumbai, but the company that runs that server may be incorporated in the United States.
Data Sovereignty
Who can legally compel access to that data — through whose courts, under whose laws, and through which administrative and technical controls.
The Netherlands’ own Court of Audit had already warned in January 2025 that the Dutch central government had entered cloud contracts without completing mandatory risk assessments for two-thirds of major cloud services reviewed. India must not make the same error.
2. The U.S. CLOUD Act: What Every Indian Business Leader Should Know
Under U.S. federal law (18 U.S.C. § 2713), any U.S.-based provider of electronic communication or cloud computing services must preserve, back up, or disclose customer data within its possession, custody, or control — regardless of where that data is physically located. This is not a hypothetical risk. It is a statutory obligation.
This does not mean that a U.S. government official can browse your company’s data at will. The correct position is more nuanced: a U.S. cloud provider may be legally compelled, under appropriate legal process, to produce data it technically controls — even if that data is stored in a server in India.
For Indian enterprises, the practical question is straightforward: Does your cloud provider’s parent company have U.S. jurisdiction? If yes, U.S. lawful access risk exists regardless of which Indian region your data sits in.
3. Can Indian Data Be Shared with a Foreign Government via an Indian Subsidiary?
This is a question increasingly being asked by Indian businesses that use global cloud platforms through locally-incorporated entities. The answer is: not automatically — but the risk is real, and it depends on how the system is architected.
An Indian subsidiary is a separate legal entity under Indian law. However, if the U.S. parent company or a U.S.-governed service provider has access to administrative controls, identity systems, support logs, telemetry, backup infrastructure, or encryption keys — a foreign legal demand may create real exposure for Indian data.
Practical scenarios Indian businesses must consider:
If you use Microsoft 365, Azure, AWS, or Google Cloud under a globally-managed service model, foreign lawful access risk exists — even for data stored in India.
If your data is stored in India but identity management, support, telemetry or backups are handled globally, local storage alone does not guarantee sovereignty.
If encryption keys are exclusively controlled by you or an Indian-governed entity, your exposure is materially reduced.
If your vendor’s Indian subsidiary operates with no parent-company access and no U.S.-controlled cloud layer, the risk is lower — but must be verified through contracts and audits.
4. It Is Not Only a U.S. Issue — The Broader Principle
India should be careful not to frame this as a problem unique to American technology companies. Sovereign access laws exist in multiple jurisdictions:
The United Kingdom’s Investigatory Powers Act has extraterritorial features, with certain notices already being served on overseas operators.
Australia’s Assistance and Access Act gives agencies tools to require industry cooperation and access digital evidence.
China’s National Intelligence Law (Article 7) requires organisations and citizens to support, assist and cooperate with state intelligence work.
The principle, therefore, is universal: any foreign-controlled digital infrastructure may carry foreign sovereign access risk. Indian businesses need a framework grounded in this reality — not one that merely substitutes one foreign provider for another.
5. Why This is Now an Economic and Business Competitiveness Issue
Data is no longer merely an operational input. It is a strategic economic asset. It drives AI models, credit scoring, health analytics, market intelligence, consumer behaviour mapping, financial surveillance, and supply chain optimisation.
When Indian enterprise data sits on foreign-controlled infrastructure, the business consequences are tangible:
Loss of bargaining power: Indian firms become dependent on foreign providers’ pricing, licensing, service continuity, and policy decisions.
Compliance cost escalation: DPDP Act obligations, sector-specific regulations (RBI, IRDAI, SEBI), and cross-border transfer requirements all add legal and operational overhead.
Innovation dependency: Indian AI and analytics capability built on foreign APIs and model ecosystems may be subject to unilateral access restrictions or commercial discontinuation.
Competitive intelligence exposure: Even anonymised or aggregated data, when processed on foreign infrastructure, can reveal patterns about Indian market behaviour, pricing, and institutional strategy.
Trade friction risk: Cross-border data restrictions can impede outsourcing, SaaS delivery, cloud migration, and global service contracts.
The European Union has already navigated this at scale. The Court of Justice of the European Union invalidated the EU–U.S. Privacy Shield in 2020, primarily over concerns about U.S. surveillance access. A new EU–U.S. Data Privacy Framework came into force in July 2023 — but the repeated litigation surrounding these arrangements demonstrates how economically consequential and legally fragile cross-border data flows can be. India should observe this experience and prepare its own frameworks proactively.
6. Should Indian Businesses Push for Indian Sovereign Cloud?
Yes — but with an important qualification. A data centre located in India is not, by itself, a sovereign cloud. What India needs is not mere data residency but genuine digital sovereignty: Indian-owned infrastructure, Indian-law-governed operations, India-based administrators, India-controlled encryption keys, auditable sub-processor chains, and strong security standards.
India has already taken steps in this direction. MeitY has empanelled cloud service providers following Standardisation Testing and Quality Certification (STQC) Directorate audits against ISO 27001, ISO 27017, ISO 27018 and ISO 20000 standards. NIC functions as a government cloud provider while engaging private players through structured tender processes.
A tiered sovereign cloud policy — rather than a blanket localisation mandate — is the right direction:
Data Category
Recommended Approach
Ordinary commercial data
Global cloud with DPDP compliance, robust contracts, security controls, and transfer impact assessments.
India-region storage mandated, stronger encryption, and auditable access logs.
Defence, law enforcement, judicial systems, core government identity
Sovereign cloud operated by Indian entities or government-controlled bodies with no foreign administrative access.
AI training datasets derived from Indian citizens
Special rules on anonymisation, model training, onward transfer, and foreign access — to be developed as a priority.
7. An Immediate Compliance Checklist for Indian Organisations
Indian businesses using foreign SaaS and cloud services should immediately review the following:
Data Map: What personal data is collected, where it is stored, and where it is processed.
Vendor Map: Cloud provider, SaaS provider, sub-processors, and support locations — including parent company jurisdiction.
Cross-Border Transfer Register: All instances where data moves outside India, with the legal basis for each transfer.
Processor Contracts: Agreements under Section 8 of the DPDP Act with all data processors.
Foreign Lawful Access Risk Assessment: Assess whether your vendor’s parent company is subject to U.S. CLOUD Act or equivalent foreign access laws.
Encryption and Key Management Policy: Ensure encryption keys are controlled by your organisation or an India-governed entity.
Breach Notification Readiness: Plans and timelines to comply with DPDP Act breach notification obligations.
Exit and Data Portability Plan: Ability to migrate data and operations if a vendor relationship ends.
Sectoral Law Review: Review obligations under RBI, IRDAI, SEBI, telecom, health, and government procurement rules.
Board-Level Data Sovereignty Policy: Governance-level oversight of data sovereignty decisions for sensitive datasets.
The Business Leadership Imperative
The Dutch–Microsoft episode is not a distant IT story. It is a warning signal for every Indian enterprise that has signed a cloud contract without fully understanding who ultimately controls its data — and under whose law.
India should not reject foreign cloud technology. That would compromise innovation and efficiency. But Indian business leaders must stop treating data infrastructure as purely a technology or procurement decision. It is simultaneously a legal risk, an economic policy choice, and a national security variable.
The real question — the one that every board, every CFO, and every CTO in India should now be asking — is not where is our data stored? but rather: who can legally, technically and operationally control our data when pressure comes?
Answering that question honestly is the first step towards genuine digital sovereignty.
Disclaimer / Author’s Note
The views and opinions expressed in this article are solely those of the author and are intended for general information and discussion purposes only. They do not constitute legal advice, professional opinion, or the official position of any organisation with which the author may be associated. Readers are advised to seek appropriate professional advice before acting on any matter discussed herein.
Ananya is the HR Manager of a mid-sized manufacturing firm in Pune. Three hundred employees. Payroll processed through a popular SaaS platform. Everything automated, everything on time.
One afternoon, a data privacy consultant visits for a routine review. She asks Ananya a simple question: “Where does your payroll platform store the data?”
Ananya checks the platform’s help documentation. Then its terms of service. Then calls their support line.
The answer comes back: servers in Singapore.
The salary details, bank account numbers, PAN numbers, and attendance records of all three hundred employees — sitting on servers outside India. No one in the organisation knew. No one had reviewed the contract for a data storage clause. No one had asked.
Why geography matters under DPDP
The Puttaswamy judgment acknowledges that data protection challenges are not limited to data localisation but have become extra-territorial — cross-border transfers of personal data raise complex regulatory questions that different jurisdictions are grappling with simultaneously.
The DPDP Act, 2023 addresses this directly. Section 16(1) empowers the Central Government to restrict the transfer of personal data by a Data Fiduciary for processing to such countries or territories outside India as may be notified. When those notifications are issued — and they will be, particularly for sensitive personal data categories — Ananya’s payroll platform will be non-compliant from that moment unless the firm has reviewed its architecture.
The Puttaswamy judgment further notes that every transaction on a digital platform is linked with some form of sensitive personal information — user IDs, account numbers, PAN numbers, biometric details. Payroll data falls precisely into this category. It is not a dataset that can sit in an unreviewed offshore location without governance.
The Data Processor contract problem
Beyond the cross-border question, there is a more immediate compliance issue. Section 8(2) of the DPDP Act requires a Data Fiduciary to engage a Data Processor only under a valid contract. That contract must — under Rule 6(1)(f) — include appropriate provisions for taking reasonable security safeguards.
Ananya’s firm signed up to the SaaS platform’s standard subscription agreement. That agreement almost certainly does not specify: the security standards to which the vendor holds itself, the encryption requirements for payroll personal data at rest and in transit, the access control and log retention requirements that Rule 6(1)(b) and (c) mandate, or the breach notification timeline that allows the firm to meet its 72-hour Board reporting obligation.
A standard SaaS subscription is not a DPDP-compliant Data Processor contract. The firm is processing employee personal data through a vendor with whom it has no contractual security obligations that meet the Act’s requirements. That is a compliance gap — and it exists for every SaaS tool in the firm’s technology stack.
The employees’ rights and what the firm cannot currently honour
Ananya’s three hundred employees are Data Principals under the DPDP Act. Each has the right under Section 11 to access a summary of their personal data being processed and the identities of all Data Processors with whom it has been shared. If an employee asks — which they are legally entitled to do — Ananya’s firm must disclose that their salary and bank account data is stored on servers in Singapore by a named SaaS vendor.
Each employee also has the right under Section 12 to request correction of inaccurate data and eventually erasure when employment ends. The firm must be able to give the SaaS vendor a contractually binding erasure instruction and receive confirmed deletion. Without a Data Processor contract that specifies this obligation, the erasure right cannot be practically honoured.
The practical steps Ananya’s firm needs to take — now
Review every SaaS and cloud platform in the technology stack that processes employee or customer personal data, and document where each platform stores data geographically.
Negotiate or obtain Data Processor Addendums from each vendor — specifying security safeguards, breach notification timelines, data residency commitments, and erasure procedures aligned with DPDP requirements.
Monitor the Central Government’s notifications under Section 16 for data localisation requirements — and build an architecture that can respond to those requirements without a full platform migration.
Build an employee-facing disclosure — accessible via the HR portal — that identifies the Data Processors used and the data shared with each, so that the right to access under Section 11 can be immediately satisfied.
The question every HR and operations leader must ask today
Do you know where every piece of employee personal data in your organisation is physically stored? If you do not — the DPDP Act requires you to find out, document it, govern it contractually, and be prepared to disclose it to every employee who asks.
The data did not leave India without anyone noticing. Someone noticed. Just not in time to prevent it, and not yet in time to govern it.
Series 2, Episode 2 — Post 2 of 3 | DPDP Meets Emerging Technologies
Sources: DPDP Act 2023 (Sections 8(1), 8(2), 11, 12, 16(1)) | DPDP Rules 2025 (Rules 6(1)(b)(c)(f)) | ICAI IS Audit 3.0 Course Materials | Justice K.S. Puttaswamy (Retd.) vs Union of India (2018)
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.
Vikram is 34 years old. He built a thriving edtech startup from his apartment in Bengaluru. Fifty thousand registered users. A small but dedicated team. And all of it running on a global cloud platform.
When he signed up, he ticked the terms of service. The data processing agreement was long. He didn’t read it. He assumed the cloud provider would handle security — that’s what the cloud is for, right?
One morning, Vikram receives an automated alert. His cloud provider has detected unusual access to a storage bucket containing the personal data of his users — names, email addresses, learning history, and payment records. The provider’s security team is investigating.
Vikram logs a support ticket with the cloud vendor and waits for them to resolve it.
He does not know that the DPDP Act has already placed the obligation firmly on him — and the 72-hour clock started the moment he became aware.
The accountability that does not transfer
Section 8(1) of the DPDP Act, 2023 is direct: a Data Fiduciary shall, irrespective of any agreement to the contrary, be responsible for complying with the provisions of this Act in respect of any processing undertaken by it or on its behalf by a Data Processor.
Vikram’s cloud provider is a Data Processor. The personal data in that storage bucket belongs to Vikram’s users — users who gave their consent to Vikram’s platform, not to a global cloud company. The fact that the breach occurred at the cloud provider’s infrastructure does not move the compliance obligation. It remains with Vikram.
Section 8(2) requires that a Data Fiduciary may engage a Data Processor only under a valid contract. That contract must include — under Rule 6(1)(f) — appropriate provisions for taking reasonable security safeguards. If Vikram’s data processing agreement did not specify encryption of personal data at rest, access controls, log retention, and breach notification timelines aligned with DPDP requirements — the contract itself is a compliance gap.
The 72-hour window and what it demands from Vikram
Under Rule 7(2) of the DPDP Rules, 2025, a Data Fiduciary must intimate the Data Protection Board within 72 hours of becoming aware of a personal data breach — with the nature, extent, timing, location, likely impact, root cause, remedial measures, and a report on notifications sent to affected Data Principals.
Vikram became aware when he received the alert. The 72-hour clock started at that moment. It does not restart when the cloud vendor completes its investigation. It does not pause while the support ticket is open. It started when Vikram knew.
IS Audit Module 6 of the ICAI IS Audit 3.0 Course identifies a cloud-specific privacy risk directly relevant here: cloud computing involves a greater dependency on third parties and increased transborder flow of personally identifiable information, creating greater magnitude of privacy risks. The breach Vikram is experiencing is exactly that risk manifesting — and DPDP requires him to have anticipated it contractually, technically, and procedurally.
What Vikram should have built before going live on cloud
A DPDP-compliant cloud deployment for a Data Fiduciary requires four things that Vikram did not have.
A valid data processing agreement that explicitly requires the cloud provider to implement encryption, access controls, logs, and breach notification to the Data Fiduciary within a timeframe that allows the Data Fiduciary to meet its own 72-hour Board reporting obligation.
Encryption of personal data at rest in every cloud storage bucket and database — so that even if access is unauthorised, the data retrieved is unreadable without the decryption key (Rule 6(1)(a)).
Access controls and logs on every cloud resource holding personal data — so that Vikram can determine, at the time of the breach, exactly which data was accessed, when, and by whom (Rule 6(1)(b) and (c)).
A documented incident response workflow that — from the moment of a breach alert — initiates Board notification preparation, Data Principal communication, and forensic log preservation simultaneously, not sequentially.
The cloud is not a compliance shortcut. It is a processing architecture that transfers operational convenience to a third party while retaining legal accountability with the Data Fiduciary.
The question every founder must answer before their next cloud migration
Does your data processing agreement with your cloud provider obligate them — in writing — to implement the security safeguards that Rule 6 of the DPDP Rules requires? Does it require them to notify you of a breach within a timeframe that lets you meet your 72-hour obligation? Does it permit you to audit their compliance?
If the answer is “our standard plan terms cover it” — read the terms again. Vikram had the same assumption.
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.
Meena’s Story – She Consented to Track Her Health. She Did Not Consent to Losing Her Insurance.
Meena is a 38-year-old marketing professional. Health-conscious, financially aware, and careful about her choices.
She uses a health tracking wearable — diligently logging her steps, sleep, heart rate, and diet. She consented to the health app processing this data to help her monitor her own wellbeing. That felt like a fair exchange.
What she did not know is that her health app shares data with an insurance aggregator platform. That aggregator’s AI model analyses her sleep patterns, exercise consistency, dietary choices, and heart rate variability — and produces a health risk score. When Meena applies for health insurance, she is offered a premium three times higher than her colleague who does not use a wearable.
She tracked her health to take care of herself. The algorithm used that data to price her out of coverage.
The consent problem — specific purpose, specific basis
The DPDP Act, 2023 draws a hard line on this. Section 6(1) requires consent to be specific — each processing purpose requires its own distinct consent. Meena consented to health monitoring for her personal wellness. She did not consent to health risk profiling for insurance underwriting by a third party.
The telemedicine app illustration in the DPDP Act itself makes this principle concrete: when a telemedicine app asks for consent to access the user’s mobile contact list along with health services consent, the Act declares that second element invalid because it is not necessary for the stated purpose. The principle extends directly to Meena’s situation — health data collected for personal monitoring cannot be repurposed for insurance risk scoring without a separate, specific consent for that distinct purpose.
Section 6(6) reinforces this: once consent is withdrawn, the Data Fiduciary must within a reasonable time cease — and cause its Data Processors to cease — processing that personal data. The insurance aggregator is a Data Processor. If Meena withdraws her consent from the health app, that cessation must cascade downstream.
The Puttaswamy warning — AI creates knowledge people never gave
The Supreme Court’s landmark judgment in Justice K.S. Puttaswamy (Retd.) vs Union of India (2018) contains a prescient warning, referenced in the project knowledge base: the creation of new knowledge complicates data privacy law as it involves information the individual did not possess and could not disclose, knowingly or otherwise.
Meena’s health risk score is new knowledge — created by the AI from her data, about her, that she never produced or shared. She shared step counts. The algorithm inferred cardiovascular risk. She shared sleep data. The algorithm inferred stress patterns. She shared dietary logs. The algorithm inferred metabolic risk. None of these inferences are what she consented to share. Yet each is personal data under Section 2(t) of the DPDP Act — data about an identifiable individual — and the creation and commercial use of that inferred data requires a valid processing basis.
The data security dimension — what the AI pipeline holds is a high-value target
IS Audit Module 6 of the ICAI IS Audit 3.0 Course identifies this clearly: most AI applications are based on massive volumes of data to learn and make intelligent decisions. Machine learning systems depend on data which is often sensitive and personal in nature. Due to this systematic learning, these ML systems can become prone to data breach and identity theft.
The aggregated health data pipeline that feeds Meena’s risk score — wearable data, app analytics, insurance scoring parameters — is not just a compliance liability. It is a high-value breach target. If that pipeline is compromised, the personal data of thousands of health-conscious users is exposed, along with the inferred health risk scores that the algorithm produced from it. Under Rule 6(1) of the DPDP Rules, every layer of this pipeline — encryption, access control, logs, breach detection — must be implemented. Under Rule 7, a breach must be reported to the Data Protection Board within 72 hours.
The CERT-In Guidelines on Secure Adoption and Governance of AI Systems (Version 1.0, 25 May 2026) specifically require organisations to ensure secure and compliant handling of data processed by AI systems — classifying and protecting sensitive data, defining retention and deletion policies, and monitoring AI-related data movement and third-party handling. A health data pipeline shared with an insurance aggregator, without documented data handling obligations, fails this standard.
What Meena is entitled to — and what the platform must build
Under Section 11 of the DPDP Act, Meena has the right to access a summary of all personal data being processed about her, and the identities of all Data Fiduciaries and Processors with whom it was shared. She has the right to know that her wearable data reached an insurance aggregator. She was never told.
Under Section 12, she has the right to request erasure of her personal data. That erasure must cascade to the aggregator. The health app cannot fulfil the erasure obligation without a contractual mechanism to cause downstream processors to delete as well — which Rule 6(1)(f) requires to be built into the Data Processor contract.
Under Section 13, she has the right to grieve the processing. The Data Fiduciary must respond within the prescribed period. If the platform cannot explain how her health data reached an insurance pricing model — it cannot respond to that grievance.
The question every health tech and insurtech organisation must answer
Does your data-sharing agreement with downstream AI platforms define, in writing, the specific purposes for which shared personal data may be used? Does it prohibit repurposing of health data for insurance risk scoring without separate user consent? Does it require the downstream processor to honour erasure requests? Does it include security safeguards aligned with Rule 6?
If the answer to any of these is no — Meena’s situation is not a story. It is your organisation’s next compliance exposure.
Series 2, Episode 1 — Post 3 of 3 | DPDP Meets Emerging Technologies.
Sources: DPDP Act 2023 (Sections 2(t), 6(1), 6(6), 8, 11, 12, 13) | DPDP Rules 2025 (Rules 6(1), 6(1)(f), 7) | ICAI IS Audit 3.0 Course Materials | CERT-In Guidelines on Secure Adoption and Governance of AI Systems (Version 1.0, 25 May 2026) | Justice K.S. Puttaswamy (Retd.) vs Union of India (2018)
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.
Rajan is a 45-year-old entrepreneur from a small town in Bihar. He has built a profitable distribution business, has a strong local reputation, and is actively applying for senior roles through an AI-driven job platform.
He never gets shortlisted. Not once.
After months of rejections, a friend in tech takes a look at his profile. The friend tells him quietly: “The algorithm probably doesn’t recognise you. You don’t look like the people it was trained to select.”
Rajan did not know an algorithm was deciding his future. He assumed a recruiter had read his profile and found it wanting. The recruiter never saw it.
When the algorithm learns from biased history
AI systems learn patterns from historical data. The assumption is that historical data reflects good decisions. But what if those decisions were themselves biased — shaped by decades of geographic, socioeconomic, and institutional inequality?
IS Audit Module 6 of the ICAI IS Audit 3.0 Course is explicit: a big problem with AI systems is that their level of goodness or badness depends on how much data they are trained on. Bad data is often associated with ethnic, communal, gender or racial biases. Proprietary algorithms are used to find out information like who gets bail, whose loan is sanctioned. If the bias hidden in the algorithms — which take crucial decisions — goes unrecognised, it could lead to unethical and unfair results.
Rajan’s algorithm had learned that successful candidates, historically, came from certain geographies, certain institutions, and certain career trajectories. It had never been trained to question whether that pattern reflected genuine merit or merely reinforced historical exclusion. The algorithm was confident. The algorithm was wrong. And Rajan had no way of knowing — or challenging — either.
The Puttaswamy dimension — data creates new knowledge about peopleThe Supreme Court’s judgment in Justice K.S. Puttaswamy (Retd.) vs Union of India (2018), included in the project knowledge base, addresses exactly this: the creation of new knowledge complicates data privacy law as it involves information the individual did not possess and could not disclose, knowingly or otherwise.
The job platform’s algorithm created a new piece of knowledge about Rajan — a risk score, a fit score, a ranking — that he did not produce, did not verify, and did not consent to. That score is personal data under Section 2(t) of the DPDP Act: any data about an individual who is identifiable by or in relation to such data. Rajan is identifiable. The score is about him. It is personal data — and its creation and use must have a valid basis.
The DPDP and algorithmic bias — this is a legal obligation, not just an ethical one
Section 10(2)(c)(i) of the DPDP Act requires every Significant Data Fiduciary to conduct a Data Protection Impact Assessment that includes assessment and management of risk to the rights of Data Principals. Rajan’s right to non-discriminatory treatment flows from his fundamental rights under the Constitution and is directly implicated when a biased algorithm systematically excludes him from opportunity based on geographic origin.
Rule 13(3) of the DPDP Rules, 2025 goes further: a Significant Data Fiduciary must observe due diligence to verify that algorithmic software adopted for processing personal data is not likely to pose a risk to the rights of Data Principals. The word “pose a risk” is important. The organisation does not need to wait for Rajan to be demonstrably harmed. The obligation is preventive — to verify, before and during deployment, that the algorithm does not create this risk.
A hiring algorithm trained on historically biased data, operating without bias auditing, and producing systematically skewed outcomes for certain demographic groups poses a risk to Data Principal rights as a matter of its design. The DPDP Act requires that risk to be identified, documented, and mitigated.
The CERT-In AI governance framework — human oversight is mandatory
The CERT-In Guidelines on Secure Adoption and Governance of Artificial Intelligence Systems (Version 1.0, 25 May 2026) identify Human Oversight and Decision Governance as a core control area requiring organisations to: validate AI-generated outputs, restrict fully autonomous critical actions, and maintain auditability and approval mechanisms.
A hiring shortlist generated entirely by an AI model — with no human review of borderline cases, no audit trail of the factors that drove the ranking, and no mechanism to flag demographically anomalous patterns — fails the human oversight standard. AI-assisted decisions are permissible. Fully autonomous, unreviewed decisions that affect an individual’s livelihood are a governance failure.
What Rajan is entitled to — and what the platform owes him
Under Section 11 of the DPDP Act, Rajan has the right to access a summary of what personal data the platform is processing about him and what processing activities are being undertaken. He has the right to know that a risk score or fit score has been generated, even if he does not know to ask for it.
Under Section 13, he has the right to raise a grievance about how his personal data has been processed. If the platform cannot explain, at the individual level, why its algorithm ranked him as it did — and what data drove that ranking — it cannot respond to that grievance in any meaningful way.
The algorithm decided. DPDP says that decision must be auditable, explainable, and subject to human governance. Rajan deserves at least that much.
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.
The AI That Rejected Her Home Loan Without Reading Her File
Priya is a 31-year-old schoolteacher in a village in Tirunelveli. Clean credit history. Stable government salary. Zero defaults.
She applies for a home loan through a fintech platform. Within seconds, the response arrives: Rejected.
No reason. No human. No explanation. An AI credit-scoring algorithm made the call — silently, instantly, and without looking her in the eye.
She tries a second platform. Same outcome. She begins to wonder what is wrong with her, when the real question is: what is wrong with the algorithm?
Why AI credit scoring creates a DPDP problem
IS Audit Module 6 of the ICAI IS Audit 3.0 Course is direct: AI is widely used in banking apps to provide a faster, more accurate assessment of a potential borrower at less cost, accounting for a wider variety of factors. Credit scoring provided by AI is based on more complex and sophisticated rules compared to traditional systems.
More complex. More factors. And entirely invisible to Priya.
The problem is this: Priya’s loan application was rejected because the AI model had never meaningfully encountered a borrower profile like hers — a government employee in a Tier-3 city, with a savings-heavy profile and no credit card history — trained predominantly on urban, credit-card-using, high-transaction-volume data. IS Audit Module 6 names this explicitly: datasets applicable to AI applications to learn are really rare. Models trained on incomplete data produce biased outcomes for underrepresented groups.
The algorithm was not wrong about what it was trained to do. It was wrong about what it was trained on. And Priya paid the price.
The DPDP dimension — consent was not built for this
When Priya downloaded the fintech app and applied for the loan, she tapped “I Agree” to a terms-of-service document she likely did not read in full. That consent, under the DPDP Act, 2023, is not valid for everything the AI subsequently did with her data.
Section 6(1) of the DPDP Act is unambiguous: consent must be free, specific, informed, unconditional and unambiguous, limited to such personal data as is necessary for the specified purpose.
The specified purpose was loan evaluation. But the AI ingested Priya’s location history, app usage patterns, device behaviour, social interactions, and transaction metadata — far beyond what is necessary to evaluate creditworthiness. Every data element beyond the specified purpose is processing without a valid basis.
Furthermore, if her data was used to train or refine the AI model — improving the algorithm for future use — that is a separate processing purpose that required separate consent. She did not give it. Section 6(1) requires each distinct purpose to be separately consented to.
The right she did not know she had
Under Section 11 of the DPDP Act, Priya has the right to access a summary of all personal data being processed about her — including the processing activities undertaken. She has the right to ask what the algorithm used, what it concluded, and why.
Under Section 13, she has the right to raise a grievance with the Data Fiduciary. An AI system that cannot explain its decision — cannot identify what data points drove the rejection — cannot satisfy this right. A black-box model is, under DPDP, a grievance waiting to happen.
The CERT-In Guidelines on Secure Adoption and Governance of Artificial Intelligence Systems (Version 1.0, 25 May 2026) identify Human Oversight and Decision Governance as a mandatory control: validate AI-generated outputs, restrict fully autonomous critical actions, and maintain auditability and approval mechanisms. An AI that rejects a loan application with no human review and no audit trail fails every limb of this control.
The question every AI-first fintech must answer
Can you tell Priya — specifically, in relation to her file — what personal data the algorithm used, whether that data was within the scope of her consent, and how it contributed to the rejection decision?
If the answer is “our model doesn’t work that way” — the compliance gap is not in the algorithm. It is in the governance architecture around it.
The DPDP Act is not asking AI to stop working. It is asking AI to work accountably.
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Authors: This article has been co-authored by CA. Sunil Elayadath and CA. Karthik Narayanan S, Partners of Karthik & Sunil, together with Mr. Dhanesh P. K., Designated Partner, DSK Sustainability Tech.
The DPDP Act establishes a clear and significant penalty framework. Penalties are imposed by the Data Protection Board of India after due inquiry, giving the accused an opportunity to be heard. The penalties are civil in nature — monetary fines, not criminal prosecution.
The Penalty Schedule
Breach
Maximum Penalty
Failure to implement security safeguards
₹250 crore
Failure to notify breach to Board or individuals
₹200 crore
Breach of children’s data obligations
₹200 crore
Breach of Significant Data Fiduciary obligations
₹150 crore
Any other provision of the Act or Rules
₹50 crore
Breach of duties by a Data Principal
₹10,000
What Factors Determine the Penalty Amount?
The Board does not automatically impose the maximum. It considers:
Nature, gravity, and duration of the breach
Sensitivity of the personal data involved
Whether the breach was repetitive
Whether any gain was made or loss avoided
Whether timely steps were taken to mitigate harm
The likely impact of the penalty on the organisation
Examples
Example 1 — Failure to Secure Data (₹250 crore) A large e-commerce platform stores millions of customer records — names, addresses, and payment details — without encryption or access controls. Hackers exploit this and steal the data. The platform had no reasonable safeguards in place. The Board finds them liable for up to ₹250 crore.
Example 2 — Failure to Report a Breach (₹200 crore) A telecom company discovers that its customer database has been compromised. Instead of notifying the Board and affected customers promptly, it delays disclosure for weeks hoping to manage the situation internally. This failure to notify attracts a penalty of up to ₹200 crore.
Example 3 — Children’s Data Violation (₹200 crore) An ed-tech platform collects data of students under 18 without obtaining verifiable parental consent. It also runs targeted advertisements directed at children on its platform. Both violations together attract a penalty of up to ₹200 crore.
Example 4 — Significant Data Fiduciary Default (₹150 crore) A major social media platform notified as a Significant Data Fiduciary fails to appoint a Data Protection Officer based in India and does not conduct its mandatory annual Data Protection Impact Assessment. The Board imposes a penalty of up to ₹150 crore.
Example 5 — Data Principal Misuse (₹10,000) An individual files repeated false complaints against a company with the Data Protection Board, with no genuine grievance. The Board finds the complaints frivolous and imposes a penalty of up to ₹10,000 on the individual.
Can the Government Go Further?
Yes. If the Board reports that penalties have been imposed on a Data Fiduciary on two or more occasions, the Central Government may direct platforms and intermediaries to block public access to that organisation’s services in India — making repeat non-compliance an existential risk for businesses.
The Key Takeaway
Penalties under the DPDP Act are not symbolic. They are substantial, scalable, and designed to deter. Compliance is not a one-time exercise — it is an ongoing obligation, and the cost of ignoring it far exceeds the cost of getting it right.
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Consent is the foundation of the DPDP Act. Before collecting or processing any personal data, a Data Fiduciary must obtain consent that meets every one of the following conditions. If even one condition is missing — the consent is invalid.
The Five Pillars of Valid Consent
Free — Consent must not be forced, pressured, or made a condition for a service where the data is not genuinely necessary. The individual must have a real choice.
Specific — Consent must be tied to a clearly defined purpose. A blanket “I agree to everything” is not valid. Each purpose requires its own consent.
Informed — The individual must know exactly what data is being collected, why it is being collected, and what their rights are — before they consent.
Unconditional — Consent cannot be bundled with unrelated terms or conditions. It must stand on its own.
Unambiguous with a Clear Affirmative Action — Silence, pre-ticked boxes, or inaction do not count as consent. The individual must actively and clearly say yes.
What is the Notice Requirement?
Before seeking consent, every Data Fiduciary must serve a Notice to the individual. This notice must be in clear, plain language — not buried in legal jargon. It must be available in English or any language listed in the Eighth Schedule of the Indian Constitution.
The Notice must contain:
What data is being collected — A clear description of the personal data proposed to be processed.
Why it is being collected — The specific purpose for which the data will be used.
How to exercise rights — A clear explanation of how the individual can access, correct, erase their data, or withdraw consent.
How to withdraw consent — The notice must explicitly tell the individual the manner in which they can withdraw consent. This is a distinct and mandatory element, separate from the general rights section. The notice must make clear that consent is limited to data necessary for the specified purpose — the individual should understand they are not consenting to unlimited data collection. The notice must clarify that withdrawing consent will not affect the legality of processing already carried out before withdrawal — so individuals understand what withdrawal does and does not undo. For existing data collected before the Act, the notice obligation is triggered as soon as reasonably practicable — this timeline aspect was mentioned but could be more explicit.
How to complain — Details of how the individual can raise a complaint with the Data Protection Board of India.
Who to contact — Business contact information of the Data Protection Officer or a designated person who can answer questions about data processing.
What About Data Already Collected Before the Act?
If consent was obtained before the Act came into force, the Data Fiduciary must still issue a notice — as soon as reasonably practicable — informing the individual of the data held, its purpose, and how to exercise their rights going forward.
What Happens to Invalid Consent?
Any portion of consent that violates the Act is invalid to that extent. The rest of the consent may still hold — but the Data Fiduciary cannot rely on the invalid portion to justify processing.
A Practical Example
A food delivery app asks you to sign up. Before you proceed, it shows a notice stating: your name, phone number, and address will be used to deliver your orders. It tells you how to delete your account and who to contact for queries. You then tap “I Agree” — actively, not by default. That is valid consent.
If instead the app pre-ticks a box agreeing to share your data with advertising partners — that portion of consent is invalid.
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
