93+ questions, answered plainly

The Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) is India's first standalone law governing the processing of digital personal data. It sets out when an organisation (a "Data Fiduciary") may process someone's personal data, requires notice and, in most cases, consent before doing so, gives individuals ("Data Principals") a defined set of rights over their data, and creates the Data Protection Board of India to enforce the law through monetary penalties rather than criminal prosecution. It received presidential assent on 11 August 2023, but only takes effect provision by provision as the Central Government notifies each one under Section 1(2).

Not everything commenced at once. Rule 1(2) of the DPDP Rules, 2025 brought Rules 1, 2 and 17-21 into force immediately when the Rules were notified on 13 November 2025 — these cover definitions and setting up the Data Protection Board (appointing its Chairperson and Members, board procedure, and its functioning as a digital office). Rule 1(3) brings Rule 4, on Consent Manager registration, into force twelve months later, around 13 November 2026. Rule 1(4) pushes the substantive obligations — notice content under Rule 3, consent and verifiable-consent mechanics under Rules 5-16, security safeguards and breach reporting, and most Data Principal rights — to eighteen months later, around 13 May 2027, which is when organisations actually need to be compliant.

Yes, if the processing is connected to offering goods or services to individuals within India. Section 3(b) extends the Act to processing that happens entirely outside India's territory, so long as it's tied to that kind of India-facing offering — there's no requirement that your entity, staff or servers be located in India.

Yes. Section 3(a) applies the Act to any digital personal data processed within India's territory, with no condition that the individual be an Indian citizen or resident — so an Indian hotel chain processing a foreign tourist's booking data is squarely covered. The nationality-linked test in Section 3(b) only comes into play for processing that happens outside India; processing that happens inside India is covered regardless of whose data it is.

The Act is built around digital personal data. Section 3(a) applies it to personal data collected in digital form, and separately to personal data collected in non-digital form that is later digitised — so a paper form that later gets scanned or keyed into a system falls within scope from that point on. Purely paper records that are never digitised sit outside the Act, though sector-specific rules may still govern them.

No — the word "sensitive" doesn't appear anywhere in the Act or the 2025 Rules. Every category of personal data, from a person's name to her health or financial records, sits under the same single set of obligations in Sections 4 through 9; there's no separate, heightened tier of rules for what other regimes call special or sensitive categories. That's a real distinction to plan around: an organisation used to GDPR-style extra safeguards for health or biometric data won't find an equivalent carve-out here telling it where to apply more caution.

Four differences stand out. GDPR offers six alternative lawful bases including a flexible legitimate-interest balancing test, while the DPDPA's Section 4 recognises only consent and a closed, legislated list of "certain legitimate uses" under Section 7, with no open-ended interest-balancing option. The DPDPA has no separate sensitive-data category, unlike GDPR's extra conditions for health, biometric and similar data. Cross-border transfer runs in reverse — Section 16 lets government blacklist specific destination countries, so transfer is allowed by default, where GDPR requires an adequacy decision or safeguard mechanism before any transfer is permitted at all. And the DPDPA has no data-portability right comparable to GDPR Article 20, with enforcement limited to civil monetary penalties from the Data Protection Board under Section 33 — the statute itself creates no criminal offences, unlike some EU member states' national laws layered on top of GDPR.

Yes, until the DPDPA's final phase takes effect. Section 44(2)(a) of the DPDP Act omits Section 43A of the IT Act, 2000 — the provision the SPDI Rules were made under — but Section 44(2) only commences on the same eighteen-month schedule as the Act's other substantive obligations, around 13 May 2027. Until then, Section 43A and the SPDI Rules keep operating alongside whatever DPDPA provisions are already in force.

No fresh consent is required for processing where consent was already obtained. Section 5(2) covers this transition directly: for consent given before the Act's commencement, the Data Fiduciary only has to give the Data Principal a notice, as soon as reasonably practicable, describing the personal data and purpose involved, and may keep processing on the strength of the original consent until it's withdrawn. Legitimate-use processing under Section 7 is different again — it was never based on consent to begin with, so there's nothing to redo; the only question is whether the ongoing processing still fits one of Section 7's enumerated categories.

Use the time before May 2027 to build the infrastructure the Rules will actually require, rather than waiting for enforcement to start: map what personal data you hold and why, redraft notices to match Rule 3's itemised-purpose format, split consent requests by purpose instead of relying on one blanket policy, put processor contracts in place per Section 8(2), and set up the breach-notification and grievance-redressal mechanisms Sections 8(6) and 8(10) require. Doing this early is also what surfaces legacy problems — old CRM or core-banking systems never built with consent or deletion in mind — which take far longer to fix than anything else on this list.

Section 2(i) defines a Data Fiduciary as any person who, alone or together with others, determines the purpose and means of processing personal data — in plain terms, whoever decides why data is collected and how it gets used. It's a functional test based on control over those decisions, not a label an organisation chooses for itself, and it carries the Act's primary compliance burden.

A Data Processor, under Section 2(k), is any person who processes personal data on behalf of a Data Fiduciary — it acts on someone else's instructions rather than deciding the purpose and means itself. The distinction matters in practice because Section 8(1) keeps the Data Fiduciary responsible for compliance even for processing a Processor carries out on its behalf, and Section 8(2) requires that relationship to run through a valid contract; the Act itself doesn't impose direct statutory obligations on Processors the way it does on Fiduciaries.

Yes — the same organisation can be a Fiduciary for data where it decides the purpose and means, and a Processor for other data it only handles on someone else's instructions; the classification depends on the activity, not on the organisation as a whole. On joint fiduciaries, the Act doesn't use that exact label the way GDPR names "joint controllers" in Article 26, but Section 2(i) already covers the scenario by defining a Data Fiduciary as anyone who determines purpose and means "alone or in conjunction with other persons" — so multiple entities deciding jointly are simply co-equal Data Fiduciaries under that one definition.

Under Section 2(j), the Data Principal is the individual to whom the personal data relates. Where that individual is a child, the term extends to include her parent or lawful guardian, and where she has a disability with a lawful guardian, it extends to that guardian acting on her behalf.

Section 2(t) defines personal data simply as any data about an individual who is identifiable by or in relation to that data. It's a deliberately broad, identifiability-based test rather than a list of specific data types or categories, so the real question in any given case is whether the data — alone or combined with other information — can be traced back to a specific person.

Section 2(x) defines processing as any wholly or partly automated operation performed on digital personal data, and lists collection, recording, storage, use, sharing, disclosure and erasure among the operations it covers. In practice, that means almost anything done to personal data — from the moment it's collected to the moment it's deleted — counts as processing, so the definition leaves very little activity outside the Act's reach.

No. Section 3(c)(ii) excludes personal data that a Data Principal has made or caused to be made publicly available herself, or that another person was legally obligated to publish, from the Act's application entirely. The Act's own illustration is someone who publicly posts her views along with her personal data while blogging — that data falls outside the Act's reach.

Section 6(1) requires consent to be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, and limited to only the personal data necessary for the specified purpose named in the notice. Under Section 6(2), any part of a consent that would infringe the Act or another law is invalid to that extent — the Act's own illustration is a consent clause waiving the right to complain to the Data Protection Board, which is void even though the rest of the consent stands.

A pre-ticked box wouldn't, because Section 6(1) requires consent to involve a "clear affirmative action" — inaction or a default state the person never actively chose doesn't meet that bar. A click-wrap mechanism can work, but only if what it presents also satisfies the rest of Section 6 and Rule 3 — specific, itemised, in plain language, and limited to what's necessary for the stated purpose; a single "I agree" click bundling several unrelated purposes into one broad acceptance would not.

Rule 3 requires the notice to stand on its own, understandable independent of anything else the Data Fiduciary has published, and to give, at minimum, an itemised description of the personal data collected, the specified purpose(s) it will be used for, and how the person can withdraw consent, exercise her rights, or complain to the Board. Under Sections 5(3) and 6(3), the Data Principal must have the option to view this in English or in any of the languages listed in the Eighth Schedule to the Constitution — 22 languages in total.

Yes — Section 6(4) gives the Data Principal the right to withdraw consent at any time, and withdrawing has to be as easy as giving it was in the first place. Withdrawal doesn't undo processing that already happened lawfully under the earlier consent, per Section 6(5), but going forward, Section 6(6) requires the Data Fiduciary — and any Data Processor acting for it — to stop processing that person's data within a reasonable time, unless some other legal basis independently authorises continuing.

Section 7 lists specific situations where a Data Fiduciary can process personal data without consent — among them, data the Data Principal voluntarily shared for a stated purpose without objecting to its use, State processing to deliver a subsidy, benefit or licence someone previously consented to, compliance with a court order, responding to a medical emergency or a disaster, and processing for employment purposes, including protecting the employer from loss such as breaches of confidentiality or trade secrets. It's a closed, enumerated list rather than an open-ended "legitimate interest" test — if a use doesn't fit one of Section 7's specific clauses, consent is required.

Every request for consent has to be accompanied or preceded by a notice under Section 5(1), so a new consent request for a new purpose always needs its own notice covering that purpose. But once consent for a specified purpose has been given and processing continues on that same basis, the Act doesn't require re-serving notice for every subsequent interaction — the trigger is a fresh request for consent, not routine ongoing use.

Only in the narrow circumstances Section 3(c)(ii) describes — where the Data Principal herself made the data publicly available, or another person was legally obligated to publish it. That exclusion takes the processing outside the Act's application altogether, so no consent or notice is needed for it; it doesn't extend to data someone else made public about the individual without that legal obligation, or to data that's merely accessible somewhere online.

A single broad policy isn't enough on its own. Section 6(1) limits consent to the personal data necessary for the specified purpose, and Rule 3(b) requires the accompanying notice to give an itemised description of the personal data and the specific purpose(s) involved — the Act's own telemedicine illustration makes the point directly, ruling out access to a contact list bundled into consent for a service that never needed it. An all-purpose T&C document that bundles unrelated processing together under one acceptance doesn't meet that purpose-specific standard.

Not for the core employment relationship. Section 7(i) lists processing "for the purposes of employment" — including protecting the employer from loss or liability, such as preventing corporate espionage or maintaining confidentiality of trade secrets — as a certain legitimate use that doesn't require consent. That covers standard HR and workplace-security processing, though it wouldn't extend to uses of employee data unrelated to the employment relationship itself.

No re-consent is required. This is the same transitional position Section 5(2) sets out for any consent given before the Act's commencement, regardless of which regime it was originally taken under: the Data Fiduciary gives the Data Principal a notice describing the personal data and purpose as soon as reasonably practicable, and may keep processing on the strength of that earlier consent until it's withdrawn.

The Act gives Data Principals four core rights, laid out across Sections 11 to 14: the right to access a summary of what personal data a Data Fiduciary holds and how it's being processed (Section 11), the right to correction, completion, updating and erasure of that data (Section 12), the right to accessible grievance redressal from the Fiduciary or Consent Manager (Section 13), and the right to nominate someone to exercise these rights on their behalf if they die or become incapacitated (Section 14). Notably absent from this list is a right to data portability — the Act stops at access, correction and erasure.

Yes — Section 14 gives every Data Principal the right to nominate another individual to exercise their rights if they die or become incapacitated. Incapacity is defined narrowly, as an inability to exercise DPDP rights due to unsoundness of mind or bodily infirmity, so this isn't a general power of attorney; it only activates in those two circumstances, and Rule 14(4) routes the actual mechanics through the Data Fiduciary's own terms of service.

No. The Act's rights chapter (Sections 11–14) covers access, correction, erasure, grievance redressal and nomination — data portability simply isn't on that list, and nothing elsewhere in the Act creates it. This is a deliberate departure from the GDPR, which grants portability under its Article 20; the DPDP Act's drafters chose not to import it, so a Data Principal cannot demand their data in a structured, machine-readable format to hand to a competing service.

Only on request. Section 11(1)(b) gives a Data Principal the right to ask for the identities of every other Data Fiduciary and Data Processor their data has been shared with, but that's a right they have to invoke, not something a Fiduciary must volunteer upfront. The notice a Fiduciary is required to give before or with a consent request, under Section 5, only has to describe the personal data being collected and the purpose of processing — it doesn't need to name downstream recipients.

Section 15 sets five duties: comply with all other applicable laws while exercising DPDP rights, not impersonate someone else when providing personal data, not suppress material information when providing data for a government-issued document or proof of identity or address, not register a false or frivolous complaint with a Data Fiduciary or the Board, and furnish only genuinely authentic information when exercising the right to correction or erasure. These exist to stop the rights regime being used as cover for fraud, not to burden ordinary requests.

The Schedule to the Act treats any breach of a Section 15 duty — including a false or frivolous complaint — as one category, carrying a penalty that may extend to ten thousand rupees. That's a modest figure next to the up-to-two-hundred-and-fifty-crore ceiling for a Fiduciary's security failures, and deliberately so: the duty provision is meant to deter bad-faith use of the complaints system, not to punish individuals at the same scale as corporate non-compliance.

The organisation first. Section 13(3) requires a Data Principal to exhaust the grievance redressal mechanism offered by the Data Fiduciary or Consent Manager before they can approach the Board at all. Only once that internal route has been tried, and hasn't resolved things, does a complaint to the Board become available.

Not for matters the Board is empowered to handle — Section 39 expressly bars civil courts from entertaining any suit or proceeding over anything within the Board's jurisdiction under the Act, and blocks injunctions against action taken under it. Even the Board's own remedy is a monetary penalty credited to the Consolidated Fund of India under Section 33, not compensation paid to the complainant, so the Act's own machinery isn't built to award personal damages either way. Section 38 preserves whatever other laws a Data Principal might separately rely on for a damages claim, but that route sits outside the DPDP Act, not inside it.

Section 8 is the backbone: comply with the Act regardless of any contrary agreement or a Data Principal's own lapses, engage processors only under a valid contract, keep data accurate and complete where it will inform a decision about someone or be shared onward, and implement technical, organisational and security measures to prevent breaches. On top of that, a Fiduciary must notify the Board and affected individuals of any breach, erase data once consent is withdrawn or the purpose is served — and make its processors do the same — and publish a contact point while running a working grievance mechanism.

Not automatically. Section 8(9) only requires an ordinary Data Fiduciary to publish a contact point who can answer a Data Principal's questions, and explicitly treats a DPO as applying only 'if applicable.' A dedicated, India-based DPO who reports to the Board of Directors and serves as the grievance point of contact becomes mandatory only once an entity is notified as a Significant Data Fiduciary, under Section 10(2)(a) — outside that trigger, the Act leaves the role, and whether it's full-time, up to the organisation.

The Act doesn't say the role must be an employee rather than an engaged consultant — for an ordinary Fiduciary there's no DPO mandate at all, so this only matters once Significant Data Fiduciary status applies. Even there, Section 10(2)(a) requires the DPO to be an individual based in India and answerable to the Board of Directors or an equivalent governing body — a real person with direct accountability into governance, not a corporate service. A genuinely independent consultant could in principle meet that if they're personally answerable in that way, but the accountability structure the Act describes is easier to deliver through a dedicated internal appointment than a shared, part-time external one.

GDPR compliance covers most of the ground on consent hygiene and security practice, but the two laws diverge in specifics that need separate work. DPDP has no data portability right and no lawful bases beyond consent and the narrow 'certain legitimate uses' list in Section 7, so a GDPR legitimate-interest basis doesn't simply carry over — it has to be re-mapped. You'll also need DPDP-specific artefacts the GDPR doesn't require in the same form: a Section 5 notice given in the prescribed manner, with an Indian-language option under the Eighth Schedule, breach intimation to the Board within Rule 7's seventy-two-hour window, and — if you qualify as a Significant Data Fiduciary — an India-based DPO plus India-only processing for any data categories the government separately notifies.

The Act's own mechanism is contractual, not a separate compliance regime for processors: Section 8(2) only lets a Fiduciary engage a processor under a valid contract, and Section 8(1) makes the Fiduciary responsible for the Act's compliance regardless of anything the processor does or fails to do. In practice, that means the Fiduciary has to push its own obligations down through that contract — security safeguards, breach notification timelines, erasure on instruction, which Rule 6(1)(f) specifically expects to be written into the contract — and then actually verify the processor is meeting them, because the Board holds the Fiduciary accountable regardless of where the failure occurred.

Rule 6 sets a floor, not a ceiling: encryption, obfuscation, masking or virtual tokens over personal data; controls on access to the computer resources involved; visibility through logs, monitoring and review so unauthorised access can be detected and investigated; backup and continuity measures for when confidentiality, integrity or availability is compromised; and retention of those logs and the personal data itself for one year, to support that detection and investigation. Fiduciaries also have to build matching safeguard obligations into their contracts with processors, and apply technical and organisational measures broadly enough to keep all of this actually working, not just documented.

A Significant Data Fiduciary is any Data Fiduciary, or class of them, that the Central Government notifies as such under Section 10(1), based on factors including the volume and sensitivity of personal data processed, risk to Data Principals' rights, and potential impact on India's sovereignty and integrity, electoral democracy, state security or public order. It's a government designation made by notification, not a threshold a company works out for itself — so an organisation only carries SDF obligations once it has actually been named.

Once notified, an SDF must appoint a Data Protection Officer who is based in India, answerable to the Board of Directors, and serves as the grievance point of contact (Section 10(2)(a)), plus an independent data auditor to evaluate its own compliance (Section 10(2)(b)). Rule 13 then adds the operational cadence: a Data Protection Impact Assessment and an audit once every twelve months, with the person conducting them reporting significant findings directly to the Board, alongside due diligence on any algorithmic systems used to process personal data.

A Data Protection Impact Assessment is the structured exercise Section 10(2)(c)(i) describes: it documents Data Principals' rights and the purpose of processing, then assesses and manages the risk that processing poses to those rights. It's mandatory only for Significant Data Fiduciaries, and Rule 13(1) sets the cadence at once every twelve months from the date an entity is notified as an SDF — it isn't a one-off exercise, and ordinary Data Fiduciaries aren't required to do one at all.

GDPR doesn't have a single 'SDF' label — it instead triggers obligations like a mandatory DPO under Article 37 once an organisation does large-scale systematic monitoring or large-scale processing of special-category data, and a DPIA under Article 35 whenever processing is likely to result in high risk, both self-assessed by the controller against those criteria. The DPDP Act inverts that logic: SDF status is a government notification under Section 10(1), not a threshold a company works out for itself, and once notified, the DPIA and audit obligations under Rule 13 run on a fixed twelve-month cycle rather than being triggered project by project. The practical difference is who decides — under DPDP, the government designates who counts as significant, whereas under GDPR every controller has to make that call itself.

Section 2(f) sets the line at anyone who hasn't completed eighteen years — a single, flat threshold with no sliding scale for teenagers. That's notably stricter than GDPR, where the default age is 16 and member states can lower it to 13, or US law (COPPA), which stops caring at 13. For any Indian platform used by 13-17 year-olds, this means the Act treats a seventeen-year-old exactly like a nine-year-old: parental consent required, no exceptions for maturity or platform type.

Section 9(1) requires a Data Fiduciary to get the parent's (or lawful guardian's) consent before processing a child's personal data, and Rule 10 spells out how that consent has to be verified rather than just clicked through. The Data Fiduciary must do due diligence to confirm the person claiming to be the parent is an identifiable adult — either by checking identity and age details it already reliably holds on that person, or by having them voluntarily supply identity and age details directly or via a virtual token issued by an authorised entity such as a Digital Locker service. In practice, this rules out a simple age-gate checkbox; the fiduciary needs an actual verification trail tying the consent to a real, identifiable adult.

Yes — Section 9(3) is a flat ban: a Data Fiduciary shall not undertake tracking or behavioural monitoring of children, or targeted advertising directed at children. This isn't a consent-based restriction that a parent can waive; it applies regardless of what consent was obtained under Section 9(1). The only way around it is one of the narrow, specific carve-outs the Rules allow (see Rule 12 below) — there's no general "but the parent agreed" exception.

Yes, but they're narrowly scoped. Rule 12 and the Fourth Schedule exempt specific classes of Data Fiduciaries — clinical and mental health establishments, allied healthcare professionals, educational institutions, creche or day-care operators, and transport providers serving them — from the parental-consent and tracking/advertising bans in Section 9(1) and 9(3), but only to the extent the processing is needed for the health, education or safety purpose named (e.g. a school tracking students strictly for safety or academic activity, not for anything broader). Separate purpose-based exemptions cover things like real-time location tracking for a child's safety, creating an email-only account, and age verification itself. Crucially, none of this touches Section 9(2)'s ban on processing that could harm a child's well-being — that duty has no exemption at all.

Section 2(j)(ii) folds the lawful guardian into the definition of "Data Principal" for a person with disability who has one, meaning the guardian steps in and acts on her behalf much like a parent does for a child. Section 9(1) then requires the same verifiable-consent treatment as for children — the Data Fiduciary must obtain the guardian's verifiable consent before processing. Rule 11 adds a check specific to this case: the fiduciary must do due diligence to confirm the guardian was actually appointed by a court, a designated authority under the Rights of Persons with Disabilities Act 2016, or a local level committee under the National Trust Act 1999 — not just someone self-declaring as a caretaker.

This is genuinely a two-step process, not a single 72-hour deadline, and Rule 7 is explicit about the split. First, without delay (no fixed hour count, but immediately on becoming aware): the Data Fiduciary must notify each affected Data Principal directly, in plain language, covering what happened, likely consequences, mitigation steps taken, what the individual can do to protect herself, and a contact person — and separately give the Board an initial description covering the breach's nature, extent, timing, location and likely impact. Second, within 72 hours of becoming aware (or a longer period the Board permits on written request), the Data Fiduciary must send the Board a follow-up, more detailed report: updated facts and circumstances, root cause, remedial measures taken, findings on who caused the breach, and confirmation of what was told to affected individuals. So the 72-hour clock governs the detailed follow-up report to the Board specifically — the first notifications to people and the Board's initial alert are due immediately, not after 72 hours.

Rule 6 lists a floor, not a ceiling, of measures a Data Fiduciary must have in place at minimum: encrypting, masking, obfuscating or tokenising personal data; controlling access to the computer resources that hold it; keeping logs and monitoring who accesses it so unauthorised access can actually be detected and investigated; having backups and continuity measures so processing can carry on if data is compromised or lost; retaining those access logs and the personal data itself for at least one year to support detection and investigation; and building the same safeguard obligations into contracts with any Data Processor. It closes with a catch-all requiring "appropriate technical and organisational measures" generally — so satisfying the listed items alone doesn't automatically mean the bar is cleared if the overall setup is still weak.

Rule 7(2) splits this into the same two stages as the overall timeline. The without-delay notice to the Board needs a description of the breach's nature, extent, timing and location, plus its likely impact. The follow-up report, due within 72 hours (or a Board-approved extension), has to add updated and more detailed information on that same description, the broader facts, circumstances and reasons behind the breach, mitigation measures implemented or proposed, any findings on who caused it, remedial steps taken to stop it recurring, and a report on what was actually communicated to affected Data Principals. In effect, the Board first gets a flash alert, then a fuller post-mortem.

Rule 6 explicitly requires both, not just the technical items on its list. Clause (f) requires the Data Fiduciary to build reasonable-security-safeguard obligations into its contracts with Data Processors — vendor governance by name — and clause (g) closes the rule with a general requirement for "appropriate technical and organisational measures to ensure effective observance of security safeguards." So a Data Fiduciary that has encryption and access logs but no vendor contracts, internal policies or staff training hasn't actually met the rule — the organisational half carries equal legal weight to the technical half, even though it gets less attention in most compliance checklists.

Yes, by default. Section 16(1) works as a blacklist, not a whitelist: the Central Government may notify specific countries or territories to which transfer is restricted, but until it does, transfer to any country is permitted. This is the opposite of the GDPR's adequacy-first model, where transfer outside the EU needs a pre-cleared basis before it's allowed — under the DPDP Act, the default is permission, and restriction is the exception that has to be actively switched on by notification.

No. As things stand, the Central Government hasn't issued any notification under Section 16(1) naming a restricted country or territory, so the blacklist is currently empty and cross-border transfer remains broadly open by default. That can change with a single notification, and because Section 16(1) doesn't require advance warning or a transition period, a Data Fiduciary with an established transfer flow to a given country should keep an eye on this rather than assume the current openness is permanent.

No blanket localisation requirement exists — Section 16 is a permissive, blacklist-style regime, not a residency mandate. But two narrower routes can still force data to stay in India. Rule 13(4) lets the Central Government, acting on a specified committee's recommendation, direct a Significant Data Fiduciary to keep specified categories of personal data (and the traffic data describing its flow) from leaving Indian territory — a targeted, SDF-specific power, not a general one. Separately, sectoral regulators such as the RBI can and do impose their own localisation mandates on entities they regulate, entirely independent of the DPDP Act, so a payments company can face storage-in-India requirements that have nothing to do with Section 16 at all. The honest answer is "no general rule, but several ways to land in the same place depending on who you are."

Section 16(2) makes clear the DPDP Act doesn't crowd out stricter rules elsewhere: nothing in Section 16 restricts the applicability of any other law in force in India that provides a higher degree of protection or restriction on transferring personal data outside India. Practically, that means RBI's payment-data storage requirements, SEBI's rules for capital-markets entities, and IRDAI's requirements for insurers all continue to apply in full alongside the DPDP Act's permissive default — a BFSI entity can't point to Section 16's openness as a reason to ignore a stricter sectoral mandate. The DPDP Act sets a floor for cross-border transfer generally; sectoral regulators are free to build a higher wall on top of it for the entities they supervise.

Section 2(g) defines a Consent Manager as a person registered with the Data Protection Board who acts as a single point of contact letting a Data Principal give, manage, review and withdraw her consent through one accessible, transparent, interoperable platform — instead of juggling separate consent settings with every Data Fiduciary she deals with. Section 6(9) requires every Consent Manager to actually register with the Board under prescribed technical, operational and financial conditions before it can operate in that role. Under the First Schedule, a Consent Manager also has to act in a fiduciary capacity toward the Data Principal and is barred from reading the content of the personal data it helps route — it's a consent-routing layer, not a data warehouse.

Optional. Section 6(7) says the Data Principal "may" give, manage, review or withdraw her consent through a Consent Manager — it's phrased as an available channel for the individual, not an obligation imposed on the Data Fiduciary to route all consent through one. A Data Fiduciary can continue collecting and managing consent directly; a Consent Manager only enters the picture where a Data Principal chooses to use one, and the Data Fiduciary would need to be onboarded onto that platform for it to work.

Rule 4 and the First Schedule set a fairly high bar. The applicant must be a company incorporated in India with a net worth of at least two crore rupees, sound financial standing and management, adequate business prospects and capital structure, and directors and senior management with a clean reputation for fairness and integrity. Its constitutional documents (memorandum and articles of association) must lock in the conflict-of-interest obligations from the First Schedule and can only be amended with the Board's prior approval, and it must get independent certification that its consent platform meets the Board's data-protection standards before the Board will register it. This isn't a self-certification exercise — the Board actively inquires into the application and can reject it with reasons.

They share one structural idea — both are consent-based, "data-blind" intermediaries that aren't supposed to read the content of what passes through them — but they're built for different jobs. An Account Aggregator is an RBI-licensed NBFC confined to the financial sector: it moves specified financial data between regulated Financial Information Providers and Financial Information Users, strictly with the customer's consent. A Consent Manager under the DPDP Act is sector-agnostic, registered with the Data Protection Board rather than the RBI, and governs consent for any personal data processing across any Data Fiduciary that onboards onto its platform, not just financial data flows. A bank could plausibly use an Account Aggregator for financial-data sharing and separately be onboarded onto a Consent Manager's platform for its broader DPDP Act consent obligations — the two aren't substitutes for each other.

The Board can inquire into a Consent Manager's conduct on a Data Principal's complaint, or on receiving intimation of a breach of its registration conditions, and impose a penalty under Section 27(1)(c) and (d). Since the Act's penalty Schedule doesn't carve out a specific rupee cap for Consent Manager breaches the way it does for a Data Fiduciary's breach-notification or children's-data failures, a Consent Manager breach falls under the residual entry — breach of any other provision of the Act or rules — which can extend up to fifty crore rupees. Beyond financial penalty, Rule 4(5) gives the Board a separate lever entirely: after a hearing, it can suspend or cancel the Consent Manager's registration outright and issue directions to protect Data Principals' interests, which for a Consent Manager is arguably the more consequential risk since its whole business depends on staying registered.

Zero. Rule 1(3) delays Rule 4 — the actual registration rule — until one year after the Rules were published in the Gazette, and the Rules were notified on 13 November 2025, which puts the registration framework's start date at 13 November 2026. Until that date arrives, there's no mechanism by which any applicant can be registered, so however many companies are gearing up to apply, the honest count today is nil. We've written more on what this timing gap means in practice at our article on DPDPA-registered Consent Managers.

Section 8(7) sets the general rule: unless retention is needed to comply with some other law, a Data Fiduciary must erase personal data when the Data Principal withdraws consent, or as soon as it's reasonable to assume the specified purpose is no longer being served — whichever happens first. Section 8(8) treats a purpose as no longer served once the Data Principal stops approaching the fiduciary for that purpose and stops exercising her rights, for a period the Rules prescribe (which varies by class of fiduciary). On top of that, Rule 8(3) sets a general floor for everyone: personal data, traffic data and processing logs must be kept for a minimum of one year from the date of processing regardless, after which they must be erased unless another law or government notification requires longer retention.

Yes, and the trigger is scale, not just business type. The Third Schedule (under Rule 8) applies a three-year inactivity rule specifically to e-commerce entities with at least two crore registered users in India, social media intermediaries with at least two crore registered users in India, and online gaming intermediaries with at least fifty lakh registered users in India. For these, most personal data must be erased three years after the Data Principal last approached the platform for the relevant purpose or exercised her rights (or from the Rules' commencement date, if that's later) — though the Schedule carves out account-access data and stored virtual tokens usable to obtain money, goods or services, which aren't subject to this particular clock. Smaller platforms below these user thresholds fall back to the general one-year floor under Rule 8(3) instead.

Yes — deleting an account doesn't reset or erase the retention clock, because the obligation attaches to the underlying processing and its logs, not to the existence of a live account. The Rules illustrate this directly: an e-commerce platform must retain a customer's order, payment and delivery records for at least one year from the transaction under Rule 8(3), and the illustration explicitly notes this applies "even if she deletes her account." So closing an account stops future processing, but it doesn't accelerate erasure of what's already subject to a minimum retention period.

Rule 8(2) requires advance warning, not a silent deletion. At least 48 hours before the erasure period is due to complete, the Data Fiduciary must inform the Data Principal that her personal data will be erased once that period ends, unless she logs into her account, otherwise gets in touch about the specified purpose, or exercises her rights over the processing. This gives the individual a real, if narrow, last chance to re-engage before the data is actually gone — erasure under this rule isn't meant to happen without at least one prior notice.

Section 33(2) sets out seven specific factors the Board has to weigh before it fixes a penalty within the Schedule's ceiling: the nature, gravity and duration of the breach; the type and sensitivity of the personal data involved; whether the breach is part of a repeated pattern; whether the fiduciary gained or avoided a loss as a result; what mitigation steps were taken, and how quickly; whether the penalty being considered is actually proportionate and likely to deter future breaches; and the impact the penalty itself would have on the person being fined. The Schedule sets the outer limit — these seven factors are what the Board uses to land somewhere below it.

No — the DPDP Act only permits monetary penalties, imposed by the Data Protection Board under Section 33 read with the Schedule; there is no provision anywhere in the Act for imprisonment or any other criminal sanction against a Data Fiduciary, its officers, or its employees. That's a deliberate design choice, not an oversight: the 2019 draft Personal Data Protection Bill did carry imprisonment for certain violations, and Parliament dropped that approach entirely by the time the DPDP Act was passed in 2023, leaving penalties as a purely civil, monetary mechanism.

The Data Protection Board of India is established under Section 18 as a body corporate that can sue and be sued, with its composition and headquarters set by Central Government notification. Its actual powers and functions live in Section 27 — receiving and inquiring into complaints and breach intimations, directing urgent remedial measures after a breach, issuing binding directions, imposing the penalties set out in the Schedule, and registering Consent Managers under Section 6(9). Section 28 requires it to operate, as far as practicable, as a 'digital office', with complaints, hearings and decisions handled digitally by design rather than through conventional paper filing.

The fine goes to the government, not the complainant. Section 34 states plainly that all sums the Board collects as penalties are credited to the Consolidated Fund of India, and the Act gives the Board no separate power to award compensation to the Data Principal whose complaint triggered the inquiry. A complaint can still get you an urgent remedial direction or a penalty against the fiduciary — it just doesn't put money in your pocket; a civil claim outside the DPDP framework would be the route to that.

Under Section 32, a person facing Board proceedings can offer a voluntary undertaking — a commitment to take certain action, or stop taking it, within a set time, sometimes with an agreement to publicise it. Once the Board accepts the undertaking, it bars further proceedings on that same matter, functioning much like a settlement. But if the person doesn't stick to its terms, Section 32(5) treats that failure as a breach of the Act in its own right, and the Board can proceed straight to a penalty under Section 33 — capped, per Schedule item 6, at whatever would have applied to the original breach the undertaking was meant to resolve.

Section 31 gives the Board an off-ramp from a full inquiry: if it thinks a complaint is capable of being resolved that way, it can direct the parties to attempt mediation, either through a mediator they mutually agree on or through an existing mediation mechanism under Indian law. The Board doesn't conduct the mediation itself, and the decision to route a complaint there is discretionary and case-by-case — not a mandatory step every complaint has to pass through before an inquiry can proceed.

Yes, with carve-outs. Section 2(s) defines 'person' to explicitly include 'the State', so a government department processing personal data is a Data Fiduciary like any other, and the Board's powers under Section 27 apply to it in the same way. But the Act also gives government processing specific relief: Section 17(2)(a) lets the Central Government exempt notified state instrumentalities altogether where the processing serves sovereignty, security, public order or foreign relations, and Section 17(4) disapplies the Section 8(7) erasure duty and the Section 12(3) erasure-on-request right for State processing generally, plus the Section 12(2) correction/updating duty wherever that processing doesn't involve a decision affecting the Data Principal. So government bodies sit inside the Act by default, just operating under a different set of exemptions than private fiduciaries.

Section 17 carves out several categories from most of the Act's obligations. Section 17(1) exempts processing necessary for enforcing a legal right or claim, for courts, tribunals and regulators performing judicial, quasi-judicial or supervisory functions, and for preventing, detecting, investigating or prosecuting an offence. Section 17(2)(a) lets the Central Government exempt notified state instrumentalities entirely for reasons of sovereignty, security, public order or foreign relations, and Section 17(2)(b) exempts processing for research, archiving or statistical purposes — but only where the data isn't used to make any decision specific to an individual, and the processing follows prescribed standards.

Not as a blanket rule — the Act generally follows the Data Principal's location, not their nationality, and under Section 3(b) it reaches processing outside India too if it's tied to offering goods or services to people within India. The specific carve-out that does exist, under Section 17(1)(d), covers personal data of Data Principals who are outside India, processed by an India-based person under a contract with someone outside India — the classic outsourcing or BPO scenario, not foreign nationals' data in general. Processing a foreign tourist's or foreign employee's data while they're physically in India, for instance, isn't covered by this exemption at all.

Yes — Section 3(c)(i) takes personal data processed by an individual for a personal or domestic purpose out of the Act entirely. Your own phone contacts, the family photos on your device, a personal address book you keep for sending festival cards — none of that makes you a Data Fiduciary under the Act. The moment that processing stops being purely personal — say, you're running a business off that same contact list — the exemption stops applying to that activity.

Banks and NBFCs are Data Fiduciaries for the KYC, transaction and credit data they hold — that data doesn't become someone else's problem when a DSA or fintech partner collected it on the bank's behalf instead; the regulated entity stays accountable under the DPDPA regardless of who's in the middle. RBI's own grievance-redressal requirements run alongside, not instead of, the DPDPA's rights and complaint mechanisms, so the two channels need to work together rather than compete for the same complaint. See our full BFSI industry page for how KYC ownership, DSA exposure and the regulatory overlap actually play out.

E-commerce platforms often don't know everything their own site is collecting — third-party ad-tech pixels and analytics SDKs create data flows product teams rarely audit, and each one needs its own lawful basis and processor paperwork. Larger platforms (two crore or more registered users in India) also carry an added obligation under the Third Schedule: erase a Data Principal's data three years after they last interacted with the platform, unless another law requires keeping it longer. Handling deletion requests properly, and building that three-year clock into the backend, is central to this — see our e-commerce & D2C industry page for the fuller picture.

Fintech companies sit in largely the same position as banks and NBFCs: the DPDPA applies on top of whatever RBI or payment-network rules already govern them, not instead of those rules. Payment data — card details, UPI handles, transaction history — tends to warrant the same rigorous security treatment as core banking data, and vendor relationships like payment gateways, BNPL partners and co-lending arrangements create the same pass-through processor exposure banks deal with. Our BFSI industry page covers this overlap in depth, since we don't yet have a page split out for fintech specifically.

Telecom operators already run a parallel consent system for commercial communications — TRAI's TCCCPR 2018 and its Digital Consent Acquisition facility, a DLT-recorded, OTP-verified process — and that framework doesn't disappear now that DPDPA consent obligations apply too; the two need to work together, not duplicate each other badly. Call records and location data are also highly sensitive and heavily reused for internal analytics, which raises its own purpose-limitation questions. See our telecom industry page for where the two frameworks actually intersect.

Unlike banking or insurance, healthcare has no single sector regulator setting data-protection standards, so the DPDPA's own principles of data minimisation and purpose limitation have to carry the weight themselves rather than defer to some existing framework. Health data is treated as highly sensitive, and consent can't be one blanket form — what a diagnostic lab needs from a patient differs from what a hospital needs for a specific procedure, so each clinical scenario needs its own consent design. Our healthcare & life sciences industry page goes into the detail, including where research consent has to diverge from routine-care consent.

Because a large share of ed-tech users are minors, Verifiable Parental Consent under Section 9 is the obligation the entire product has to be built around, not a signup checkbox added afterward. That means real age verification paired with actual guardian approval, and it puts these platforms in the DPDPA's highest-penalty category by default even though no dedicated sector regulator oversees them. Our ed-tech industry page covers what a genuinely verifiable consent flow looks like in practice.

HR-tech and staffing platforms handle a wide range of personal data — salary, health records, and family information that often includes children's data via dependents on group health and insurance policies — even though none of it is individually unusual. The bigger risk is usually the vendor chain: background-verification firms, payroll processors and insurers all need proper Data Processor agreements, and group policy data still gets passed around by spreadsheet or email far more often than it should. See our HR-tech & staffing industry page for where this actually breaks down in practice.

The DPDPA carves out no exemption for AI or machine learning — training a model on personal data is processing like any other, and it needs a valid legal basis under Section 4, almost always consent, before it happens. That rules out training on scraped data, repurposed user logs, or legacy datasets collected years before the Act existed, since the Act doesn't grandfather old collection, and a deletion request has to reach data already baked into a training set, not only a database row. See our insight on what DPDPA means for AI companies for what actually needs to change in an ML pipeline.

A B2B company is still a Data Fiduciary — typically for a much smaller footprint of employees, job applicants, website enquiries and sales leads, rather than millions of end users. That's genuinely lower exposure in most cases, but it isn't zero: the same consent, notice and rights-handling obligations apply to that smaller dataset. A DPDP gap assessment is usually enough to confirm there's nothing bigger hiding underneath before moving on.

Behavioural tracking and profiling for targeted advertising need their own specific, informed consent — a general privacy-policy mention doesn't cover it, and a pre-ticked or bundled opt-in for ad tracking fails the DPDPA's standard for valid consent. Identity resolution across web, app and connected-TV touchpoints makes this harder in practice, since one person's consent state can end up fragmented across platforms that don't talk to each other. Our media & entertainment industry page covers this fragmentation problem in more depth, since advertising sits inside that industry's core data practices.

IT and ITeS companies doing outsourced work for foreign clients are usually Data Processors under the DPDPA, not Fiduciaries, for that work — the client stays accountable for its own end users' data. The real exposure isn't the outsourcer's own limited footprint of employees and leads; it's what the outsourcer's systems and staff are able to do with the client's data, where access controls, sub-processor chains and cross-border engineering access matter far more than the outsourcer's own status. See our SaaS & IT services industry page for where that exposure actually concentrates.

OTT and streaming platforms run on personalisation, and much of the data behind it — viewing history, watch-time, device signals — is captured indirectly rather than something a user consciously handed over, which still needs a clear, specific purpose disclosure. Where the audience skews toward children, the same profiling and recommendation practices trigger Verifiable Parental Consent exactly as they do in ed-tech, not a lighter version of it. Our media & entertainment industry page covers both the personalisation and child-audience angles in full.

Yes, generally — handing personal data to a government or law-enforcement body under some other law doesn't automatically take that disclosure outside the DPDPA. Section 17 does carve out specific exemptions: processing necessary to enforce a legal right, courts and regulators performing judicial or supervisory functions, and processing in the interest of preventing, detecting, investigating or prosecuting an offence. But these cover defined situations rather than every government request by default, so the basis for each disclosure still needs checking rather than assumed.

Consent alone isn't proof of compliance — organisations need to actually maintain the records that demonstrate it: consent logs tied to specific purposes, a data inventory or register of processing activities, logs of rights requests and how they were resolved, breach records, signed vendor/processor contracts, training records, and DPIA documentation if the organisation qualifies as a Significant Data Fiduciary. A DPDP gap assessment is the fastest way to see which of these already exist versus which only exist in someone's head, and our RoPA, DPDR & CDJR registers service builds the registers themselves.

A single static privacy policy covering "all our data processing" doesn't meet the DPDPA's specificity standard — each purpose needs to be itemised clearly enough that a Data Principal actually understands what's being collected and why, rather than folded into one broad blanket statement. That usually means restructuring the policy around distinct purposes rather than a relabelled old GDPR-style document with updated headings, and keeping it in sync as new processing purposes get added. Our policy drafting service handles this rewrite properly.