Cloud Dependency is No Longer Only an IT Procurement Matter; It is a Sovereignty, Economic Policy and National Security Matter

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:

ConceptWhat It Actually Means
Data ResidencyWhere 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 SovereigntyWho 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 CategoryRecommended Approach
Ordinary commercial dataGlobal cloud with DPDP compliance, robust contracts, security controls, and transfer impact assessments.
Financial, health, children’s data, public-sector databasesIndia-region storage mandated, stronger encryption, and auditable access logs.
Defence, law enforcement, judicial systems, core government identitySovereign cloud operated by Indian entities or government-controlled bodies with no foreign administrative access.
AI training datasets derived from Indian citizensSpecial 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.

Author: CA.Sunil Elayadath | Partner | Karthik & Sunil |

Cloud Dependency is No Longer Only an IT Procurement Matter; It is a Sovereignty, Economic Policy and National Security Matter

DPDP 3.2.2 : DPDP and Cloud – Case Study 2 – The Payroll Data That Left India Without Anyone Noticing

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.


DPDP 3.2.2 : DPDP and Cloud – Case Study 2 – The Payroll Data That Left India Without Anyone Noticing

DPDP 3.2.1 : DPDP and Cloud – Case Study 1 – The Cloud Vendor’s Breach. The Founder’s Problem.

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.


Sources: DPDP Act 2023 (Sections 8(1), 8(2)) | DPDP Rules 2025 (Rules 6(1)(a)(b)(c)(f), 7(2)) | ICAI IS Audit 3.0 Course — Module 6 (Section 6.3.5 — Cloud Privacy and Security Risks)


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.


DPDP 3.2.1 : DPDP and Cloud – Case Study 1 – The Cloud Vendor’s Breach. The Founder’s Problem.

DPDP 3.1.2 – Artificial Intelligence and DPDP – The Algorithm That Inherited Someone Else’s Bias — and Gave It to Him

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.

Note: The images used are AI Generated Images

DPDP 3.1.2 – Artificial Intelligence and DPDP – The Algorithm That Inherited Someone Else’s Bias — and Gave It to Him

DPDP 3.1 – Artificial Intelligence and DPDP: When the Algorithm Decides

DPDP Series 2, Episode 1.1

Priya’s Story

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.

DPDP 3.1 – Artificial Intelligence and DPDP: When the Algorithm Decides

Work from Home, Employee Monitoring & DPDP Compliance

Prefatory Note — The Policy Context

The Prime Minister’s appeal for enabling Work from Home, hybrid working arrangements, online meetings and reduced travel wherever operationally feasible deserves a positive response from employers. WFH is not merely a welfare measure — it reduces urban congestion, carbon footprint, and commuting costs, and can demonstrably improve productivity when implemented thoughtfully.

Employers who embrace WFH should do so, however, through a written WFH policy that is legally reviewed and addresses the full spectrum of applicable Indian law — including Indian labour laws (Factories Act, Industrial Disputes Act, Shops and Establishments Acts as applicable to the state of operation), employment contracts, standing orders where applicable, POSH obligations (Prevention of Sexual Harassment at the Workplace Act, 2013), applicable social security obligations (EPF, ESI, gratuity), and the Digital Personal Data Protection Act, 2023.

The DPDP dimension of Work from Home, particularly in relation to what employee monitoring an employer may or may not lawfully conduct, forms the subject matter of this advisory. Although the DPDP framework is being implemented in phases and is expected to become fully effective from May 13, 2027, organisations should use the transition period to align their WFH monitoring practices with the principles of notice, purpose limitation, data minimisation, proportionality, security and employee privacy.

Setting the Legal Framework

In the DPDP context, the employer is the Data Fiduciary — the entity that determines the purpose and means of processing personal data (Section 2(i), DPDP Act). The employee is the Data Principal — the individual to whom the personal data relates (Section 2(j)). Every monitoring mechanism deployed in a WFH environment involves the collection and processing of the employee’s personal data, and in several cases, personal data of other household members who are entirely outside the employment relationship.

The key lawful basis available to employers under the DPDP Act for processing employee data without requiring consent is Section 7(i) — which permits processing for purposes of employment or those related to safeguarding the employer from loss or liability, such as prevention of corporate espionage, maintenance of confidentiality of trade secrets, intellectual property, classified information, or provision of any service or benefit sought by a Data Principal who is an employee.

This is a legitimate use — but it is not a blanket surveillance licence. It is bounded by two fundamental constraints that apply throughout the DPDP Act.

The first is data minimisation and necessity: under Section 6(1), processing must be limited to personal data that is necessary for the specified purpose. The same principle is expressed in the Second Schedule to the DPDP Rules, which requires processing to be limited to such personal data as is necessary for such uses or achieving such purposes.

The second is proportionality: the Puttaswamy judgment (Justice K.S. Puttaswamy (Retd.) vs Union of India, 2018, included in the project knowledge base) lays down the constitutional standard — a limitation of a fundamental right is permissible only if it is designated for a proper purpose, the measures are rationally connected to that purpose, the measures are necessary in that there are no alternative measures that may similarly achieve the same purpose with a lesser degree of limitation, and there is a proper balance between the importance of the purpose and the importance of the right being limited. This proportionality doctrine — not merely statutory compliance — governs what an employer may permissibly do in a WFH monitoring context.

Issue 1 — Screen Activity Monitoring and Recording

What is collected: Application usage, websites visited, documents accessed, communications composed, work patterns, keystroke sequences, and browsing behaviour.

DPDP Analysis:

Screen monitoring limited to work-device activity during designated working hours has a defensible basis under Section 7(i) for the purpose of preventing corporate data leakage, protecting trade secrets, and ensuring compliance with confidentiality obligations. However, the following distinctions are critical.

Monitoring which applications are open, whether corporate systems are being accessed, and whether DLP alerts are triggered — these are proportionate to the stated purpose. They constitute access logs and activity metadata, not a reproduction of content.

Full-day screen recording — capturing every pixel of everything displayed on an employee’s screen continuously — is disproportionate. It records personal communications, personal browser activity, medical or financial information briefly displayed, and the content of confidential client communications. The Puttaswamy proportionality test asks whether there is a less intrusive measure that achieves the same purpose. The answer here is yes — DLP alerts, access logs, and application monitoring achieve the security objective without wholesale content surveillance.

Keystroke logging is particularly invasive. It captures passwords, personal messages, draft communications subsequently deleted, and information entirely unrelated to work. No legitimate employment purpose requires the capture of every keystroke. It fails the proportionality test.

Notice obligation: Even where Section 7(i) applies and consent is not required, Section 5 of the DPDP Act requires the employer to give the employee a notice describing the personal data being collected and the purpose. A monitoring policy must be explicitly communicated in clear and plain language — not merely buried as a clause in an employment agreement signed on joining.

Assessment: Limited, purpose-specific screen activity monitoring is defensible. Full-day screen recording and keystroke logging are disproportionate and non-compliant.

Issue 2 — Webcam Open During Working Hours (Continuous Video Feed)

What is collected: Real-time visual data of the employee, their home environment, family members, and potentially other individuals who happen to be present.

DPDP Analysis:

A continuously open webcam during working hours collects several distinct categories of personal data simultaneously, each with a distinct legal problem.

The employee’s own image is personal data under Section 2(t). Continuous live video of a person in their home environment — revealing health indicators, emotional state, domestic circumstances, and living conditions — goes well beyond what is necessary to verify that work is being performed. Login activity, task completion, and access logs establish work activity without visual surveillance of the employee’s home.

Far more seriously, the webcam captures the personal data of household members — family, children, domestic workers — who are entirely outside the employment relationship and have given no consent whatsoever. They are Data Principals under the Act with full rights. The employer has no lawful basis — neither consent under Section 6 nor legitimate use under Section 7(i) — to collect their personal data. Section 7(i) is expressly limited to employment purposes; it does not extend to surveillance of third parties who happen to share the employee’s home.

The presence of children in the webcam feed creates an additional dimension. Section 9 of the DPDP Act requires verifiable parental consent before processing the personal data of a child under eighteen years of age. A household webcam that captures a child in the background is processing a child’s personal data without any consent mechanism at all.

Assessment: Continuous webcam monitoring during working hours is legally indefensible under the DPDP Act. It collects the personal data of third parties who have given no consent, captures children’s data in violation of Section 9, and fails the proportionality test even for the employee’s own data. This practice must be discontinued.

Issue 3 — Periodic Photographs Captured via Webcam

What is collected: Timestamped still facial images of the employee at regular automated intervals.

DPDP Analysis:

A facial photograph is unambiguously personal data. Periodic automated facial photographs, particularly when used for identity verification or attendance confirmation, constitute biometric data processing. The Puttaswamy judgment extensively addresses biometric data protection internationally, noting that facial scans require explicit consent and robust safeguards — principles consistent with the DPDP Act’s consent framework.

If the employer relies on Section 7(i), it must demonstrate that periodic facial photograph capture is necessary to prevent corporate espionage or safeguard trade secrets. This argument is very difficult to sustain. Login event logs, VPN connection records, and access logs establish that an authorised employee is operating the device — without requiring the capture and storage of biometric-level facial images at regular intervals.

If the employer instead relies on employee consent under Section 6, that consent must be free, specific, informed, unconditional, and unambiguous. The Puttaswamy judgment and DPDP consent jurisprudence recognise that consent given in an employment context — where an employee may fear job loss for withholding consent — is of questionable freedom. Consent embedded in a joining formality cannot satisfy the “free” requirement of Section 6(1).

The retention of these timestamped photographs over months or years represents a significant and growing database of biometric personal data, subject to Rule 8’s erasure obligations and Rule 6’s security requirements.

Assessment: The highest-risk element of WFH monitoring. Periodic facial photograph capture via webcam is biometric data processing that fails both the proportionality test under Section 7(i) and the free consent standard under Section 6(1). This practice carries acute DPDP compliance risk and must be discontinued.

Issue 4 — IP Address Capture and Tracking

What is collected: The employee’s home IP address, from which approximate residential location and internet service provider can be derived.

DPDP Analysis:

An IP address is personal data under Section 2(t). A home IP address additionally reveals information about the employee’s private residence. Two distinct use cases must be separated.

IP address for access authentication — verifying that a VPN or corporate system connection originates from an authorised device — has a clear and defensible basis under Section 7(i). This is consistent with the CERT-In Elemental Cyber Defense Controls (ACIM.1, ACIM.2), which require unique user IDs and role-based access controls. Using IP as an authentication signal in this context is proportionate.

Continuous tracking and storage of home IP addresses over time — correlating them to build location patterns, monitoring for address changes, or retaining them as a surveillance dataset — has no proportionate justification under the legitimate use basis. It constitutes location surveillance of an employee’s private residence, with no rational connection to the purpose of protecting trade secrets or corporate data.

Additionally, an employer who stores a database of all employees’ home IP addresses creates a significant breach risk. If that database is compromised, the residential network details of every WFH employee are exposed — creating a real-world security risk for the employees themselves that the employer, as Data Fiduciary, is responsible for preventing under Rule 6(1).

Assessment: IP capture for authentication is permissible. Continuous tracking, profiling, or retention of home IP addresses as a surveillance instrument is disproportionate and non-compliant.

Issue 5 — Aggregation and Profiling

What is collected: The combination of screen data + webcam feed + facial photographs + keystroke logs + IP address + application usage = a comprehensive behavioural profile of the employee in their home environment.

DPDP Analysis:

Each element of the monitoring regime creates a data exposure. But the aggregation of these elements into a combined profile is qualitatively more invasive than any single element. The Puttaswamy judgment specifically addresses informational privacy as a distinct constitutional right — the right to control what information about oneself is collected, aggregated, and used by others.

The aggregated profile reveals not just work activity but health patterns (movement in webcam), domestic relationships (household members visible), financial circumstances (home environment), and psychological state (work patterns and response times). None of this is necessary for employment management. It is behavioural surveillance that goes far beyond the employer’s legitimate interests under Section 7(i).

Assessment: Behavioural profiling through data aggregation in a WFH context has no valid lawful basis under the DPDP Act. It is disproportionate, exceeds any employment purpose, and constitutes a systematic interference with the employee’s informational privacy.

What the Employer Should Do — The Permissible Framework

Employers have a genuine and legitimate interest in protecting confidential information, trade secrets, intellectual property, customer data, and business systems. The DPDP Act fully recognises this under Section 7(i). The question is not whether to protect these interests but how — through measures that are proportionate, transparent, and respectful of the employee’s privacy in their home.

Recommended measures that are defensible under Section 7(i):

Secure VPN access — all WFH connections should be routed through a corporate VPN, ensuring encrypted transmission and access authentication without exposing the employee’s home network. MFA for all corporate systems, particularly those accessing customer data, financial records, or intellectual property. Role-based access control (RBAC) ensuring employees can access only the data their role requires. Access logs and audit trails showing which systems were accessed, when, and by whom — without recording the content of what was viewed. DLP (Data Leakage Prevention) alerts triggered when confidential data is transmitted outside authorised channels — flagging the event, not recording all activity. Device management policies governing corporate devices used for WFH, including remote wipe capability in the event of loss or separation. Task-based performance review and deliverable tracking — the most privacy-preserving and effective form of WFH productivity management, requiring no personal data beyond work outputs.

Measures that should not be deployed without strict necessity, proportionality, explicit notice, legal review, and a valid lawful basis:

Continuous webcam monitoring during working hours. Periodic automated facial photograph capture. Full-day screen recording. Keystroke logging. Home environment surveillance of any kind. Continuous home IP address tracking or location profiling. Behavioural profiling through data aggregation.

For any such measure that an employer nonetheless believes is strictly necessary for a specific, documented security purpose, the following conditions must all be met before deployment: a written documented justification of strict necessity, a proportionality assessment demonstrating no less intrusive alternative exists, a standalone clear and plain notice to employees specifying exactly what is collected, how it is stored, who can access it, for how long, and what rights the employee has, legal review of the lawful basis, defined retention and erasure schedules under Rule 8, and a grievance mechanism under Section 13 through which employees can raise objections.

The Preferred WFH Governance Model

The preferred model for WFH governance under DPDP is trust-based, deliverable-based, and security-led — not surveillance-led.

Trust-based: employees are presumed to be performing their duties unless there is a specific, documented reason to investigate otherwise. Surveillance is not a substitute for management.

Deliverable-based: performance is measured by outputs, outcomes, and quality of work — not by hours of screen visibility or number of keystrokes. This is both more legally defensible and more effective at driving actual productivity.

Security-led: the employer’s legitimate concerns about data security and IP protection are addressed through robust technical controls — VPN, MFA, RBAC, DLP, access logs — that protect the organisation’s assets without surveilling employees’ homes.

Summary Assessment Table

WFH PracticeLawful Basis AvailableDPDP StatusRecommendation
Secure VPN accessSection 7(i) ✅CompliantImplement as standard
MFA for all systemsSection 7(i) ✅CompliantImplement as standard
Role-based access controlSection 7(i) ✅CompliantImplement as standard
Access logs and audit trailsSection 7(i) ✅CompliantImplement with retention schedule
DLP alerts (not full recording)Section 7(i) ✅CompliantImplement as standard
Task/deliverable-based reviewNo personal dataPreferred modelImplement as primary PM tool
Limited screen activity monitoringSection 7(i) — conditionalDefensible if scopedLimit to access metadata only
Full-day screen recordingNo valid basisNon-compliantDo not deploy
Keystroke loggingNo valid basisNon-compliantDo not deploy
Continuous webcam monitoringNo valid basisNon-compliantDo not deploy
Periodic webcam photographsNo valid basisNon-compliant — biometric dataDo not deploy
Home IP continuous trackingNo valid basisNon-compliantAuthentication use only
Behavioural profilingNo valid basisNon-compliantDo not deploy

The Bottom Line

WFH is now policy-positive, PM-endorsed, and legally permissible. It is a legitimate, productivity-enhancing, environmentally responsible mode of working that Indian employers should embrace wherever operationally feasible.

The monitoring architecture that accompanies it, however, must be minimal, transparent, proportionate, labour-law compliant, and privacy-preserving.

An employer who enables WFH while deploying continuous webcam surveillance, periodic facial photographs, keystroke logging, and full-day screen recording has not implemented WFH — it has installed a surveillance apparatus inside the employee’s home. That is not what the PM’s appeal envisioned, it is not what good management requires, and it is not what Indian law — including the DPDP Act — permits.

The right model is this: protect the organisation’s data and systems through robust technical controls. Measure performance through outputs and outcomes. Trust the employee with the dignity of their private home environment. And build the WFH policy on a legal foundation that will withstand scrutiny — from the Data Protection Board, from employees who know their rights, and from a workforce that will perform best when it is trusted rather than surveilled.

Source note: All DPDP analysis is derived from the Digital Personal Data Protection Act, 2023 (Sections 2(i), 2(j), 2(t), 2(u), 5, 6, 7(i), 8, 9, 12, 13), the DPDP Rules, 2025 (Rules 6, 8, Second Schedule), the Justice K.S. Puttaswamy (Retd.) vs Union of India Supreme Court judgment (2018) on the right to privacy and proportionality doctrine, and the CERT-In Elemental Cyber Defense Controls for MSMEs (Version 1.0, dated 01.09.2025). References to labour law, POSH, EPF, ESI and Shops and Establishments requirements.

Disclaimer

This note is for general informational purposes only and should not be treated as legal opinion or professional advice. The applicability of Work from Home, employee monitoring, DPDP Act requirements, and labour law obligations may vary based on the facts, sector, state laws, employment terms, and internal policies.

Organisations should obtain a specific legal opinion from a qualified advocate / labour-law expert / data-protection professional before implementing or relying on any Work from Home or employee monitoring policy.

CA.Sunil E
Partner

Work from Home, Employee Monitoring & DPDP Compliance