India’s data-protection regime now has a clock. The final Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025, but they do not commence all at once. Rules 1, 2 and 17 to 21 commenced on publication. Rule 4, governing Consent Managers, commences one year later. Rules 3, 5 to 16, 22 and 23 commence eighteen months after publication, on 13 May 2027.
For technology companies, that staggered date is not a reason to wait. The delayed rules require changes to product interfaces, telemetry, vendor contracts, incident response and data architecture. Those systems cannot be produced by a privacy policy update in the final month. The transition period should be treated as an engineering programme under the Digital Personal Data Protection Act, 2023.
Notice must become a product surface
Rule 3 requires a notice that is independently understandable, uses clear language, itemises the personal data and links each category to specified purposes and enabled goods or services. It must also provide a route to withdraw consent, exercise statutory rights and complain to the Data Protection Board. The ease of withdrawal must be comparable to the ease of giving consent.
A generic privacy policy buried in a footer will not perform this function well. Product teams need a notice registry connecting each collection event, such as account creation, location access, behavioural analytics, support recording or personalisation, to a controlled purpose statement. Versioning is essential. The company should be able to show which notice a user saw, when consent was recorded and what changed later, without converting the consent log into an unrestricted copy of the user’s activity.
Rule 6 defines the minimum security control plane
The final Rules translate “reasonable security safeguards” into a minimum architecture. They identify encryption, obfuscation, masking or tokenisation; access controls; logs, monitoring and review; continuity measures such as backups; contractual safeguards with processors; and wider technical and organisational measures. They also require retention of relevant logs and personal data for at least one year for detection, investigation, remediation and continuity, unless another law requires otherwise.
This does not mean every database must be encrypted in the same way or that tokenisation alone proves compliance. Controls must respond to risk and data flow. A useful implementation map identifies the system of record, privileges, key management, backup restoration test, monitoring owner, alert severity and processor dependency for every material processing activity. The board and senior management should receive evidence that controls work, not only an assurance that a policy exists.
Breach notification is a two-speed workflow
Rule 7 requires notice to each affected Data Principal without delay. The communication must describe the breach, its likely consequences, mitigation, steps the individual can take and a business contact. The Board also receives an initial description without delay, followed within seventy-two hours by updated details, causal facts, mitigation, findings about the person responsible, measures against recurrence and a report on user notifications. The Board may allow longer time on a written request, but extension should be an exception supported by the investigation record.
Companies therefore need two parallel workstreams. The technical stream contains the incident, preserves evidence, determines scope and restores service. The legal-communications stream classifies affected individuals, drafts accurate notices, records regulatory decisions and avoids unsupported certainty. A seventy-two-hour report cannot depend on a committee being assembled after the breach. Decision rights, templates and escalation thresholds should be tested through simulations before commencement.
Erasure and retention must be reconciled
Rule 8 requires specified classes of fiduciaries to erase data when the listed purpose is no longer served, subject to legal retention. It also requires at least forty-eight hours’ warning before certain inactivity-based erasure. At the same time, processing data, associated traffic data and logs may need to be kept for a minimum one-year period for specified purposes. Privacy engineering must therefore distinguish live product data, security logs, legal holds, fraud records and backups rather than applying a single deletion switch.
A defensible retention schedule names the legal or operational purpose, start event, retention period, system owner and deletion method. Backups require special treatment: deletion from the live database should not silently leave indefinitely restorable personal data in snapshots.
Children and Consent Managers require identity-aware design
Rule 10 requires verifiable parental consent before processing a child’s personal data and due diligence to establish that the person presenting as parent is an identifiable adult. The Rules contemplate reliable identity-and-age details or a virtual token issued through an authorised entity, including a Digital Locker service provider. This creates a design tension: verify adulthood without collecting more identity data than the service needs. Token-based or reusable verification should be preferred where it reduces exposure.
Rule 4’s Consent Manager framework begins on 13 November 2026. Even companies that do not become Consent Managers must anticipate interoperable consent signals, auditable instructions and withdrawal across systems. API contracts should define identity matching, authorisation, replay protection, timestamps and failure handling.
A compliance build plan for the remaining runway
The immediate task is a gap assessment against the final Rules, not the earlier draft. By the end of 2026, companies should have an approved data inventory, notice catalogue, processor-contract standard, security-control matrix and Consent Manager impact assessment. Early 2027 should be reserved for system changes, migration of legacy consents where legally required, breach simulations, rights-request testing and evidence collection.
The strongest compliance programme will not treat privacy as a legal overlay on a finished product. The DPDP regime makes interface design, access architecture, logging, vendor engineering and incident communications part of the legal duty. May 2027 is the enforcement milestone; the build deadline is much earlier.
Primary references
Digital Personal Data Protection Rules, 2025 (final Gazette)