A privacy policy that actually complies with Indian law — starting with the fact that a child here is eighteen

Whether the Act applies to you

There is no turnover test and no employee-count test. The test is what you do with data.

Three consequences that catch businesses out.

• Paper that gets typed in is covered. Collecting on a form and entering it into a spreadsheet brings it inside the Act. “We are not a tech company” is not an answer.
• Foreign sellers are covered. A company outside India selling to Indian customers is within Section 3(b) whatever its hosting arrangements.
• The publicly-available exclusion is narrow. It covers data the person herself made public, or that somebody was legally obliged to publish. It does not cover data that a third party leaked, scraped or posted without authority.

The four words that decide everything

The whole Act runs on four defined terms, and using them precisely is what separates a real policy from a template.

“Fiduciary” is worth pausing on. Indian law uses that word for someone who holds something on trust for another and owes duties of good faith in dealing with it. The Act could have said “data controller”, as other jurisdictions do. It says fiduciary, and the framing runs through the obligations: you are not the owner of the data you hold.

Section 5 — the notice, and the language nobody plans for

Section 5(3) is the sleeper obligation. The Eighth Schedule lists the languages of India, and the Act gives the person the option to access the notice in any of them. That is not a suggestion in a guidance note; it is in the section.

For most businesses this is an operational problem rather than a legal one, and it is solvable in stages: a well-drafted, short notice is far cheaper to make available in multiple languages than a sprawling policy written by somebody paid by the page. It is one of the reasons we draft the notice and the policy as two separate documents rather than one long one.

There is also a consequence for existing users. Section 5(2) deals with personal data collected before the relevant provisions commence: the Data Fiduciary is required to give the notice as soon as reasonably practicable, and processing may continue until the person withdraws consent. So a business with an existing database is not exempt because the data is old.

Section 6 — what valid consent looks like

Take the adjectives one at a time, because each of them kills a common practice.

• Free. Consent extracted as the price of a service that does not need the data is not free.
• Specific. One tick covering marketing, profiling, sharing with partners and future products is not specific. Purposes are consented to individually.
• Informed. The Section 5 notice has to have been given first.
• Unconditional. Consent cannot be conditioned on agreeing to processing beyond what the purpose needs.
• Unambiguous, with a clear affirmative action. A pre-ticked box is not an affirmative action. Continuing to browse is not an affirmative action.
• Limited to what is necessary. Collecting a date of birth for a newsletter is outside the consent even if the person ticked the box.

Section 6(2) is the safety valve that makes all of this enforceable. A business cannot draft its way out by writing a broader consent clause, because the part that infringes the Act is invalid to that extent. Long consent language does not buy wider rights; it just creates a longer document with the same effective scope.

Section 6(7) to 6(9) introduce the Consent Manager — a registered entity through which a Data Principal may give, manage, review and withdraw consent, accountable to the Data Principal and acting on her behalf. A policy should be written so that consent obtained through such a route works without redrafting.

Withdrawal, and the comparable-ease test

The comparable-ease test is the most practically demanding sentence in the Act, because it is a design requirement rather than a drafting one. If consent was one tap in an app, withdrawal cannot be an email to a support address that replies in three working days. If consent was collected at checkout, withdrawal should be available in the account.

Two further points that policies usually get wrong. First, withdrawal does not invalidate what happened before it — Section 6(5) preserves the lawfulness of processing carried out before withdrawal. Second, withdrawal has to propagate to your processors; Section 6(6) makes you responsible for causing them to stop, which is only possible if your processor contracts say so.

Section 7 — when you do not need consent

Businesses often assume the Act is a consent statute and nothing else. It is not. Section 7 lists “certain legitimate uses” for which personal data may be processed without consent, and using the right one is often more defensible than collecting a consent that would not survive scrutiny.

• Where the Data Principal has voluntarily provided her personal data for a specified purpose and has not indicated that she does not consent to its use.
• For the State to provide a subsidy, benefit, service, certificate, licence or permit, in the circumstances the section describes.
• For performance of any function under law, or for compliance with any judgment, decree or order.
• For responding to a medical emergency involving a threat to life or immediate threat to health.
• For taking measures during an epidemic, outbreak of disease or other threat to public health.
• For safety or assistance during a disaster or breakdown of public order.
• For purposes of employment, or those related to safeguarding the employer from loss or liability — the section expressly mentions prevention of corporate espionage, maintenance of confidentiality of trade secrets, intellectual property and classified information, and provision of any service or benefit sought by an employee.

The employment limb deserves emphasis because it resolves a question every HR department asks. Employee data is generally processed under Section 7, not under consent. That is the right answer for a structural reason: consent obtained from somebody who depends on you for their livelihood is hard to call free. Our employment agreement guide and POSH compliance guide deal with the employment side; a DPDP-aware HR policy simply records that this is the basis being relied on.

Children — where the Indian Act is strictest

This is the part where an imported template does the most damage, and it starts with a definition.

Read Section 9(3) again and notice what is missing from it: any reference to consent. It is a flat prohibition. A parent cannot authorise behavioural tracking of a thirteen-year-old, because the Act does not make the prohibition consent-dependent. For any Indian platform that serves a general audience and runs behavioural advertising, this is not a policy question. It is an engineering and product question.

The practical difficulty is knowing who is a child. A tickbox saying “I am over 18” is not verifiable consent of a parent, and it is not age assurance. Nor is asking for a date of birth that the user simply types. What a business can reasonably do is proportionate to the risk of its service, and the honest position for most sites is a combination of measures: not designing for minors, age-gating where the content warrants it, acting on actual knowledge, and having a process that removes a child’s data promptly when it comes to light.

Where a GDPR template goes wrong

We are asked constantly whether an existing European-style policy can simply be relabelled. Here is the honest comparison.

The right of nomination under Section 14 is worth a sentence because it is distinctively Indian and no template contains it. A Data Principal may nominate another individual to exercise her rights under the Act in the event of her death or incapacity. If your policy does not mention it and your systems cannot record a nominee, you have a gap that an imported document will never tell you about.

Section 8 — the obligations behind the policy

Section 8 is the operational core of the Act, and it is where a policy stops being a document and starts being a description of systems you either have or do not.

• 8(1) — you stay responsible. The Data Fiduciary is responsible for complying with the Act in respect of any processing undertaken by it or on its behalf by a Data Processor. Outsourcing moves the work, not the liability.
• 8(2) — processors only under a valid contract. Not a purchase order, not clickwrap terms nobody read. A contract.
• 8(3) — accuracy. Where the personal data is likely to be used to make a decision affecting the Data Principal, or is likely to be disclosed to another Data Fiduciary, it must be complete, accurate and consistent.
• 8(4) — technical and organisational measures to ensure effective observance of the Act.
• 8(5) — reasonable security safeguards to prevent a personal data breach. This is the obligation carrying the largest penalty in the Schedule.
• 8(6) — breach intimation to the Board and to each affected Data Principal.
• 8(7) — erasure on withdrawal or once the specified purpose is no longer served.
• 8(9) — publish the contact of the Data Protection Officer if applicable, or of a person able to answer questions about the processing.
• 8(10) — a grievance redressal mechanism.

Notice how few of these are satisfied by writing anything. Eight of the nine describe something you have to do. This is why we refuse to hand a client a policy without first having the mapping conversation: a policy that describes a breach process, a retention schedule and a grievance route that do not exist is a signed statement of what you were supposed to have.

Retention and erasure

“Keep everything forever, storage is cheap” is no longer a defensible position, and Indian businesses have almost universally operated that way. The Act requires the opposite default.

What this means in practice is a written retention schedule: for each category of data, the purpose, the basis, how long it is kept, what triggers deletion, and what statutory retention requirement (tax, company law, labour records) overrides erasure. Building it is unglamorous, and it is the single most useful compliance artefact a business can have — because it is what turns a vague policy sentence into something staff can follow.

Note the last clause: you must also cause your processors to erase. A deletion process that clears your database but leaves the data in your email platform, your analytics warehouse and your backup vendor has not done what Section 8(7) requires.

Breach — who you have to tell

Section 8(6) requires intimation, in the event of a personal data breach, to the Board and to each affected Data Principal, in such form and manner as may be prescribed.

Two features distinguish this from what most businesses expect.

• No threshold appears in the section. Regimes elsewhere excuse notification where a breach is unlikely to result in risk to individuals. The Indian section as enacted does not carry that qualifier on its face.
• Individuals are told directly. Not only the regulator. Every affected person.

The Schedule prescribes a penalty of up to two hundred crore rupees for failure to give that intimation — separately from the penalty for the failure of security that allowed the breach. An organisation can therefore be penalised twice over for the same incident: once for the safeguards and once for the silence.

Because the prescribed form and manner are matters for the rules, and the rules position evolves, we confirm the current requirement when we set the process up rather than printing a timeline on a page that ages.

Processors, vendors and the written contract

Most businesses have more processors than they think. A short audit usually turns up a cloud host, an email service, an analytics tool, a payments gateway, a CRM, a helpdesk, a payroll provider, an accounting package, a backup service and two or three marketing tools nobody remembers signing up for.

Section 8(2) permits engaging a Data Processor to process personal data on the Data Fiduciary’s behalf only under a valid contract. Each of those vendors therefore needs one, and what it needs to say follows from the Act rather than from any template.

• Process only on the Data Fiduciary’s documented instructions, and only for the stated purposes.
• Maintain reasonable security safeguards, described rather than asserted.
• Notify the Data Fiduciary immediately on becoming aware of a breach — because your Section 8(6) clock effectively starts with their knowledge.
• Assist with rights requests, including correction and erasure.
• Erase or return the data at the end, and erase on instruction under Section 8(7).
• Not engage a sub-processor without authorisation, and flow the same terms down.
• Confidentiality obligations on the personnel who touch the data.

Where a global vendor offers only its own standard terms, the practical answer is to read them and record the gaps against this list, rather than assume that a document called a data processing addendum does what the Indian Act requires. Our data processing agreement service covers both drafting your own and reviewing what a vendor has put in front of you.

Significant Data Fiduciaries

Section 10 allows the Central Government to notify any Data Fiduciary or class of Data Fiduciaries as a Significant Data Fiduciary, having regard to the volume and sensitivity of the personal data processed, the risk to the rights of Data Principals, the potential impact on the sovereignty and integrity of India, the risk to electoral democracy, security of the State, and public order.

Being notified brings three additional obligations.

• A Data Protection Officer who is based in India, represents the Significant Data Fiduciary under the Act, is responsible to the Board of Directors or similar governing body, and is the point of contact for the grievance redressal mechanism.
• An independent data auditor to evaluate compliance.
• Periodic Data Protection Impact Assessment and periodic audit, and such other measures as may be prescribed.

Most businesses reading this will not be notified. It is still worth knowing the shape of the obligations, for two reasons: a growing platform can cross into this category, and large customers increasingly ask smaller vendors to meet parts of this standard by contract even where the statute does not require it.

The four rights, and answering them

Section 13 carries a design implication that businesses tend to welcome: your grievance mechanism is the first forum, and it has to be exhausted before the person may approach the Board. A grievance process that works, answers within the prescribed period and keeps a record is therefore not just a compliance item. It is your opportunity to resolve a complaint before a regulator sees it.

The duties the Act puts on the user

A feature with no European counterpart, and one worth knowing about.

The Schedule provides for a penalty of up to ten thousand rupees for breach of these duties. In practice this is unlikely to be the centre of anybody’s compliance programme, but it does two useful things: it gives a business a legitimate answer when a complaint mechanism is being abused, and it signals that the Act is framed as a balance of obligations rather than as a one-way street.

Sending data outside India

This is where the Indian approach diverges most sharply from what an internationally-advised business expects.

So the default is permission, and restriction arrives by notification. There is no adequacy assessment to obtain and no standard contractual clauses to execute as a precondition. A business checks whether the destination has been restricted.

Section 16(2) is the qualifier that catches people. Sectoral rules that are stricter survive. Rules made by financial sector regulators about where certain data must be stored, and similar requirements in other regulated sectors, continue to apply on their own terms. A business in a regulated sector cannot read Section 16 alone and conclude that transfers are unrestricted.

What it costs to get wrong

The Schedule to the Act sets out the penalties the Data Protection Board may impose after an inquiry, and the numbers changed the conversation in Indian boardrooms.

The Board determines the amount after an inquiry, having regard to matters the Act specifies — including the nature, gravity and duration of the breach, the type of personal data affected, whether the breach is repetitive, whether the person realised a gain or avoided a loss, what mitigating action was taken and how promptly, and the likely effect of the penalty.

That list is worth reading as a to-do list rather than as a threat. “What mitigating action was taken and how promptly” is the item most within your control, and it is decided by whether you had a process before the incident rather than by what you improvise after it.

Because the commencement of different provisions and the content of the rules are still being settled, we do not print compliance deadlines on this page. We confirm the current position when you engage us, and we build the documents so that they do not need rewriting when a date arrives.

Employee data

Every employer processes personal data about its workforce, and the question of basis comes up immediately.

As set out above, Section 7 provides for processing for purposes of employment or those related to safeguarding the employer from loss or liability. That is the ordinary basis for payroll, administration, performance management, access control and the protection of confidential information — not consent, which is difficult to characterise as free in an employment relationship.

Three practical points follow.

• An employee privacy notice is a separate document. Your website policy speaks to customers. The workforce needs its own, covering recruitment, employment and what happens after exit.
• Monitoring needs care. Section 7 supports processing to safeguard the employer from loss or liability, including protection of trade secrets and confidential information — but the measure still has to be proportionate, and the workforce should know it exists. Our confidentiality guide covers the contractual side.
• Retention after exit. Statutory records have their own retention periods and must be kept; the rest should be governed by your schedule rather than kept by default. Our employment agreement guide and POSH guide cover the records those regimes require.

What a real policy contains

Here is the structure we use, and the reason each part is there.

The policy is then paired with a short notice shown at the point of collection, because Section 5 requires the notice to accompany or precede the request for consent. Making the whole policy do both jobs produces a document too long to read at a signup screen and too thin to cover the obligations.

Where businesses go wrong

What we do, and what it costs

A DPDP-compliant privacy policy starts at ₹3,999 and ordinarily takes 2 – 5 days. We do not send a questionnaire and return a template. We have a mapping conversation first, because a policy that does not match your actual processing is a liability rather than a protection.

Where the scope is wider than a website — multiple products, an app, a call centre, a regulated sector — the right starting point is our DPDP compliance review. Where you also need website terms, a refund policy and a disclaimer, the website legal pack covers the set. Nothing is payable in advance, and on the first call we will tell you honestly whether you need the full review or only the policy.

If the last answer is yes, fix that first. Everything else on the list is a gap. That one is a statement.