5.5 Governance, compliance and Indian data law

Quotes the Digital Personal Data Protection Act, 2023 (sections 5, 6 and 8); checked August 2026

What this is and why it exists

Governance is what keeps a cloud estate from becoming forty accounts nobody can name, and compliance is what happens when somebody asks you to prove it. For anyone building in India there is now a specific law to answer to — the Digital Personal Data Protection Act, 2023 — and this lesson gives you both halves: the structures that make an account governable, and the obligations the Act actually places on you, from its own text.

The vocabulary

  • Account, project or subscription — the provider's top-level container; the unit that limits how far a mistake spreads.
  • Blast radius — how much a single compromise or error can reach.
  • Organisation policy (or guardrail) — a rule applied above accounts that no policy inside them can override.
  • Tagging standard — an agreed set of labels on every resource, so that cost and ownership are answerable.
  • Data Principal — in the Act's words, the individual to whom the personal data relates.
  • Data Fiduciary — the person or entity that determines the purpose and means of processing personal data.
  • Consent — under the Act, permission that is free, specific, informed, unconditional and unambiguous.
  • Audit evidence — the artefacts that show a control was in force, not merely intended.

The mental model

Structure first, because it decides how much anything else costs. The account is the strongest boundary any provider offers: separate accounts for production and non-production mean a mistake in development cannot reach customer data, and a compromised development credential is not a production credential. The usual arrangement is one organisation containing several accounts — production, staging, development, and a separate one holding the audit logs — with guardrails applied at the organisation level. The reason to do this early is that splitting later means moving live resources, and nobody has ever enjoyed that.

Guardrails are the deny-by-default idea from the identity topic, applied above accounts: no regions outside the ones you have chosen, no turning off the audit log, no making storage public. They cost nothing while nobody is doing anything wrong and they are the only control that keeps working when somebody is in a hurry. Tagging is the same instinct pointed at accountability — an owner, an environment and a cost centre on every resource — and it is what makes the question "what is this and who pays for it" answerable rather than archaeological. Enforce it with a guardrail, or it will be applied to the resources created in the first fortnight and nothing after.

Now the Act, and it is worth learning properly rather than by rumour. It gives two roles: the Data Principal is the individual the data is about, and the Data Fiduciary is whoever determines why and how it is processed — which is you, for the application you build, even if a provider stores the bytes. Processing personal data generally requires consent, and Section 6 defines what consent must be: free, "given without her being subjected to any deceptive or manipulative practice"; specific, "not for more than the specified purpose and, if the purpose changes, then a fresh consent"; informed; unconditional; and unambiguous, "expressed by way of any clear affirmative action and not by mere inaction or disengagement". A pre-ticked box is not consent, and neither is a bundled agreement that makes access conditional on permissions unrelated to the service.

Consent is preceded by notice. Section 5 requires every request for consent to be "accompanied or preceded by a notice", telling the person the personal data and the purpose for which it is proposed to be processed, how they may exercise their rights, and how they may complain to the Board — and Section 5(3) requires the option to read that notice in English or any language in the Eighth Schedule to the Constitution. For a product used by students across India, that last requirement is a design constraint, not a footnote.

Section 8 then places the operational obligations, and they map directly onto things you build. The Fiduciary is responsible for compliance even where a processor does the work on its behalf, and may involve one "only under a valid contract" — which is why the terms you accept from a cloud provider are part of your compliance, not separate from it. Where data will be used to make a decision affecting the person or is disclosed onward, you must "ensure its completeness, accuracy and consistency". You must take "reasonable security safeguards to prevent personal data breach". On a breach you must give "the Board and each affected Data Principal, intimation of such breach". And personal data must be erased "upon the Data Principal withdrawing her consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier", unless a law requires it kept.

Read that erasure clause next to the deletion problem from the attacks topic and you have this module's most practical instruction: purpose limitation and minimisation are not paperwork, they are architecture. Collect the fields the purpose needs and no more, because every extra field is a thing you must secure, disclose, and eventually erase from every copy. Know where the copies are before you are asked. The Act commenced in phases from 13 November 2025, with further provisions following on 13 November 2026 and 13 May 2027, so treat the specific dates as something to check rather than to remember.

Audit evidence, finally, is the difference between a control and an intention. Being able to say "we require multi-factor authentication" is not evidence; the setting, plus a report showing every account has it, is. Useful evidence is boring and generated automatically: the guardrail configuration, the audit log with its retention and its protection against deletion, a scan report from the build pipeline, a restore you performed and timed, and a record of who has access reviewed on a date. Every one of those is a by-product of doing the work properly, which is the point — a compliance questionnaire you can answer honestly is a description of a system that was built well, not a document written afterwards.

What you should now be able to explain or do

Say why accounts are the strongest boundary and describe a sensible account layout. Explain what a guardrail is and give three worth applying on day one. Define Data Principal and Data Fiduciary, and say which one you are. List the five qualities consent must have and give an example of something that fails each of two of them. State what a notice must contain and the language requirement attached to it. Recite the Section 8 obligations in your own words, and connect the erasure obligation to where your copies live. Name five pieces of audit evidence you could produce this week.

Check yourself

You are — the Fiduciary is whoever determines the purpose and means of processing. The Act makes you responsible for compliance even where a processor acts on your behalf, and permits involving one only under a valid contract.

Unambiguous — consent must be "expressed by way of any clear affirmative action and not by mere inaction or disengagement". A box the user did not tick is inaction.

The personal data and the purpose for which it is proposed to be processed, how they may exercise their rights, and how they may complain to the Board — with the option to read it in English or a language in the Eighth Schedule.

On withdrawal of consent, or as soon as it is reasonable to assume the specified purpose is no longer being served — whichever comes first — unless a law requires it to be retained.

The configuration that enforces it plus a report showing every account actually has it, dated. Evidence is a by-product of the control being real; a sentence is a by-product of intending it.

Go deeper

We haven't checked most of these for screen reader use yet.

Back to Governance, compliance and Indian data law: work through the checklist