DPDP 3.1.3: DPDP and Internet of Things (IoT) – Case Study 3 – Lakshmi’s Smart Home and the Data That Left the House

Karthik & Sunil, , , , , , Leave a comment

The Scenario

Lakshmi is a homemaker in Bengaluru. Her family uses a suite of smart home devices — a connected doorbell with a camera, a voice-activated home assistant, smart lighting controlled by an app, and a connected refrigerator that tracks grocery inventory. All devices were purchased from different manufacturers, each with its own app and privacy policy.

Over time, Lakshmi realised that advertisements on her phone were displaying products she had discussed verbally at home and items she had added to her refrigerator’s shopping list. She had never consciously consented to any of this data leaving her home and being used for targeted advertising. She also had no single point of contact to understand what data was being collected, by whom, or how to stop it.

When she attempted to delete her data from one manufacturer’s platform, she received a response that her data had been shared with “technology partners” and could not be fully recalled.

The DPDP Act Position

Lakshmi’s situation illustrates the most complex IoT-DPDP compliance scenario: the multi-vendor smart home, where data collected by one device travels through multiple Data Fiduciaries and Data Processors, none of whom have a co-ordinated compliance architecture.

First — Consent fragmentation failure. Each device manufacturer that collects personal data within Lakshmi’s home is a Data Fiduciary. Each must independently satisfy Section 5 (notice) and Section 6(1) (specific, informed, free consent). A bundled privacy policy buried in a device setup wizard does not constitute the clear, plain-language, itemised consent notice required by Rule 3 of the DPDP Rules. Moreover, oral conversations captured by a voice assistant constitute personal data under Section 2(t) of the Act — any data about an individual who is identifiable by or in relation to such data. Capturing and processing these without specific, affirmative consent is unlawful.

Second — Data sharing with technology partners as undisclosed processing. When a Data Fiduciary shares personal data with a third-party technology partner for advertising targeting, that third party is either a Data Processor or a separate Data Fiduciary. Under Section 8(2), if it is a Data Processor, the original Data Fiduciary must ensure it processes data only for the specified purpose. If the specified purpose was “device functionality” and the actual use is “advertising targeting,” the sharing is unlawful — regardless of what the fine print says.

Third — Structural inability to respond to erasure requests. Section 12(3) of the DPDP Act requires the Data Fiduciary to erase personal data on request. When the Data Fiduciary has already shared data with technology partners — who are now using it independently — the original Data Fiduciary cannot honour this obligation without binding downstream agreements that require cascading deletion. The absence of such agreements is a compliance failure at the architecture stage, not a technical impossibility.

Fourth — Children’s data risk. If Lakshmi’s home includes minor children who interact with voice assistants or other smart devices, Section 9 of the DPDP Act applies. Processing personal data of a child requires verifiable parental consent. A voice assistant that captures a child’s voice — identifiable personal data — without verifiable parental consent is in direct violation. The penalty for breach of Section 9 obligations extends to ₹150 crore under the Schedule to the Act.

The IS Audit Perspective

IS Audit 3.0 by ICAI is explicit: IoT privacy risk arises because objects within the IoT collect and aggregate fragments of data that relate to their service, and that individually innocuous data points combine to reveal sensitive attributes. Lakshmi’s scenario is the textbook illustration of this risk at the consumer level.

The Puttaswamy judgment (2018) directly anticipated this concern, observing that IoT and data mining processes together can create new knowledge about individuals — something even the individuals themselves did not possess. The court noted that this is an age of “ubiquitous dataveillance,” where users of wearable devices and smart home technology generate vast data about lifestyles, choices, and preferences without conceiving of themselves as having volunteered that data. Indian law now governs that data.

The Compliance Fix

Smart home device manufacturers and platform operators selling to Indian consumers must:

→ Provide a separate, device-specific consent notice in clear and plain language — not a buried privacy policy — before any data collection begins. Rule 3 of the DPDP Rules applies to every device sold in India that collects personal data. → Identify and disclose every “technology partner” as a named Data Processor or co-Data Fiduciary in the consent notice, along with a specific description of what data they receive and for what purpose. → Build cascading deletion mechanisms so that an erasure request to the primary Data Fiduciary propagates to all downstream Data Processors. → Implement verifiable parental consent mechanisms under Section 9 before any smart home device capable of collecting children’s data is activated in a household. → Apply transport-level encryption across all device-to-cloud data flows — IS Audit 3.0 (Section 6.5.6) identifies the lack of transport encryption as a primary IoT risk.

Lakshmi’s home was smart. Its manufacturers were not compliant.

The Central Compliance Question for IoT Deployments

The IoT-DPDP compliance challenge is, at its core, a consent architecture problem. IoT devices are designed to collect continuously, silently, and at scale. The DPDP Act requires consent to be specific, informed, and granular. These two imperatives pull in opposite directions — and organisations that do not resolve this tension before deployment will face it as an enforcement problem after 13 May 2027.

There are five questions every organisation must answer before deploying IoT systems that collect personal data:

One. Have we issued a Rule 3-compliant notice — itemised, plain-language, and device-specific — for every category of personal data our IoT system collects?

Two. Is each downstream use of that data — analytics, scoring, advertising, pricing, performance management — identified as a specified purpose at the time of initial consent?

Three. Does every vendor, cloud platform, and analytics partner in our IoT data chain have a written Data Processor contract under Section 8(2) limiting them to the specified purpose?

Four. Have we built cascading deletion mechanisms so that a Section 12(3) erasure request can be honoured across the full data chain?

Five. If children may interact with our IoT devices, do we have a verifiable parental consent mechanism that meets the Section 9 standard?

IS Audit 3.0 by ICAI sets the governance standard clearly: IoT governance must address the lifecycle of IoT devices, the data managed by the IoT solution, and IoT applications in the organisation’s IT landscape. The DPDP Act makes this governance framework legally mandatory, not merely a best practice.

What Responsible IoT and DPDP Compliance Looks Like

The DPDP Act does not prohibit IoT. It requires that every IoT deployment be designed so that Data Principal rights — consent, purpose limitation, erasure, and correction — can be meaningfully exercised.

Devices will continue to collect data. Networks will continue to transmit it. Platforms will continue to analyse it. None of that is prohibited. However, every step in that chain — from sensor to server to insight — must be governed by a consent framework that the person at the centre of it all understood and agreed to, in plain language, before collection began.

The Puttaswamy judgment (2018) described this era as one of ubiquitous dataveillance. IoT is the infrastructure of that dataveillance. The DPDP Act is the law that governs it. Together, they mean one thing for Indian organisations: design your IoT systems for privacy first, not compliance as an afterthought.

The compliance deadline is 13 May 2027. Every IoT device collecting personal data in India today is already in scope.

Sources: IS Audit 3.0, ICAI | DPDP Act 2023| DPDP Rules 2025 | Puttaswamy v 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.1.3: DPDP and Internet of Things (IoT) – Case Study 3 – Lakshmi’s Smart Home and the Data That Left the House

DPDP 3.1.2: DPDP and Internet of Things (IoT) – Case Study 2 –  Suresh and the Smart Office That Never Stopped Watching

Karthik & Sunil, , , , , Leave a comment

The Scenario

Suresh is a mid-level manager at a logistics company in Chennai. His employer had implemented an IoT-enabled smart office system — access badges tracked movement across the building, smart cameras monitored workstations, occupancy sensors logged time at desk, and a connected printer recorded who printed what and when.

All of this data flowed into a workplace analytics platform that generated individual productivity scores. Suresh was placed on a performance improvement plan based partly on his occupancy metrics — he had spent less time at his desk during a period when he was, in fact, attending client meetings in the conference rooms.

He was never told that his movement and occupancy data were being collected and used for performance evaluation. He had signed a general IT usage policy when he joined — three years before this system was installed.

The DPDP Act Position

This scenario raises three compliance failures.

First — Absence of lawful consent for a new processing purpose. Section 6(1) of the DPDP Act requires consent for each specified purpose. A general IT usage policy signed three years earlier does not constitute valid consent for IoT-based occupancy tracking and performance scoring. The purposes are different, the data categories are different, and the consequences to the employee are materially different.

Section 5(1) of the Act requires that every request for consent be accompanied or preceded by a notice informing the Data Principal of the personal data to be processed and the purpose. No such notice was given when the IoT system was deployed. Consequently, all processing of Suresh’s location and occupancy data for performance evaluation was unlawful.

Second — Use of incomplete data to make decisions affecting the Data Principal. Section 8(3) requires that when personal data is likely to be used to make a decision that affects the Data Principal, the Data Fiduciary must ensure the completeness, accuracy, and consistency of that data. Suresh’s occupancy data was accurate — he was not at his desk — but it was incomplete, because the system had no mechanism to capture the reason. An employee attending client meetings generates the same occupancy reading as one who is absent without reason. Using this data for performance decisions without ensuring completeness is a direct violation of Section 8(3).

Third — Breach of proportionality under the Puttaswamy doctrine. The Supreme Court’s judgment in Puttaswamy v Union of India (2018) established that any encroachment on informational privacy must satisfy the proportionality test: there must be a lawful basis, a legitimate aim, and the measure must be proportionate to that aim. Continuous occupancy monitoring of every employee for the purpose of productivity scoring is disproportionate to any legitimate workplace management aim — particularly when other, less invasive means of performance assessment are readily available.

The IS Audit 3.0 Perspective

IS Audit 3.0 by ICAI identifies insufficient authentication and authorisation, insecure web interfaces, and lack of transport-level encryption as key IoT risks. In Suresh’s case, the workplace IoT system aggregated movement data with no individual access controls, no audit trail for the analytics platform, and no individual visibility into what data was being collected about each employee.

IS Audit 3.0 (Governance and Controls) is direct: IoT governance must define the lifecycle of IoT data, cover the changes to IT governance for distributed IoT architecture, and ensure that the principles for managing that architecture deliver on the stated business goals. A workplace analytics platform that generates employment consequences without a lawful consent framework is not a managed system — it is an uncontrolled compliance liability.

The Compliance Fix

Employers deploying workplace IoT systems must:

→ Issue a fresh, specific consent notice — separate from general IT policies — for each new IoT deployment that collects employee personal data. → Conduct a Data Protection Impact Assessment (DPIA) under Section 10 of the DPDP Act before deploying any system that collects employee movement, biometric, or occupancy data at scale. → Ensure that any data used to make employment decisions is complete, not merely accurate — which means building context-capture mechanisms alongside sensors. → Apply proportionality: if the legitimate aim is productivity management, the least invasive means of achieving that aim should be used. Continuous movement tracking is rarely the least invasive option. → Give employees visibility into what data is being collected about them, and provide a mechanism to raise corrections under Section 12(2) of the DPDP Act.

Suresh’s employer automated its surveillance. However, it did not automate its compliance.

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.2: DPDP and Internet of Things (IoT) – Case Study 2 –  Suresh and the Smart Office That Never Stopped Watching

DPDP 3.1.1: DPDP and Internet of Things (IoT) – Case Study 1 –  When Every Device Becomes a Witness

Karthik & Sunil, , , , , , Leave a comment

INTRODUCTION

IoT and DPDP compliance represent one of the most underestimated challenges in India’s data protection landscape today.

Your fitness band knows your resting heart rate. Your smart meter knows when you wake up. Your office access badge knows exactly where you were at 9:14 am. Individually, each of these data points seems harmless. Together, however, they compose a surveillance portrait of extraordinary detail — one that its subject never agreed to provide and may not even know exists.

This is precisely the privacy risk that IS Audit 3.0 (ICAI Module 6, Section 6.5.6) identifies when it notes that IoT devices collect and aggregate fragments of data that, in combination, can reveal religion, health information, lifestyle choices, and other sensitive personal attributes — even when no single data point appears sensitive in isolation.

The Internet of Things is defined in IS Audit 3.0 (Module 6, Section 6.5.1) as a system of interrelated computing devices, mechanical and digital machines, objects, animals, or people that are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. In simple terms, devices collect, send, and act on data — largely without human involvement at the point of collection.

That last phrase is the compliance problem. The DPDP Act, 2023 is built on the premise of informed, specific, and free consent. IoT is built on the premise of seamless, continuous, and frictionless data collection. These two architectures sit in fundamental tension — and that tension has a deadline: 13 May 2027.

Three Case Study bring this tension to life.

Case Study 1 — Rohini’s Wearable and the Insurance Company That Knew Too Much

The Scenario

Rohini is a 41-year-old schoolteacher in Pune. She purchased a health insurance policy from a mid-sized insurer. As part of a wellness incentive programme, the insurer offered her a discount in exchange for syncing her fitness wearable to their app. Rohini agreed, expecting only her step count to be shared.

Over eighteen months, the wearable transmitted her heart rate variability, sleep patterns, stress indicators, menstrual cycle data, and location history to the insurer’s cloud platform. The insurer’s algorithm then recalculated her risk profile — and at renewal, her premium increased substantially. No one told Rohini that these data points were being collected, how they were being used, or that they would influence her premium.

The DPDP Act Position

Rohini’s situation discloses at least three distinct violations.

First — Consent specificity failure under Section 6(1). The DPDP Act requires consent to be free, specific, informed, unconditional, and unambiguous. It must be limited to personal data that is necessary for the specified purpose. Rohini consented to sharing her step count for a wellness discount. She did not consent to the sharing of menstrual cycle data, stress indicators, or sleep patterns. Any processing beyond the specified purpose is unlawful.

Rule 3 of the DPDP Rules, 2025 reinforces this directly. A Data Fiduciary must give notice in clear and plain language, with an itemised description of personal data to be collected and a specific description of the purpose. A general reference to “health data” does not satisfy this standard. Each category of IoT data being collected must be identified separately in the consent notice.

Second — Purpose limitation failure under Section 8(1). The purpose for which Rohini’s data was processed — premium recalculation — was never disclosed as a specified purpose at the time of consent. Consequently, processing her data for that purpose is unlawful under the Act, regardless of what the policy fine print may say.

Third — Sensitive personal data processing without adequate basis. Menstrual cycle data and health metrics constitute personal health information. While the DPDP Act does not yet have a separate “sensitive personal data” category in the manner of some foreign frameworks, Section 8(5) requires the Data Fiduciary to implement reasonable security safeguards. Moreover, when data is used to make a decision that affects the Data Principal, Section 8(3) requires the Data Fiduciary to ensure completeness, accuracy, and consistency of that data. An algorithmic premium revision based on wearable data must meet this standard.

The IS Audit 3.0 Perspective

IS Audit 3.0 (Module 6, Section 6.5.6) specifically identifies privacy concerns in healthcare IoT as a primary risk, observing that devices in this domain collect at least one piece of personal information and that the aggregation of IoT data fragments can reveal health information that was never explicitly disclosed. This aggregation risk is precisely what happened to Rohini.

Furthermore, IS Audit 3.0 (Section 6.5.7) identifies governance of IoT data as requiring a clear reference architecture, defined governance processes, and lifecycle management of the data managed by the IoT solution — none of which the insurer had implemented.

The Compliance Fix

Insurers and any organisation using wearable or health IoT data must:

→ Issue a separate, itemised consent notice for each data category collected by the device — not a single bundled consent covering “health data.” → Clearly specify every downstream use — including risk assessment, pricing, and underwriting decisions — as a stated purpose at the time of initial consent. → Ensure that data collected via wearable integration is not used for purposes beyond what was disclosed, unless fresh consent is obtained for the new purpose. → Implement data minimisation controls at the IoT gateway level, so that only the specific data categories covered by consent are transmitted to the cloud platform.

Rohini’s insurer collected far more than it disclosed. The DPDP Act calls that a violation — not a feature.

Rohini’s insurer had a wellness programme. It did not have a consent programme. Under the DPDP Act, that distinction matters enormously. The compliance deadline is 13 May 2027.

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.1: DPDP and Internet of Things (IoT) – Case Study 1 –  When Every Device Becomes a Witness

Income Tax Act, 2025: What Changes for Individual Taxpayers?

Karthik & Sunil, , , , Leave a comment

A Simpler Law, But Not a New Tax Regime

By CA Sunil Elayadath

India’s Income-tax Act, 1961 served the nation for more than six decades. During this period, it underwent thousands of amendments, resulting in a statute that became increasingly difficult to navigate, even for tax professionals.

With effect from 1 April 2026, the Income-tax Act, 2025 replaces the 1961 Act. This naturally raises an important question for millions of taxpayers:

“Will I pay more tax under the new Act?”

The short answer is No.

The Income-tax Act, 2025 is primarily a legislative reform, not a tax policy reform. The objective is to simplify the law without substantially altering the tax burden.

This article discusses what individual taxpayers should know.

1. The Objective Is Simplicity, Not Higher Taxes

One of the biggest misconceptions is that a new Income-tax Act automatically means new taxes.

That is not the case.

The CBDT has clarified that the new Act primarily aims to:

  • simplify the language;
  • consolidate scattered provisions;
  • reduce repetitive explanations;
  • improve readability; and
  • make compliance easier.

For most salaried individuals and small taxpayers, the manner of computing tax remains substantially unchanged.

2. Most Taxpayers Will Continue Paying Tax in the Same Manner

The following continue substantially in the same form:

  • Income under five heads
  • Tax deducted at source (TDS)
  • Advance tax
  • Self-assessment tax
  • Return filing
  • Refund mechanism
  • Appeals
  • Interest provisions

Therefore, taxpayers should not expect a completely new taxation system.

3. The Biggest Change Is the Structure of the Law

The 1961 Act contained hundreds of sections inserted over several decades.

The 2025 Act reorganises these provisions into a logical structure.

For example:

Earlier ActNew Act
Section 139Section 263 (Return of Income)
Sections 192–194TSections 392 & 393 (TDS)
Section 237Section 431 (Refunds)

Instead of searching through numerous sections, taxpayers and professionals will now find related provisions grouped together.

4. Section Numbers Have Changed

Perhaps the most noticeable difference for taxpayers and professionals will be the renumbering of sections.

For example:

  • Return filing provisions now appear under Section 263.
  • Most TDS provisions are consolidated under Section 393.
  • Refund provisions begin from Section 431.

While this initially requires familiarisation, the new numbering is considerably more systematic.

5. Transition Year Will Be Unique

The year 2026 will witness an interesting transition.

For example:

  • Returns for Assessment Year 2026–27 will still be filed under the Income-tax Act, 1961.
  • At the same time, advance tax for Tax Year 2026–27 will be governed by the Income-tax Act, 2025.

Therefore, for a temporary period, both Acts will operate simultaneously.

Professionals must be careful in identifying which law applies to a particular transaction.

6. TDS Has Become Easier to Understand

One of the significant drafting improvements is in the TDS provisions.

Earlier:

  • Separate sections existed for contractors, rent, commission, professional fees, dividends and several other payments.

Now:

  • Salary has been placed under Section 392.
  • Most other TDS provisions are consolidated into Section 393 in tabular form.

Although the rates and thresholds remain largely unchanged, locating the applicable provision has become much easier.

7. Refunds Continue in the Same Manner

Many taxpayers worry whether the refund process changes.

The answer is reassuring.

The principles governing:

  • excess tax paid,
  • refund claims,
  • interest on refunds,
  • adjustment against outstanding demands,

continue substantially unchanged.

8. Appeals and Pending Proceedings Are Protected

The repeal of the 1961 Act does not mean that pending proceedings disappear.

Assessments, appeals and litigation relating to earlier years continue under the old Act through detailed savings provisions.

This ensures continuity and prevents disruption to taxpayers.

9. Technology Alignment Is Better

The new Act has been drafted keeping digital tax administration in mind.

As tax compliance increasingly moves towards:

  • AIS,
  • pre-filled returns,
  • faceless proceedings,
  • online TDS reporting,

the new structure supports easier integration with technology.

10. What Should Individual Taxpayers Do?

For most taxpayers, no immediate action is required.

However, it is advisable to:

  • understand the new section numbering;
  • preserve tax records relating to earlier years;
  • verify TDS and AIS regularly;
  • consult professionals during the transition period; and
  • ensure that future references are made using the new provisions.

Conclusion

The Income-tax Act, 2025 represents one of the most significant legislative exercises in India’s tax history.

Its success will not be measured by the number of new provisions introduced, but by whether taxpayers can finally understand the law without navigating hundreds of amendments accumulated over six decades.

For individual taxpayers, the message is simple:

The law has become simpler; your tax liability has not necessarily become higher.

The real challenge lies not in learning new tax principles, but in adapting to a better organised legal framework.

Key Takeaways

  • The Income-tax Act, 2025 is primarily a simplification exercise.
  • No major increase in tax burden merely because of the new Act.
  • Section numbers have changed significantly.
  • TDS provisions are consolidated and easier to navigate.
  • Both Acts will operate simultaneously during the transition period.
  • Individual taxpayers should familiarise themselves with the new structure rather than fear major tax changes.

Author’s Note

The views expressed are personal and intended solely for educational purposes. Readers are advised to refer to the Income-tax Act, 2025, the Income-tax Rules, 2026, notifications, circulars, and professional advice before taking any action based on this article.

Income Tax Act, 2025: What Changes for Individual Taxpayers?

DPDP 3.3.3: DPDP and Blockchain – Case Study 3 – When the Ledger Never Forgets – Kaveri’s KYC That Lived Forever

Karthik & Sunil, , , , , , , , Leave a comment

The Scenario

Kaveri runs a small trading firm. As part of onboarding a fintech lending platform, she completed a KYC process in 2022. The platform had built its KYC infrastructure on a consortium blockchain shared across six lenders.

In 2024, Kaveri closed her account and formally requested that her KYC data be removed. The fintech replied that the KYC records were permanent, shared across the consortium, and could not be altered because that would “break the chain’s integrity.”

Meanwhile, one lender in the consortium — located in a foreign jurisdiction — faced a regulatory investigation. Kaveri’s personal data was accessed by foreign law enforcement as part of that investigation, without her knowledge.

The Two DPDP Act Violations

Violation one: Section 12(3) — erasure right denied. The fintech’s architecture made it structurally impossible to honour a statutory right. That is a compliance failure attributable to design, not a force majeure.

Violation two: Rule 15 of the DPDP Rules, 2025 — foreign state access restrictions. Rule 15 prohibits a Data Fiduciary from enabling foreign governments or their instrumentalities to access personal data of Indian Data Principals except through legal channels prescribed by Indian law. Kaveri’s data was accessed by a foreign authority through a consortium node without any such channel being invoked.

This is precisely the data sovereignty concern that the Puttaswamy judgment (2018) framed when it recognised informational self-determination as a fundamental right. The Supreme Court observed that humans forget, but the internet does not. Blockchain amplifies this observation: not only does the internet not forget — the chain mathematically cannot.

The IS Audit  Perspective

IS Audit course material of ICAI notes that credential security on blockchain is only as strong as the access point, and that not all participants in a public or consortium chain can be assumed to have equivalent governance standards. Furthermore, Section on Governance and Controls requires that organisations assessing blockchain solutions audit cross-border data flows as a primary governance item.

The Compliance Architecture Fix

Consortium blockchain participants must establish a data governance charter before deployment, specifying: which personal data categories may be written on-chain; cross-border node participation restrictions consistent with Rule 15; erasure and key-revocation protocols binding on all nodes; and a Data Processor contract between the consortium and each member lender covering DPDP Act obligations.

Kaveri’s case is not hypothetical. Indian KYC infrastructure today sits at exactly this intersection.

The Central Compliance Question for Blockchain Deployments

The immutability of blockchain is not, by itself, illegal under the DPDP Act. However, placing personal data directly on an immutable ledger without designing for erasure is a compliance failure. The DPDP Act does not prohibit blockchain. It requires that every technology deployment — including blockchain — be architected so that Data Principal rights can be exercised.

There are four questions every organisation must answer before writing personal data to a blockchain:

One. Can we honour a Section 12(3) erasure request without breaking the chain? If not, the architecture must change before deployment.

Two. Does every node in our network have a written Data Processor agreement under Section 8(2)?

Three. Do any nodes sit in foreign jurisdictions? If so, does Rule 15 governance apply, and is it documented?

Four. Have we used off-chain storage with on-chain hashes, or encryption-at-rest with key deletion on erasure, to build in a compliance exit?

IS Audit study material by ICAI frames this governance requirement clearly: organisations implementing or assessing blockchain solutions must evaluate legal and compliance risk as a first-order item, not an afterthought. The DPDP Act makes this mandatory. The deadline is 13 May 2027.

What Responsible Blockchain and DPDP Compliance Looks Like

The DPDP Act does not ask organisations to abandon blockchain. It asks them to build it responsibly. Consequently, the organisations that will navigate this intersection well are those that:

Design data architecture around erasure rights from day one. Keep personal data off the immutable ledger wherever possible. Use encryption and key management as a proxy for deletion where off-chain storage is not feasible. Govern every node as a Data Processor. Apply Rule 15 restrictions to every cross-border node participant. And audit the entire architecture annually under IS Audit 3.0 standards.

Blockchain is a powerful technology. The DPDP Act is a serious law. Used together — with care — they are compatible. Used carelessly, they create the hardest compliance problems in India’s data protection landscape. 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.3.3: DPDP and Blockchain – Case Study 3 – When the Ledger Never Forgets – Kaveri’s KYC That Lived Forever

DPDP 3.3.2 : DPDP and Blockchain – Case Study 2 – Meera’s Story

Karthik & Sunil, , , , , , , , , Leave a comment

She withdrew consent. The blockchain remembered anyway.

Meera consented to her medical data being stored on a hospital’s blockchain network. Three years later, she withdrew that consent and asked for her records to be removed.

The hospital recorded her withdrawal correctly. However, her personal data had already been distributed across six network nodes. Those nodes — each holding a copy — were not instructed to delete anything.

Under Section 6(4) of the DPDP Act, 2023, withdrawal of consent must be as easy as giving it. Under Section 8(1), the Data Fiduciary must cease all processing upon withdrawal. Under Section 8(2), every entity processing personal data on the Data Fiduciary’s behalf — effectively, every node — must operate under a written contract limiting processing to the specified purpose.

Meera’s hospital had a consent withdrawal mechanism. However, they had no node governance framework. That gap is the compliance failure.

IS Audit 3.0 Study material of  ICAI (Module 6) flags precisely this risk: not all data on a distributed ledger should be accessible to others, and interoperability between chains creates additional exposure that is often overlooked in deployment planning.

Three things organisations deploying blockchain for sensitive personal data must do:

→ Map every node as a potential Data Processor. Execute written contracts under Section 8(2) before deployment.
→ Design consent withdrawal to trigger cascading deletion or encryption-key revocation across all nodes simultaneously.
→ Never write raw personal data to the chain. Use pseudonymous identifiers on-chain, with personal data in a governed, erasable off-chain repository.

Meera’s hospital is rebuilding its architecture. Consequently, the cost is now far higher than it would have been at design stage.

The DPDP Act compliance deadline is 13 May 2027. Node governance is not optional.

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.3.2 : DPDP and Blockchain – Case Study 2 – Meera’s Story

DPDP 3.3.1 : DPDP and Blockchain – Case Study 1

Karthik & Sunil, , , , , , , , Leave a comment

“The blockchain won’t let me delete your data.” That is not a legal answer under Indian law.

Arjun resigned from his employer and asked them to erase his personal data. His HR team apologised — the data was on their blockchain-based verification system and, they said, could not be deleted.

Under Section 12(3) of the DPDP Act, 2023, every Data Principal has a statutory right to erasure. The Data Fiduciary must comply — unless retention is necessary for a specified purpose or legal obligation. The DPDP Act creates no exception for immutable ledgers.

Furthermore, Section 8(1) places non-derogable liability on the Data Fiduciary. An organisation cannot transfer that liability to its technology architecture.

IS Audit 3.0 by ICAI identifies legal and compliance uncertainty as a primary blockchain risk. Before the DPDP Act, that uncertainty was structural. Today, the law is clear.

The compliance design choices are not complicated — but they must be made at the architecture stage, not after deployment:

→ Store personal data off-chain. Record only a hash on the ledger. Delete the off-chain data on erasure request.
→ Alternatively, encrypt personal data before writing to the chain. On erasure request, delete the encryption key. The block remains — but it is unreadable.
→ For permissioned chains, build node-level governance with erasure-triggering protocols.

Arjun’s employer had an immutable ledger. However, they did not have an erasure plan. Those are two different problems — and only one of them was a technical constraint.

The DPDP Act compliance deadline is 13 May 2027. Blockchain architectures processing personal data today need an erasure design now.

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.3.1 : DPDP and Blockchain – Case Study 1

DPDP Meets Emerging Technologies — Episode 3 – Introduction on Blockchain & DPDP

Karthik & Sunil, , , , , , , Leave a comment

Blockchain and DPDP compliance

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.

DPDP Meets Emerging Technologies — Episode 3 – Introduction on Blockchain & DPDP

DPDP 3.2.3 : DPDP and Cloud – Case Study – The Erasure Request That Broke Three Clouds at Once

Karthik & Sunil, , , , , , , , , , Leave a comment

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.

DPDP 3.2.3 : DPDP and Cloud – Case Study – The Erasure Request That Broke Three Clouds at Once

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

Karthik & Sunil, , , , , , , , , , , , , , , , , , , Leave a comment

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