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

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

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 Series 1.8: Penalty under DPDP Act, 2023

Penalties Under the DPDP Act, 2023

The DPDP Act establishes a clear and significant penalty framework. Penalties are imposed by the Data Protection Board of India after due inquiry, giving the accused an opportunity to be heard. The penalties are civil in nature — monetary fines, not criminal prosecution.


The Penalty Schedule

BreachMaximum Penalty
Failure to implement security safeguards₹250 crore
Failure to notify breach to Board or individuals₹200 crore
Breach of children’s data obligations₹200 crore
Breach of Significant Data Fiduciary obligations₹150 crore
Any other provision of the Act or Rules₹50 crore
Breach of duties by a Data Principal₹10,000

What Factors Determine the Penalty Amount?

The Board does not automatically impose the maximum. It considers:

  • Nature, gravity, and duration of the breach
  • Sensitivity of the personal data involved
  • Whether the breach was repetitive
  • Whether any gain was made or loss avoided
  • Whether timely steps were taken to mitigate harm
  • The likely impact of the penalty on the organisation

Examples

Example 1 — Failure to Secure Data (₹250 crore) A large e-commerce platform stores millions of customer records — names, addresses, and payment details — without encryption or access controls. Hackers exploit this and steal the data. The platform had no reasonable safeguards in place. The Board finds them liable for up to ₹250 crore.

Example 2 — Failure to Report a Breach (₹200 crore) A telecom company discovers that its customer database has been compromised. Instead of notifying the Board and affected customers promptly, it delays disclosure for weeks hoping to manage the situation internally. This failure to notify attracts a penalty of up to ₹200 crore.

Example 3 — Children’s Data Violation (₹200 crore) An ed-tech platform collects data of students under 18 without obtaining verifiable parental consent. It also runs targeted advertisements directed at children on its platform. Both violations together attract a penalty of up to ₹200 crore.

Example 4 — Significant Data Fiduciary Default (₹150 crore) A major social media platform notified as a Significant Data Fiduciary fails to appoint a Data Protection Officer based in India and does not conduct its mandatory annual Data Protection Impact Assessment. The Board imposes a penalty of up to ₹150 crore.

Example 5 — Data Principal Misuse (₹10,000) An individual files repeated false complaints against a company with the Data Protection Board, with no genuine grievance. The Board finds the complaints frivolous and imposes a penalty of up to ₹10,000 on the individual.


Can the Government Go Further?

Yes. If the Board reports that penalties have been imposed on a Data Fiduciary on two or more occasions, the Central Government may direct platforms and intermediaries to block public access to that organisation’s services in India — making repeat non-compliance an existential risk for businesses.


The Key Takeaway

Penalties under the DPDP Act are not symbolic. They are substantial, scalable, and designed to deter. Compliance is not a one-time exercise — it is an ongoing obligation, and the cost of ignoring it far exceeds the cost of getting it right.


Disclaimer

The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.

The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.

Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.

The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.

DPDP Series 1.8: Penalty under DPDP Act, 2023

DPDP Series 1.7: Consent

What is Valid Consent Under the DPDP Act?

Consent is the foundation of the DPDP Act. Before collecting or processing any personal data, a Data Fiduciary must obtain consent that meets every one of the following conditions. If even one condition is missing — the consent is invalid.


The Five Pillars of Valid Consent

Free — Consent must not be forced, pressured, or made a condition for a service where the data is not genuinely necessary. The individual must have a real choice.

Specific — Consent must be tied to a clearly defined purpose. A blanket “I agree to everything” is not valid. Each purpose requires its own consent.

Informed — The individual must know exactly what data is being collected, why it is being collected, and what their rights are — before they consent.

Unconditional — Consent cannot be bundled with unrelated terms or conditions. It must stand on its own.

Unambiguous with a Clear Affirmative Action — Silence, pre-ticked boxes, or inaction do not count as consent. The individual must actively and clearly say yes.


What is the Notice Requirement?

Before seeking consent, every Data Fiduciary must serve a Notice to the individual. This notice must be in clear, plain language — not buried in legal jargon. It must be available in English or any language listed in the Eighth Schedule of the Indian Constitution.

The Notice must contain:

What data is being collected — A clear description of the personal data proposed to be processed.

Why it is being collected — The specific purpose for which the data will be used.

How to exercise rights — A clear explanation of how the individual can access, correct, erase their data, or withdraw consent.

How to withdraw consent — The notice must explicitly tell the individual the manner in which they can withdraw consent. This is a distinct and mandatory element, separate from the general rights section.
The notice must make clear that consent is limited to data necessary for the specified purpose — the individual should understand they are not consenting to unlimited data collection. The notice must clarify that withdrawing consent will not affect the legality of processing already carried out before withdrawal — so individuals understand what withdrawal does and does not undo. For existing data collected before the Act, the notice obligation is triggered as soon as reasonably practicable — this timeline aspect was mentioned but could be more explicit.

How to complain — Details of how the individual can raise a complaint with the Data Protection Board of India.

Who to contact — Business contact information of the Data Protection Officer or a designated person who can answer questions about data processing.


What About Data Already Collected Before the Act?

If consent was obtained before the Act came into force, the Data Fiduciary must still issue a notice — as soon as reasonably practicable — informing the individual of the data held, its purpose, and how to exercise their rights going forward.


What Happens to Invalid Consent?

Any portion of consent that violates the Act is invalid to that extent. The rest of the consent may still hold — but the Data Fiduciary cannot rely on the invalid portion to justify processing.


A Practical Example

A food delivery app asks you to sign up. Before you proceed, it shows a notice stating: your name, phone number, and address will be used to deliver your orders. It tells you how to delete your account and who to contact for queries. You then tap “I Agree” — actively, not by default. That is valid consent.

If instead the app pre-ticks a box agreeing to share your data with advertising partners — that portion of consent is invalid.


Disclaimer

The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.

The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.

Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.

The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.

DPDP Series 1.7: Consent

DPDP Series 1.6: Services to Indian Individuals by Foregin Entity

I’m a US Citizen Providing Services to Indians. Am I Covered Under the DPDP Act?

The short answer is — Yes, very likely.

The DPDP Act, 2023 is not limited to organisations or individuals based in India. Its reach is intentionally extraterritorial, designed to protect Indian individuals regardless of where the entity collecting their data is located.


What Does the Act Say?

The Act applies to the processing of digital personal data in two scenarios:

Within India — Any personal data collected in digital form (or digitised from non-digital form) within the territory of India.

Outside India — Any processing of digital personal data outside India, if such processing is in connection with offering goods or services to individuals in India.

This second provision is what covers you directly as a US-based service provider.


Does This Apply to Me?

Ask yourself these questions:

Do you collect personal data of individuals located in India? If yes — names, email addresses, phone numbers, payment details, usage behaviour — you are processing personal data of Indian Data Principals.

Do you offer goods or services to individuals in India? If your platform, app, or service is accessible to and targeted at Indian users — even if your servers are in the US — you fall within the scope of the Act.

Do you receive payment or registrations from Indian users? If Indian individuals are signing up, subscribing, or transacting with you, you are offering services to Data Principals within India.

If your answer to any of the above is yes, the DPDP Act applies to you.


What Are Your Obligations?

As a Data Fiduciary operating from outside India, you must:

  • Obtain free, informed, and unambiguous consent from Indian users before collecting their data
  • Provide a clear notice describing what data is collected and why
  • Use the data only for the stated purpose
  • Implement reasonable security safeguards to prevent breaches
  • Delete the data once the purpose is served or consent is withdrawn
  • Report breaches to the Data Protection Board of India and affected users promptly

Are There Any Restrictions on Sending Data Back to the US?

Yes, potentially. The Central Government has the power to restrict transfer of personal data to specific countries. If India notifies the US as a restricted destination, additional compliance steps may apply before you can transfer or store Indian users’ data on US servers.


What Happens If You Don’t Comply?

Non-compliance exposes you to penalties imposed by the Data Protection Board of India — up to ₹250 crore for security failures and up to ₹200 crore for failure to report a breach. The Board has jurisdiction over processing that affects Indian Data Principals, regardless of where you are based.


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.

DPDP Series 1.6: Services to Indian Individuals by Foregin Entity

DPDP Series 1.5: Data Breaches

What is a Data Breach?

A personal data breach under the DPDP Act, 2023 is any unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data — that compromises its confidentiality, integrity, or availability.

In plain terms: if personal data ends up where it shouldn’t, gets changed without authorisation, or becomes inaccessible when it should be available — it is a breach.


How Does a Breach Happen?

Breaches can occur in many ways — through external attacks, internal negligence, or simple system failures.

Example 1 — Cyberattack A hospital’s patient database is hacked. Names, phone numbers, diagnoses, and medical histories of thousands of patients are stolen and published online. This is a breach of confidentiality.

Example 2 — Accidental Disclosure An HR executive accidentally emails salary slips of 500 employees to the wrong mailing list. The data was not stolen — but it was disclosed without authorisation. Still a breach.

Example 3 — Insider Threat A bank employee downloads and sells customer account details to a third party for personal gain. This is unauthorised processing — a serious breach.

Example 4 — Ransomware Attack A company’s servers are encrypted by ransomware. All customer data becomes inaccessible. Even though data was not stolen, loss of availability is a breach under the Act.

Example 5 — Third-Party Vendor Failure A Data Fiduciary shares customer data with a cloud service provider (Data Processor). The vendor suffers a security failure and the data is exposed. The Data Fiduciary remains accountable.


What Must a Data Fiduciary Do After a Breach?

The Act imposes a strict response obligation:

Notify immediately — Inform every affected Data Principal about the nature of the breach, its likely consequences, and the steps being taken to contain it.

Report to the Board — Intimate the Data Protection Board of India with full details: the root cause, timeline of events, persons responsible, mitigation measures taken, and steps to prevent recurrence.


What Are the Consequences?

Failure to implement safeguards that could have prevented the breach attracts a penalty of up to ₹250 crore. Failure to notify the Board or affected individuals attracts up to ₹200 crore — both imposed by the Data Protection Board.


The Key Takeaway

A breach is not just a hacking incident. Sending data to the wrong person, losing a device with unencrypted data, or a vendor’s server going down — all can qualify. The obligation to protect data, and to respond swiftly when things go wrong, rests squarely on the Data Fiduciary.


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.

DPDP Series 1.5: Data Breaches

DPDP Series 1.4: Data Fiduciary – Obligations

Am I a Data Fiduciary? What Are My Obligations?


Q: How do I know if I am a Data Fiduciary?

If your organisation decides why and how personal data is collected and processed — you are a Data Fiduciary. This includes businesses, hospitals, schools, employers, apps, government bodies, and NGOs. Size does not matter; if you collect personal data of individuals in India, you qualify.


Q: Do I need consent before collecting data?

Yes. Before collecting any personal data, you must give the individual a clear notice describing what data is being collected and why. Consent must be free, specific, informed, and unambiguous.


Q: Can I collect more data than I need? No. You may only collect data that is necessary for the stated purpose. Collecting excess data is a violation of the Act.


Q: How long can I keep the data?

Only as long as the purpose requires. Once the purpose is served or the individual withdraws consent, you must delete the data — unless a law requires you to retain it for a specific period.


Q: What security measures must I put in place?

You must implement reasonable technical and organisational safeguards — including encryption, access controls, monitoring logs, and data backups — to prevent unauthorised access or breaches.


Q: What must I do if there is a data breach?

You must immediately notify the Data Protection Board and every affected individual, describing the nature of the breach, its likely impact, and the steps being taken to contain it.


Q: Must I have a grievance mechanism?

Yes. Every Data Fiduciary must establish an effective grievance redressal system and publish contact details of a person who can respond to Data Principal queries.


Q: What are the penalties for non-compliance?

Penalties can reach up to ₹250 crore for failure to implement security safeguards, and up to ₹200 crore for failure to report a breach — imposed by the Data Protection Board.


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.

DPDP Series 1.4: Data Fiduciary – Obligations

DPDP Series 1.2: Roles under DPDP Act

Who Am I? Know Your Role Under the DPDP Act


Q: What is a Data Principal?

You are a Data Principal if you are the individual whose personal data is being collected. Every time you fill a form, sign up for an app, or share your details with a business or government portal — you are the Data Principal. You have the right to access, correct, erase your data, and withdraw consent at any time.


Q: What is a Data Fiduciary?

You are a Data Fiduciary if your organisation decides why and how personal data is collected and used. Banks, hospitals, e-commerce platforms, employers, and government bodies are all Data Fiduciaries. You must obtain consent, give prior notice, secure the data, report breaches, and delete data once the purpose is served.


Q: What is a Data Processor?

You are a Data Processor if you handle personal data on behalf of a Data Fiduciary — under a contract, not on your own initiative. Cloud providers, payroll vendors, and IT service companies typically fall here. You follow instructions; the Fiduciary remains legally accountable.


Q: What is a Significant Data Fiduciary?

You are a Significant Data Fiduciary (SDF) if the Central Government notifies you as one — based on the volume or sensitivity of data you process, risk to individuals’ rights, or implications for national security. As an SDF, you must additionally appoint a Data Protection Officer (based in India), conduct annual Data Protection Impact Assessments, and undergo independent data audits.


Q: Can I be more than one?

Yes. A company can be both a Data Fiduciary (for its customers’ data) and a Data Processor (for data it handles on behalf of another business). Roles depend on context, not just who you are.


Q: What if I’m just an individual using data for personal purposes?

The Act does not apply to data processed purely for personal or domestic use. If you’re not collecting data as part of a business or service, you fall outside the Act’s scope.


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.

DPDP Series 1.2: Roles under DPDP Act