How does India DPDP Act work?

What the DPDP Act is doing, in practical terms

India’s DPDP Act is a personal data processing law, so the core question is not just what it says, but how it changes day-to-day handling of digital personal data. It pushes organisations to be deliberate about why they collect data, what they disclose to individuals, how they obtain and manage consent, and how they govern processors and retention.

The act is built around a simple operating model: collect only what you need, tell people what you are doing, give them meaningful rights, and keep enough control over the data lifecycle to honour those rights. That means policy alone is not enough. You need workflows for notices, consent capture, withdrawal, correction, deletion, and vendor management that actually work in production.

For a broader view of how India DPDP fits alongside other national privacy regimes, the Global Privacy Regulatory Map is a useful reference point because it places India DPDP in the context of cross-border privacy obligations and transfer rules.

Where compliance usually succeeds or fails

Most implementation problems come from treating DPDP as a legal notice exercise instead of an information governance program. If an organisation cannot trace where personal data sits, who can reach it, which vendors process it, and when deletion should occur, it will struggle to meet the act’s operational obligations even if the policy language looks correct.

The second common failure is overcollection. If teams keep collecting broad identity, behavioural, or contact data “just in case”, the organisation increases compliance burden and creates more work for correction, deletion, and purpose limitation. The practical test is whether each data element has a current, documented purpose and a defensible retention path.

Consent management is also easy to get wrong. If the business depends on consent for processing, it must be possible to prove what was consented to, when it was given, and how withdrawal is handled downstream. A notice that is unclear, buried, or detached from actual processing practices undermines the whole control set, even if the form is technically present.

Controls that make the act workable

DPDP becomes manageable when organisations translate legal duties into controls over collection, disclosure, retention, security, and third-party processing. That usually means data inventories, purpose tagging, notice templates, request handling workflows, deletion queues, and vendor controls that can be audited rather than assumed.

Security matters because privacy rights are only meaningful if the underlying data is protected and recoverable in a controlled way. A strong baseline is to restrict access, review who can change or export personal data, and make deletion and correction requests visible in ticketing or case-management systems so they are not lost in email or ad hoc approvals.

Where personal data handling sits in a broader security program, the control logic aligns well with standard security expectations such as the NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, auditability, and system integrity.

Deletion and retention deserve special attention because they are often weaker in practice than collection controls. If backup systems, analytics stores, and vendor copies are not included in the retention model, the organisation may technically “delete” data in one system while leaving it accessible elsewhere.

Risk and Threat Considerations

DPDP failures usually show up as exposure, not just paperwork gaps. The main risks are overcollection, unclear lawful basis or consent handling, weak vendor oversight, and incomplete deletion, all of which can leave personal data circulating longer and wider than the business intended.

Failure mechanism: When inventory, purpose limitation, consent records, or downstream deletion workflows are incomplete, personal data can remain available in production systems, analytics platforms, backups, or vendor environments after it should have been reduced or removed.

Impact: That creates avoidable privacy exposure, makes rights requests harder to satisfy, and increases the blast radius of any security incident because more data exists, in more places, for longer than necessary.

Practitioner Guidance

What to prioritise: Start with the data sets that combine high volume, high sensitivity, and multiple downstream recipients. Those are the places where notice quality, consent logic, deletion timing, and vendor oversight are most likely to fail together.

What to verify: Check whether you can produce evidence for each major obligation, including the notice shown, the consent state captured, the withdrawal path, the correction path, and the deletion workflow. If any of those rely on manual tribal knowledge, the control is not mature enough.

Practitioner takeaway: The DPDP Act is workable only when privacy obligations are operationalised as lifecycle controls over data, vendors, and requests, not treated as a one-time legal review.

Related resources from NHI Mgmt Group

• India DPDP Act
• How should organisations govern AI agents that act as business units of work?
• What breaks when DPDP Act compliance is managed with manual cloud audits?
• Why does the DPDP framework create extra governance pressure for organisations processing Indian personal data outside India?