Final Rules Vs Act

Topic / Obligation

What DPDP Act states

What was unclear originally

How the Rules fill the gap

Practical implication for organizations

Notice to Data Principal

(Sec 5) Before requesting consent, a Data Fiduciary must give the Data Principal a notice informing her of the personal data being collected, the purpose of processing, how to exercise rights, and how to file a complaint.

The Act says notice must be given “in such manner as may be prescribed,” but does not specify format or content beyond the broad points. Practically, organizations did not know how detailed the notice must be or where/how to publish it.

Rule 3 spells out notice requirements in detail. It requires the notice to be standalone and in plain language. At minimum, the notice must itemize the data categories and specific purposes (and what goods/services will be provided by the processing). It must also provide a direct link or means (website/app and other methods) for the Data Principal to withdraw consent, exercise rights, or complain.

Organizations now must prepare detailed notices. For example, a website form collecting data must include a clear list of each data field and why it’s needed, plus links (or contact info) for withdrawing consent or complaining. Notices must be prominent and easy to understand, not buried in terms of service.

Consent Requirements

Consent must be “free, specific, informed, unconditional and unambiguous,” given by a clear affirmative action. It must cover a defined purpose and only necessary data. Withdrawal of consent is allowed anytime, with comparable ease

The Act defines the quality of consent but does not describe the process or documentation. It was unclear what form of action counts as “affirmative,” or how to obtain and record consent.

The Rules do not add a general consent process beyond the Act’s principles, but they clarify special cases. Rules 10–11 define how to obtain “verifiable” consent for children’s or disabled individuals’ data (see next row). Also, Rule 3’s notice requirements (above) help ensure consent is informed. Rule 9 requires providing contact info (e.g. Data Protection Officer) wherever consent is requested

In practice, organizations should ensure consent forms or checkbox procedures clearly label each data point and purpose. For digital consent, it must be documented (e.g. timestamp, IP log) so it can be “verified” later if disputed. Non-children consent is largely unchanged, but companies should adopt record-keeping practices (e.g. audit logs of consents) in case proof is needed.

 Data Principal Rights (access, correction, erasure)

DP’s rights to access summary of her data and its processing (Sec. 11) and to correction/completion/updating/erasure of her data processed with consent (Sec. 12). (Requests “in such manner as prescribed.”)

The Act left unspecified how DP requests are made or processed, what identifiers or formats to use, and no response deadlines.

Rule 14 requires each Data Fiduciary (and Consent Manager) to prominently publish on its website/app the means to request rights and any identifiers needed (usernames, IDs). It also allows nomination of representatives (rule 14(4)) and mandates a grievance-response timeframe (≤ 90 days). Rule 9 requires DF to publish DPO or contact info in all DP responses.

Organizations must update privacy notices and websites with clear instructions (webforms, emails, etc.) for DP rights requests, collect only needed IDs, and implement workflows to meet the prescribed timelines. They must track and document DP requests and respond (through DPO) within the rule’s limits.

 Lawful Processing

Sec. 4 Processing of personal data is allowed only for a lawful purpose, which is defined as any purpose not forbidden by law. A fiduciary may process data only with the Data Principal’s consent or for certain “legitimate uses”

The Act’s language is broad: it does not detail what counts as a “legitimate use” or how to determine lawfulness. It also does not specify how to document consent or lawfulness.

The Rules elaborate some legitimate-use cases. For example, Rule 5 and its Second Schedule govern when State agencies can process data (e.g. for issuing subsidies or licenses. No rule explicitly changes Sec.4, but these clarifications show how specific uses (subsidies, benefits) fit under “legitimate uses.”

Organizations must ensure any data use falls under consent or a defined legitimate category. For government services, they must follow the standards in the Second Schedule when processing citizen data. Firms should document the lawful basis (consent or specific legitimate purpose) for each processing activity.

Data retention & deletion

DF must erase personal data on DP’s withdrawal of consent or “as soon as reasonable to assume” the purpose has ended (Sec. 8(7)) (unless law requires retention).

No specific retention periods or notice requirements were given. “Reasonable time” is vague; organizations did not know how long to keep data or when to delete it.

Rule 8 sets concrete timelines and procedures. Affected DF classes have fixed retention periods (e.g. 3 years of inactivity for large e‑commerce, gaming, social-media intermediaries, per Third Schedule). Before auto-deletion, DF must notify DP 48 hours in advance. All DFs must retain logs and associated data for ≥1 year for audit purposes.

Organizations must implement retention schedules and deletion workflows. They need to track when a DP last engaged (or exercised rights) and delete data after the prescribed inactivity period, sending advance notices. Systems must also keep processing logs for at least one year for compliance auditing.

Data breach notification

In case of a personal data breach, DF “shall give the Board and each affected DP intimation, in such form and manner as may be prescribed” (Sec. 8(6).

The Act did not specify when or how to notify, or what details to include. There was no timeline for Board notification or content guidance.

Rule 7 spells out detailed obligations. DF must notify each affected DP “without delay” via the DP’s account or registered contact, in concise, clear and plain language, including: the breach description (nature, extent, timing); likely consequences; mitigation measures; safety steps DP can take; and a business contact at the DF. Separately, DF must notify the Board “without delay” of breach summary (with nature, timing, location, impact) and provide a detailed report within 72 hours (extended only by Board’s written permission).

Organizations must establish incident-response protocols to meet these rules. Breach reports must be formatted as required, and sent immediately to affected individuals (DP) and the Board. Systems should track breach timelines (to ensure 72h Board notice). Businesses need ready templates and contacts to fulfil these notification requirements promptly.

Grievance redressal

DP has right to grievance redressal by DF or Consent Manager (Sec. 13(1)), and DF/CM must respond “within such period as may be prescribed”.

The Act did not define how to handle complaints or what the prescribed response period is.

Rule 14(3) fixes that period: every DF and CM must respond to DP grievances within 90 days (unless a shorter period is later prescribed). The grievance mechanism (forms, contact) must be published.

Companies must set up formal complaint-handling processes (e.g. a portal or email). All privacy complaints must be logged, investigated, and answered within 90 days. Compliance teams need to monitor this 90‑day window.

Security safeguards

DF must take “reasonable security safeguards” to protect data (Sec. 8(5)).

What exactly qualifies as “reasonable” was unclear. No baseline controls were listed.

Rule 6 details minimum safeguards: e.g. encryption/ obfuscation of stored data; access controls on systems and DF/processor resources; audit logs and monitoring to detect unauthorized access; data backups for continuity; and requiring processors by contract to also implement these safeguards. (It also requires retaining logs for 1 year.)

Organizations must implement these concrete controls. For example, they should encrypt databases, restrict administrative access, maintain logs with audit trails, deploy backups, and include security clauses in processor contracts. These become the new de facto compliance floor.

Cross-border transfers

The Central Government may “restrict the transfer of personal data… to such countries or territories outside India as may be notified” (Sec. 16(1)).

No criteria or procedure for lawful transfer were provided. It was unclear how and when DF can transfer data abroad.

Rule 15 clarifies that any transfer outside India is permitted only if the DF meets conditions that the Central Government may specify by general order or special order. In effect, transfers are allowed subject to any future government requirements (e.g. adequacy lists, contracts, or exemptions) announced by rule or notification.

Organizations must closely monitor future government orders or guidelines on overseas transfer. Until then, they should assume strict conditions (for example, only transferring to countries deemed safe or under specified contractual terms) and be prepared to implement any required transfer agreements or localization as mandated.

Government data processing standards

The Act’s “certain legitimate uses” include State/instrumentalities processing for services or official functions (Sec. 7(b), Sec. 17(2)). Such processing is permitted “subject to standards being in accordance with policy issued by the CG or any law”.

The Act did not enumerate those “standards”. It just referenced future rules/policies.

Schedule II (Rules) prescribes standards for State and its agencies when processing personal data: processing must be lawful and limited to necessary data; data must be kept accurate; retention only as needed; and reasonable security safeguards (similar to DF obligations) must be in place. When processing under Sec. 7(b), the agency must also give the Data Principal an intimation (notice) and provide contact info and rights-access details.

Government bodies and related projects must comply with these rules (e.g. minimizing data collected for welfare schemes, securing it, and notifying citizens). For example, an edtech platform running a government scholarship program must follow these procedures. In practice, State entities now have clearer compliance checklists akin to DF requirements.

Significant Data Fiduciary obligations

“Significant” Data Fiduciaries (those notified by CG) must appoint a DPO, conduct periodic DPIAs and audits (Sec. 10(2)).

The Act did not define “periodic” or set frequencies; nor did it address algorithmic risk or cross-border restrictions for SDFs.

Rule 13 mandates that each SDF must perform a Data Protection Impact Assessment and a data audit at least once every 12 months after notification as SDF. The SDF must submit the DPIA/audit report (with significant findings) to the Board. The rule also requires SDFs to conduct due diligence on any “technical measures or algorithmic software” they use so that these do not endanger DP rights. Additionally, an SDF must follow Government orders to not transfer specified personal and traffic data outside India (if a CG committee identifies certain categories).

Large organizations (e.g. major tech or online service providers) designated as SDFs must now schedule annual DPIAs and independent audits and document them. They need to review algorithms for bias/privacy risk, and stay alert for any CG list of data classes that must remain in India. These obligations raise the bar for compliance in the largest companies.

Children’s data processing

Special rules apply to child data (Sec. 9): DF must obtain “verifiable consent” of a parent before processing a child’s data; it must not process data “likely to cause any detrimental effect on child” or undertake behavioural tracking/targeted ads at children. (Exceptions may be prescribed.)

The Act left key points undefined: How to ensure parental consent is authentic (“verifiable”); what counts as “detrimental”; and what exceptions exist for e.g. schools, transport, etc.

Rule 10 defines “verifiable consent”: DFs must take technical/organizational measures to confirm the parent is an identifiable adult. This may involve checking identity/age via DF’s records or verifying a government-issued ID or token (e.g. DigiLocker). Rule 11 similarly addresses guardians of disabled persons. The Fourth Schedule (Rules) lists specific exceptions to Sec. 9(1) and (3): for example, schools and child-care providers may track children in their care or during transport for safety, and trivial account functions (like setting up an email-only account) are exempt.

EdTech and other child-focused platforms must implement robust parental-verification (e.g. require parent login or government ID check) before storing a minor’s data. They must disable targeted ads or profiling for users identified as children. The exceptions mean schools can use monitoring systems within the defined safety limits, but otherwise consents can’t be bypassed. These clarifications help edtech companies design child-safe data flows.

Nomination of Representatives

(Sec 14) Data Principals can nominate one or more individuals (e.g. heirs) to exercise their data rights after death or incapacity, in a manner “as may be prescribed”

The Act provided no detail on nomination procedures or proof required. It was unclear how a principal would notify a fiduciary about their nominees.

Rule 14 (see Rights above) states that to nominate, the principal can provide the nominee’s details using the same request channels and identifiers used for other rights. In other words, nomination is just another type of request under the fiduciary’s process.

Practically, organizations should allow an account holder to designate contacts (e.g. via a form or account settings). After the Principal’s death/incapacity, the nominee can use these credentials/IDs to act on data requests. Service agreements or platforms may add a “nominee” field in user profiles.