DPDP Act Key Provisions Explained

DPDP Act Key Provisions Explained: A Detailed Analysis

A breakdown of the most important provisions in the Digital Personal Data Protection Act and what they mean for your organisation

I. Introduction

The Digital Personal Data Protection Act, 2023 (DPDP Act) represents a watershed moment in India's regulatory landscape. For the first time, organisations processing digital personal data face a comprehensive legal framework that balances individual privacy rights with legitimate business needs. Whether you operate an e-commerce platform, manage a healthcare facility, run an educational institution, or provide professional services, this Act fundamentally changes how you handle personal data.

The DPDP Act came into force in stages, with foundational provisions taking effect immediately and substantive compliance obligations phasing in over 12 to 18 months from the notification of the Digital Personal Data Protection Rules, 2025. This staged implementation provides organisations with a crucial window to understand their obligations and implement necessary changes.

This article provides a detailed analysis of the Act's key provisions, translating legal requirements into practical guidance. As your organisation navigates these new requirements, understanding not just what the law says but what it means for your operations becomes essential. At the Centre for Applied Data Protection (CADP), we specialise in bridging this gap between legal frameworks and operational implementation.

This analysis forms part of a comprehensive series on DPDP Act compliance. While this article explains what the law requires, our companion Implementation Guide (linked throughout) provides the practical frameworks for meeting those requirements.

II. Understanding Core Concepts First

Before examining specific provisions, clarity on fundamental concepts ensures accurate interpretation of your obligations.

A. Key Definitions

Personal Data

Personal data means any data about an individual who is identifiable by or in relation to such data. This extends beyond obvious identifiers like names and addresses. Consider these examples:

A mobile phone number linked to purchase history
An email address associated with service preferences
Location data showing a pattern of visits to medical facilities
Biometric data used for authentication
Financial information connected to spending patterns

The defining characteristic is identifiability—whether the data allows you to identify a specific person, either alone or in combination with other information.

Processing

Processing encompasses any operation performed on digital personal data, including:

Collection (when you first receive the data)
Recording (storing it in your systems)
Organisation and structuring (arranging it for use)
Storage (maintaining it over time)
Adaptation or alteration (updating or modifying it)
Retrieval (accessing it when needed)
Use (applying it for specific purposes)
Disclosure by transmission (sharing it with others)
Erasure or destruction (deleting it)

Importantly, processing can be wholly or partly automated. If digital systems touch personal data at any stage, processing occurs.

Data Fiduciary

A Data Fiduciary is any person who, alone or with others, determines the purpose and means of processing personal data. In practical terms, you are a Data Fiduciary when you decide:

Why you need personal data (the purpose)
How you will obtain and use it (the means)

Think of a Data Fiduciary as occupying a position analogous to a trustee—holding and managing personal data with attendant responsibilities toward individuals.

Data Principal

The Data Principal is the individual to whom the personal data relates. This is the person whose data you process. For most organisations, Data Principals are your customers, employees, vendors, or service users.

For children (persons under 18 years) and persons with disability who have lawful guardians, the term Data Principal includes their parents or lawful guardians respectively.

Data Processor

A Data Processor processes personal data on behalf of a Data Fiduciary. If you engage a cloud service provider to store customer data, or a payroll service bureau to process employee information, they function as Data Processors. Critically, Data Processors act under your instructions and contract—you remain responsible for their processing activities.

B. The Act's Philosophy

The DPDP Act embodies a fundamental recognition: individuals have a right to protect their personal data, yet organisations have legitimate needs to process such data. This dual recognition shapes every provision.

Earlier privacy frameworks often operated on a "notice and consent" model—organisations could process personal data for virtually any purpose if they obtained consent. The DPDP Act adopts a more nuanced approach:

Consent remains important but must meet stringent requirements of being free, specific, informed, unconditional and unambiguous. Consent cannot be a formality or buried in complex terms of service.

Legitimate uses provide an alternative basis where processing serves recognised purposes—governmental functions, legal compliance, employment relationships, emergencies—without requiring individual consent for each instance.

This philosophy allows organisations to function efficiently while maintaining meaningful individual control. It recognises that consent makes sense for discretionary processing (marketing communications, optional features) but proves impractical for necessary processing (legal compliance, employee management, emergency response).

Understanding this philosophical foundation helps in interpreting specific provisions. The Act seeks balance, not burden. Compliance should enable trust and operational clarity, not merely tick regulatory boxes.

III. The Foundation: When Can You Process Personal Data?

Section 4 of the Act establishes the fundamental principle: you may process personal data only in accordance with the Act's provisions and for lawful purposes, based on either:

The Data Principal's consent, or
Certain legitimate uses

This binary framework—consent or legitimate use—determines the legal basis for all processing activities. Identifying your correct basis for each processing activity constitutes the foundation of compliance.

A. Processing Based on Consent

What Makes Consent Valid (Section 6)

The Act prescribes exacting standards for valid consent. Consent must be:

Free: Given without coercion, pressure, or adverse consequences for refusal. Consent is not free if refusing it means denial of services to which the individual is otherwise entitled.

Specific: Related to clearly defined processing activities and purposes. Blanket consent for undefined future uses fails this requirement.

Informed: The individual understands what data will be processed and for what purposes, based on clear notice (discussed below).

Unconditional: Not bundled with other agreements or made a condition for unrelated services. If processing is unnecessary for the service being provided, consent for such processing cannot be made a precondition.

Unambiguous: Demonstrated through a clear affirmative action. Silence, pre-ticked boxes, or inactivity do not constitute consent.

The Act illustrates this with a telling example: if a telemedicine application requests consent both for processing health data to provide medical services AND for accessing your mobile phone contact list, your consent is limited to the former. Accessing the contact list is not necessary for telemedicine services, so any purported consent for it proves invalid.

The Notice Requirement (Section 5)

Before requesting consent, you must provide the Data Principal with clear notice containing:

An itemised description of personal data you seek to process. Generic categories ("contact information") prove insufficient; specify what you need ("name, email address, mobile number").

The specified purpose or purposes for processing, with specific description of the goods or services provided or uses enabled. "Business purposes" or "improving our services" lack the required specificity.

How the Data Principal may exercise rights under the Act, including withdrawing consent.

How to make a complaint to the Data Protection Board.

This notice must be:

Presented independently of other information, not buried in lengthy terms of service
In clear and plain language
Available in English or any language in the Eighth Schedule to the Constitution (the Data Principal's choice)
Accompanied by contact details of your Data Protection Officer (if applicable) or other authorised person

Practical Example: When an individual opens a bank account via mobile app, the bank must provide clear notice describing the personal data required (identity documents, contact information, financial details), the specific purpose (fulfilling regulatory Know-Your-Customer requirements, account management, transaction processing), and how the individual can exercise rights or raise concerns.

Withdrawal of Consent (Section 6(4)-(6))

Data Principals retain the right to withdraw consent at any time, and withdrawal must be as easy as giving consent. If consent was obtained through a single tap in an app, withdrawal should require similar ease.

However, withdrawal carries consequences that the Data Principal must bear. If you granted consent for an e-commerce platform to process your data for order fulfilment and then withdraw that consent, the platform may cease enabling you to place orders, but must continue processing already-placed orders for which payment was made.

Upon withdrawal, you must:

Cease processing the personal data (except where another legal basis applies)
Cause your Data Processors to cease processing
Take these actions within a reasonable timeframe

The Act permits continued processing if required or authorised under other provisions or any law for the time being in force.

Consent Managers (Section 6(7)-(10))

The Act introduces an innovative concept—Consent Managers—who serve as intermediaries enabling Data Principals to give, manage, review and withdraw consent through an accessible, transparent, and interoperable platform.

Think of a Consent Manager as a single point of control for an individual's consent across multiple Data Fiduciaries. Rather than managing consent separately with each organisation, individuals can use a Consent Manager's platform to:

View all consent requests in one place
Grant or deny consent
Review a record of consents given
Withdraw consent across organisations

Consent Managers must be registered with the Data Protection Board and are accountable to Data Principals, not Data Fiduciaries. They act in a fiduciary capacity, avoiding conflicts of interest. The Digital Personal Data Protection Rules, 2025 specify registration requirements and obligations.

For organisations, Consent Managers offer a standardised interface for consent management, potentially simplifying compliance while enhancing user experience. As Consent Managers become established, organisations should evaluate whether integration with these platforms benefits their Data Principals and operations.

Burden of Proof (Section 6(10))

Where consent forms the basis for processing and a question arises, the Data Fiduciary bears the burden of proving:

Notice was given in accordance with the Act
Consent was obtained in accordance with the Act

Maintain clear records of consent mechanisms, notices provided, and affirmative actions taken by Data Principals. This documentation proves essential if your processing is questioned.

B. Processing Based on Certain Legitimate Uses (Section 7)

Section 7 enumerates nine categories of processing that do not require individual consent because they serve recognised legitimate purposes. These provisions enable necessary operational, governmental, and emergency functions without the impracticality of obtaining consent for each instance.

1. Voluntary Provision with Limited Use (Section 7(a))

Processing is permissible when the Data Principal voluntarily provides personal data for a specified purpose and does not indicate unwillingness for such use.

The Act provides instructive examples:

An individual makes a purchase at a pharmacy and voluntarily provides personal data, requesting a payment receipt via SMS. The pharmacy may process this data to send the receipt.
An individual contacts a real estate broker requesting assistance in finding rental accommodation, sharing personal data for this purpose. The broker may process this data to identify and communicate suitable options. When the individual subsequently informs the broker that assistance is no longer needed, processing must cease.

This legitimate use applies where:

The Data Principal initiates the interaction
The purpose is clear from context
No indication of objection exists
Processing remains limited to the specified purpose

Once the Data Principal indicates unwillingness for such processing, it must cease. This legitimate use depends on ongoing voluntary participation; withdrawal of that participation removes the basis for processing.

2. Government Benefits and Services (Section 7(b))

The State and its instrumentalities may process personal data to provide or issue subsidies, benefits, services, certificates, licences or permits prescribed by the Central Government, where:

The Data Principal previously consented to processing by the State or its instrumentalities for any subsidy, benefit, service, certificate, licence or permit, OR

Such personal data is available in digital form or digitised from non-digital form, from databases, registers, books or documents maintained by the State or instrumentalities and notified by the Central Government.

This provision recognises that once an individual enrolls in one government programme with consent, government may use that data for other prescribed programmes without seeking fresh consent for each programme, provided processing follows standards specified in the Second Schedule to the Rules.

Practical Example: An individual enrolls in a maternity benefits programme, consenting to provide personal data for receiving such benefits. Government may process this data to determine eligibility for other prescribed benefits (child nutrition programmes, healthcare services) without obtaining separate consent for each programme.

The Second Schedule mandates standards including lawful processing, necessity and proportionality, accuracy, appropriate security safeguards, and accountability. These ensure that while consent is not required for each instance, processing remains subject to robust safeguards.

3. Performance of State Functions (Section 7(c))

Processing necessary for the State or its instrumentalities to perform any function under law or in the interest of sovereignty and integrity of India or security of the State requires no consent.

This recognises that governmental functions—law enforcement, national security, regulatory oversight, judicial proceedings—cannot operate subject to individual consent. However, such processing must be genuinely necessary for the stated function and conducted in accordance with applicable law.

4. Legal Compliance (Section 7(d))

Processing to fulfil any obligation under law to disclose information to the State or its instrumentalities requires no consent, provided such processing accords with provisions regarding disclosure in such law.

If banking regulations require disclosure of suspicious transactions to financial intelligence authorities, or tax laws mandate reporting of certain financial information, such processing proceeds without consent. The Act defers to sectoral laws regarding the scope and manner of such disclosures.

5. Judicial and Civil Claims (Section 7(e))

Processing for compliance with court judgments, decrees or orders under Indian law, or judgments or orders relating to contractual or civil claims under foreign law, requires no consent.

This enables organisations to respond to legal proceedings, enforce contracts, and comply with judicial directives without seeking consent from potentially adverse parties.

6. Medical Emergencies (Section 7(f))

Processing in response to medical emergencies involving threat to life or immediate threat to health of the Data Principal or another individual requires no consent.

A hospital providing emergency treatment may process patient data necessary for such treatment without first obtaining consent. The emergency nature of the situation makes consent impractical while processing proves necessary for protecting vital interests.

7. Public Health Measures (Section 7(g))

Processing to provide medical treatment or health services to any individual during epidemics, disease outbreaks, or other public health threats requires no consent.

The COVID-19 pandemic illustrated the necessity of processing health data for vaccination programmes, contact tracing, and healthcare delivery during public health crises. This provision provides clear legal basis for such processing.

8. Disaster Response (Section 7(h))

Processing to ensure safety of, or provide assistance or services to, any individual during any disaster or public order breakdown requires no consent.

The term "disaster" carries the same meaning as in the Disaster Management Act, 2005, encompassing natural or man-made catastrophes causing loss of life, property, or environmental degradation of such magnitude as to overwhelm local capacity to respond.

9. Employment Purposes (Section 7(i))

Processing for employment purposes or those related to safeguarding the employer from loss or liability requires no consent. This includes:

Prevention of corporate espionage
Maintenance of confidentiality of trade secrets, intellectual property, or classified information
Provision of any service or benefit sought by an employee

This recognises the impracticality and artificiality of consent in employment relationships where power dynamics exist, and where processing proves necessary for the employment relationship itself or legitimate employer interests in protection of business assets.

C. Implications for Your Organisation

The consent versus legitimate use framework requires careful mapping of your processing activities.

For each type of personal data you process, document:

What data you collect
From whom (customers, employees, vendors, etc.)
For what purposes
Under which legal basis (specific consent or which legitimate use)

This data inventory and basis mapping constitutes foundational compliance work. It reveals where you need robust consent mechanisms, where legitimate uses apply, and where your current practices may lack adequate legal basis.

Common mistakes to avoid:

Assuming consent alone suffices for all processing
Claiming legitimate use when consent is actually required
Obtaining consent for purposes where legitimate use would apply (creating unnecessary withdrawal rights)
Treating "legitimate interests" as carte blanche—each legitimate use has specific criteria
Failing to document the legal basis for processing activities

For organisations requiring guidance on mapping processing activities to appropriate legal bases, CADP offers compliance advisory services addressing these foundational questions. Proper basis identification prevents both over-reliance on consent (creating operational fragility) and under-protection of individual rights.

IV. Rights of Data Principals

The Act grants Data Principals specific rights concerning their personal data. Your organisation must enable the exercise of these rights through appropriate mechanisms.

A. Right to Access Information (Section 11)

Data Principals have the right to obtain from any Data Fiduciary to whom they previously gave consent (including consent under Section 7(a)):

A summary of personal data being processed and the processing activities undertaken with respect to such data.

The identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared, along with description of data shared.

Any other information related to personal data and its processing, as may be prescribed.

This right does not extend to personal data shared with Data Fiduciaries authorised by law to obtain such data, where sharing occurs pursuant to written request for prevention, detection, or investigation of offences or cyber incidents, or for prosecution or punishment of offences. This exception recognises that disclosing law enforcement data access could prejudice investigations.

Data Principals exercise this right by making requests in the prescribed manner to the Data Fiduciary. The Rules specify that Data Fiduciaries must prominently publish on their website or app the means for making such requests and any particulars (username, customer ID, etc.) required to identify the requesting individual.

B. Right to Correction and Erasure (Section 12)

Data Principals have the right to correction, completion, updating and erasure of their personal data, subject to any requirements or procedures under law.

Upon receiving a request for correction, completion or updating, the Data Fiduciary must:

Correct inaccurate or misleading personal data
Complete incomplete personal data
Update personal data

Upon receiving a request for erasure, the Data Fiduciary must erase personal data unless retention is necessary for the specified purpose or for compliance with law.

This right recognises that personal data may become inaccurate over time, that individuals may wish to correct errors, and that data no longer needed should be deleted upon request.

Requests for erasure do not override legal retention requirements. If law mandates maintaining certain records for specified periods, erasure requests do not compel violation of such requirements. The Data Fiduciary must balance individual rights against legal obligations.

C. Right to Grievance Redressal (Section 13)

Data Principals have the right to readily available means of grievance redressal provided by Data Fiduciaries and Consent Managers regarding:

Any act or omission concerning performance of obligations related to the Data Principal's personal data
Exercise of rights under the Act

The Data Fiduciary or Consent Manager must respond to grievances within the prescribed period. The Rules specify a 90-day period for establishing effective grievance redressal mechanisms and require Data Fiduciaries and Consent Managers to prominently publish information about their grievance systems.

Critically, Data Principals must exhaust this grievance redressal opportunity before approaching the Data Protection Board. This requirement channels disputes toward resolution at the organisational level before escalation to regulatory proceedings.

D. Right to Nominate (Section 14)

Data Principals may nominate any other individual who, in the event of the Data Principal's death or incapacity, shall exercise the Data Principal's rights under the Act.

"Incapacity" means inability to exercise rights due to unsoundness of mind or infirmity of body.

This right addresses the question of what happens to digital personal data upon death or incapacity. The nominated individual steps into the Data Principal's position, able to access information, request corrections or erasure, and exercise other rights.

The Rules specify that nomination shall be made in accordance with the Data Fiduciary's terms of service and any applicable law, using prescribed means and furnishing required particulars.

E. Enabling Rights Exercise

The Rules require Data Fiduciaries to prominently publish on websites or apps:

Details of means for making rights requests
Particulars required to identify requesting Data Principals (usernames, customer IDs, etc.)
Information about grievance redressal mechanisms, including response timelines

This publication requirement ensures Data Principals can readily discover how to exercise rights. Organisations should ensure that rights exercise mechanisms are accessible, clearly explained, and actually functional—not merely documented.

Consider the user experience: Can a Data Principal easily find how to access their data, request corrections, or file grievances? Is the process straightforward or does it create friction designed to discourage rights exercise? The Act expects genuine enablement, not grudging compliance.

V. Obligations of Data Fiduciaries

As a Data Fiduciary, you bear primary responsibility for complying with the Act's requirements. These obligations apply regardless of whether you process data with consent or under legitimate uses. They represent the baseline standards for responsible data processing.

A. Fundamental Obligations (Section 8)

1. Responsibility for Processing (Section 8(1))

You remain responsible for all processing you undertake or that is undertaken on your behalf by a Data Processor, regardless of:

Any agreement to the contrary
Failure of a Data Principal to carry out duties under the Act

This responsibility cannot be contracted away. Even if you engage a Data Processor and that Processor breaches the Act, you remain accountable. This incentivises careful Processor selection, appropriate contractual provisions, and ongoing oversight.

2. Data Processor Engagement (Section 8(2))

You may engage Data Processors only under valid contracts. The contract should address security safeguards, processing limitations, data return or deletion upon contract termination, and other protections. Rule 6(1)(f) requires that contracts with Data Processors include appropriate provisions for taking reasonable security safeguards.

When selecting Data Processors, evaluate their:

Technical and organisational capabilities
Security measures and certifications
Track record and reputation
Financial stability
Alignment with your compliance requirements

The Data Processor acts as your agent; their failures become your liabilities.

3. Data Quality (Section 8(3))

Where personal data processed is likely to be:

Used to make a decision affecting the Data Principal, OR
Disclosed to another Data Fiduciary

You must ensure the data's completeness, accuracy and consistency.

This obligation recognises that decisions based on inaccurate data can cause significant harm (denial of services, incorrect assessments, financial loss). Similarly, sharing inaccurate data propagates errors across Data Fiduciaries.

Implement processes for:

Data validation at point of collection
Regular data quality checks
Mechanisms for Data Principals to report and correct errors
Verification before using data for significant decisions

4. Technical and Organisational Measures (Section 8(4))

You must implement appropriate technical and organisational measures to ensure effective observance of the Act's provisions.

"Technical measures" include systems, software, encryption, access controls, and other technology-based safeguards. "Organisational measures" include policies, procedures, training, governance structures, and management oversight.

The measures must be "appropriate"—proportionate to the:

Volume and sensitivity of data processed
Risks to Data Principals
Nature of your operations
State of technology and implementation costs

Small-scale processing of non-sensitive data requires different measures than large-scale processing of health or financial data.

5. Reasonable Security Safeguards (Section 8(5))

You must protect personal data through reasonable security safeguards to prevent personal data breach.

Rule 6 elaborates that reasonable security safeguards include, at minimum:

Data security measures such as:

Encryption of personal data (rendering it unreadable without authorised decryption)
Obfuscation (making data obscure or unclear to unauthorised parties)
Masking (hiding data while preserving format)
Virtual tokens (substituting sensitive data with non-sensitive equivalents)

Access controls to computer resources used for processing, ensuring only authorised personnel access personal data.

Logging, monitoring and review providing visibility into data access, enabling detection of unauthorised access, investigation of incidents, and remediation to prevent recurrence.

Business continuity measures enabling continued processing if confidentiality, integrity or availability of personal data is compromised, such as through data backups and disaster recovery plans.

Retention of logs and personal data for one year to enable detection, investigation and remediation of unauthorised access, unless law requires otherwise.

Contractual provisions with Data Processors requiring them to implement reasonable security safeguards.

Appropriate technical and organisational measures ensuring effective observance of security safeguards.

The specific security measures your organisation implements will depend on the nature of data processed and associated risks. Healthcare organisations handling medical records require more stringent measures than organisations processing basic contact information for newsletter distribution.

For guidance on implementing appropriate security safeguards tailored to your organisation's risk profile, consider consulting with specialists in data protection compliance.

6. Personal Data Breach Response (Section 8(6) and Rule 7)

In the event of a personal data breach, you must:

Intimate each affected Data Principal, to the best of your knowledge, without delay, through their user account or any registered communication mode, providing:

Description of the breach, including nature, extent, and timing
Consequences relevant to the Data Principal likely to arise
Measures you have implemented and are implementing to mitigate risk
Safety measures the Data Principal may take to protect their interests
Business contact information of a person able to respond to queries

Intimate the Data Protection Board:

Without delay: Description of the breach, including nature, extent, timing, location, and likely impact
Within 72 hours of becoming aware (or longer period if Board allows on written request): Updated detailed information including:
- Facts related to events, circumstances and reasons for the breach
- Measures implemented or proposed to mitigate risk
- Any findings regarding the person who caused the breach
- Remedial measures to prevent recurrence
- Report on intimations given to affected Data Principals

The 72-hour timeline runs from when you become aware of the breach, not when the breach occurred. However, "becoming aware" is objective—when you should reasonably have known through appropriate monitoring and detection systems, not merely when someone explicitly informs you.

Personal data breach means unauthorised processing, or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, compromising confidentiality, integrity or availability. This encompasses:

Hacking or cyber attacks
Unauthorised employee access
Accidental public disclosure (misconfigured systems, misdirected emails)
Loss or theft of devices containing personal data
Ransomware attacks encrypting data
Data corruption or loss

Establish incident response plans that enable:

Prompt breach detection through monitoring
Rapid assessment of breach nature, scope and impact
Immediate containment and mitigation measures
Timely notification to affected Data Principals and the Board
Investigation and remediation to prevent recurrence
Documentation of the incident and response

7. Data Retention and Erasure (Section 8(7) and Rule 8)

You must erase personal data:

Upon the Data Principal withdrawing consent, OR
As soon as it is reasonable to assume the specified purpose is no longer being served

Whichever occurs earlier, unless retention is necessary for compliance with law.

You must also cause your Data Processors to erase personal data you made available to them.

Rule 8 specifies time periods for certain classes of Data Fiduciaries and purposes. For example, large e-commerce entities, online gaming intermediaries, and social media intermediaries with specified user thresholds must erase data three years after the Data Principal last approached the Data Fiduciary or exercised rights, if she neither approaches for the specified purpose nor exercises rights during that period.

These specified periods establish clear erasure obligations where Data Principals cease active engagement. Before the period completes, you must inform Data Principals (at least 48 hours prior) that data will be erased unless they login or initiate contact.

However, Rule 8(3) requires retention of personal data, associated traffic data, and processing logs for a minimum of one year from the date of processing, for purposes including:

Preventing, detecting, investigating or prosecuting offences or cyber incidents
Enforcing legal rights or claims
Complying with judicial or regulatory orders
Enabling grievance redressal
Ensuring personal data security

This one-year minimum retention applies even if the Data Principal withdraws consent or the specified purpose is served, after which erasure must occur unless further retention is required by law.

The specified purpose is deemed no longer served if the Data Principal does not approach the Data Fiduciary for the specified purpose's performance and does not exercise rights for the prescribed time period. "Approaching" means initiating contact in person or by electronic or physical communication.

These retention and erasure requirements balance competing interests: enabling individuals to control data no longer needed, allowing organisations to maintain data necessary for operations and legal compliance, and ensuring accountability through processing logs.

8. Point of Contact (Section 8(9) and Rule 9)

You must prominently publish business contact information of your Data Protection Officer (if applicable) or a person able to answer questions about processing of personal data on behalf of the Data Fiduciary.

This requirement ensures Data Principals have a clear point of contact for questions, concerns, and rights exercise. The contact information should be readily discoverable on your website or app, not buried in lengthy documents.

The person designated should have sufficient knowledge of your processing activities and authority to respond meaningfully to enquiries.

9. Grievance Redressal Mechanism (Section 8(10) and Rule 14)

You must establish an effective mechanism to redress grievances of Data Principals.

Rule 14(3) requires this mechanism to respond to grievances within 90 days of receipt for all or any class of Data Fiduciaries, with appropriate technical and organisational measures implemented to ensure effectiveness.

An effective mechanism includes:

Clear procedures for filing grievances
Acknowledgement of receipt
Investigation and assessment of grievances
Communication of outcomes and remedial actions
Escalation paths for unresolved grievances
Documentation of grievances and resolutions

The grievance mechanism serves as the first line of resolution before matters escalate to the Data Protection Board.

B. Special Obligations for Processing Children's Data (Section 9)

Processing personal data of children (individuals under 18 years) requires enhanced protections.

1. Verifiable Parental Consent (Section 9(1) and Rule 10)

Before processing any personal data of a child, you must obtain verifiable consent of the parent or lawful guardian.

Rule 10 specifies that verifiable consent requires adopting appropriate technical and organisational measures to ensure the individual identifying herself as the parent is an adult (18 years or above) who is identifiable if required by law, by reference to:

Reliable details of identity and age available with the Data Fiduciary, OR
Identity and age details voluntarily provided by the individual or through virtual tokens issued by authorised entities (entities entrusted by law or Government with issuance of identity and age details, including Digital Locker service providers)

The Act illustrates this with examples. If a child seeks to create a user account on an online platform, the platform must enable the parent to identify herself. If the parent is an existing registered user whose identity and age details the platform already holds reliably, the platform must verify the parent is an identifiable adult. If the parent is not an existing user, the platform must verify adult status through government-issued identity and age details or virtual tokens, which the parent may provide through Digital Locker services.

This requirement balances child protection with practical verification. Platforms need not conduct independent background checks but must take reasonable steps to verify the person consenting is indeed an adult parent or guardian.

2. Prohibition on Detrimental Processing (Section 9(2))

You must not undertake processing of personal data likely to cause detrimental effect on the well-being of a child.

"Detrimental effect" is not defined, allowing flexibility in interpretation based on circumstances. Consider effects on:

Physical health and safety
Mental and emotional well-being
Educational development
Social development
Financial interests

Processing that exposes children to harmful content, enables exploitation, causes psychological harm, or otherwise adversely affects their well-being violates this provision.

3. Prohibition on Tracking, Behavioural Monitoring, and Targeted Advertising (Section 9(3))

You must not:

Track children's online activity
Conduct behavioural monitoring of children
Direct targeted advertising at children

This prohibition recognises children's vulnerability to commercial exploitation and manipulation. The restriction extends to:

Tracking across websites or apps
Profiling based on behaviour
Using personal data to target advertisements to children

Note that this does not prohibit all advertising on services used by children, but specifically targeted advertising directed at children based on their personal data or behaviour.

4. Exemptions from Children's Data Requirements (Rules 12, Section 9(4) and (5))

The prohibitions on verifiable parental consent and tracking/targeting do not apply in certain circumstances.

Exempt classes of Data Fiduciaries (Rule 12, Part A):

Clinical establishments, mental health establishments, and healthcare professionals—processing restricted to providing health services to the child, to the extent necessary for health protection
Allied healthcare professionals—processing restricted to supporting implementation of treatment and referral plans, to the extent necessary for health protection
Educational institutions—processing restricted to tracking and behavioural monitoring for educational activities or child safety
Individuals providing care at crèches or child day care centres—processing restricted to tracking and behavioural monitoring for child safety
Entities providing transport for educational institutions, crèches or child care centres—processing restricted to location tracking during travel, for child safety

Exempt purposes (Rule 12, Part B):

Exercise of power, performance of function, or discharge of duties under law in the child's interests—processing restricted to extent necessary
Providing government subsidies, benefits, services, certificates, licences or permits to the child under Section 7(b)—processing restricted to extent necessary
Creating an email communication account—processing restricted to account creation, with use limited to email communication
Determining real-time location of a child—processing restricted to location tracking for safety, protection or security
Ensuring information, services or advertisements likely to cause detrimental effect are not accessible to the child—processing restricted to preventing such access
Confirming the Data Principal is not a child and observing due diligence for verification—processing restricted to such confirmation or observance

These exemptions recognise that in specific contexts, processing children's data without parental consent serves the child's interests (health services, education, safety) or proves necessary for age verification itself.

Central Government may notify ages above which specific Data Fiduciaries are exempt from verifiable parental consent and tracking/targeting prohibitions, if satisfied the Data Fiduciary ensures processing is verifiably safe. This allows tailored age thresholds for platforms that demonstrate robust child protection measures.

C. If You Are a "Significant Data Fiduciary" (Section 10 and Rule 13)

The Central Government may notify any Data Fiduciary or class of Data Fiduciaries as Significant Data Fiduciary based on assessment of relevant factors including:

Volume and sensitivity of personal data processed
Risk to rights of Data Principals
Potential impact on sovereignty and integrity of India
Risk to electoral democracy
Security of the State
Public order

Designation as Significant Data Fiduciary triggers additional obligations.

1. Appoint a Data Protection Officer (Section 10(2)(a))

You must appoint a Data Protection Officer who:

Represents the Significant Data Fiduciary under the Act
Is based in India
Is responsible to the Board of Directors or similar governing body
Serves as the point of contact for grievance redressal under the Act

The Data Protection Officer serves as the primary interface with Data Principals, the Data Protection Board, and internal governance bodies on data protection matters. This individual should have appropriate seniority, authority, and resources to fulfil responsibilities effectively.

2. Appoint an Independent Data Auditor (Section 10(2)(b))

You must appoint an independent data auditor to evaluate your compliance with the Act.

Independence means freedom from conflicts of interest that might compromise objectivity. The auditor should not be subject to financial or other interests that could bias audit findings.

3. Undertake Additional Measures (Section 10(2)(c))

You must undertake:

Periodic Data Protection Impact Assessment—a process comprising:

Description of rights of Data Principals and the purpose of processing their personal data
Assessment and management of risk to Data Principals' rights
Such other matters as may be prescribed

Data Protection Impact Assessment provides a systematic framework for identifying and mitigating risks before they materialise into harms. This proactive approach to risk management constitutes best practice in data protection.

Periodic audit—evaluation by the independent data auditor of compliance with the Act.

Rule 13(1) requires Data Protection Impact Assessment and audit at least once every 12 months from notification as Significant Data Fiduciary.

Such other measures as prescribed, consistent with the Act.

Rule 13(3) requires due diligence to verify that technical measures including algorithmic software adopted for hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing of personal data are not likely to pose risk to Data Principals' rights.

This addresses concerns about algorithmic decision-making and automated processing. Where algorithms process personal data, you must assess whether such processing creates risks (discrimination, unfair treatment, manipulation) and implement safeguards.

4. Furnish Report to the Board (Rule 13(2))

You must cause the person carrying out Data Protection Impact Assessment and audit to furnish to the Board a report containing significant observations.

This reporting creates regulatory visibility into how Significant Data Fiduciaries manage data protection risks and comply with obligations.

5. Data Localisation for Specified Personal Data (Rule 13(4))

You must ensure that personal data specified by the Central Government, based on recommendations of a committee it constitutes, is processed subject to restriction that the personal data and traffic data pertaining to its flow is not transferred outside India.

This potential data localisation requirement applies only to personal data specifically notified by the Central Government, not to all processing by Significant Data Fiduciaries. The Government will determine, based on the committee's recommendations, which categories of personal data require localisation.

The committee includes officials from the Ministry of Electronics and Information Technology and may include officials from other Ministries or Departments.

Until the Central Government specifies personal data categories, this obligation remains inchoate. Organisations designated as Significant Data Fiduciaries should monitor for such notifications and prepare contingency plans for potential localisation requirements.

VI. Cross-Border Data Transfers

Section 16 addresses transfer of personal data outside India's territory.

A. Restriction Framework

The Central Government may, by notification, restrict transfer of personal data by a Data Fiduciary for processing to any specified country or territory outside India.

This is a blacklist approach—transfers are permitted unless the Central Government specifically restricts them. The restriction operates on a country-by-country basis, not as a blanket prohibition on all cross-border transfers.

The Central Government may impose such restrictions based on concerns about:

Adequacy of data protection laws in the destination country
Risks of unauthorised access by foreign governments
Geopolitical considerations
Security and sovereignty concerns

As of the Rules' commencement, no countries or territories have been notified as restricted destinations. Until such notification occurs, cross-border transfers are permissible subject to Rule 15's requirements.

B. Requirements for Transfers (Rule 15)

Any personal data processed under the Act may be transferred outside India subject to the Data Fiduciary meeting such requirements as the Central Government may specify for making such personal data available to:

Any foreign State
Any person or entity under the control of, or any agency of, such a foreign State

This provision addresses government access to data transferred abroad. The Central Government may impose requirements ensuring that foreign government access to data transferred from India occurs only under appropriate legal frameworks and safeguards.

Specific requirements remain to be notified. Organisations engaging in cross-border transfers should:

Monitor for notifications specifying requirements
Document transfers, including destination, purpose, and safeguards
Assess legal and practical protections in destination jurisdictions
Implement contractual safeguards with recipients
Maintain ability to comply with requirements once notified

C. Relationship with Other Laws

Section 16(2) clarifies that nothing in Section 16 restricts applicability of any law providing higher protection or greater restriction on transfer of personal data outside India.

If sectoral laws (banking regulations, health data rules, legal professional privilege rules) impose stricter requirements on cross-border data transfers, those requirements continue to apply. The DPDP Act establishes a baseline; sector-specific requirements may exceed it.

VII. Exemptions—When the Act Doesn't Apply

The Act exempts certain processing from some or all obligations, recognising contexts where full compliance would be inappropriate, impractical, or contrary to public interest.

A. Personal or Domestic Purposes (Section 3(c)(i))

The Act does not apply to processing of personal data by an individual for any personal or domestic purpose.

This exemption ensures the Act does not regulate private personal activities. Maintaining a personal contact list, organising family photos with facial recognition, or emailing friends does not trigger DPDP Act obligations.

However, this exemption is narrow. It applies only to individuals (not organisations) and only for genuinely personal or domestic purposes. Once processing extends beyond personal use—for example, if an individual operates a business from home and processes customer data—the exemption ceases to apply.

B. Publicly Available Data (Section 3(c)(ii))

The Act does not apply to personal data made publicly available by:

The Data Principal to whom such data relates, OR
Any other person under an obligation under law to make such data publicly available

The Act illustrates this: an individual blogging her views makes her personal data publicly available on social media. The Act does not apply to processing of such publicly available personal data.

This exemption recognises that data intentionally made public by individuals themselves occupies different status than data shared in restricted contexts. If you post your contact details on a public website, others may process that data without DPDP Act obligations.

Similarly, data required by law to be made public (corporate records, court judgments, government gazettes) may be processed without Act obligations.

However, this exemption has limits. It exempts processing of the publicly available data in the form it was made public. If you collect publicly available data and combine it with non-public data to create detailed profiles, the combined processing may fall within the Act's scope.

C. Research, Archiving, and Statistical Purposes (Section 17(2)(b) and Rule 16)

The Act does not apply to processing necessary for research, archiving or statistical purposes if:

The personal data is not used to make decisions specific to a Data Principal, AND
Processing is carried on in accordance with standards specified in Second Schedule (same standards applicable to government processing under Section 7(b))

These standards include:

Lawful processing
Necessity and proportionality—processing limited to data necessary for the purpose
Reasonable efforts to ensure completeness, accuracy and consistency
Retention limited to that required for the purpose or legal compliance
Reasonable security safeguards to prevent personal data breach
Appropriate technical and organisational measures ensuring effective observance
Accountability of the person determining purpose and means of processing

This exemption facilitates research and statistics while protecting against misuse. Processing historical data for academic research, maintaining archives of cultural or historical significance, or conducting statistical analysis for public policy purposes may proceed under this exemption, provided:

No decisions affecting specific individuals result from the processing
The prescribed standards are observed

D. Exemptions for Certain Data Fiduciaries (Section 17(3))

The Central Government may notify certain Data Fiduciaries or classes of Data Fiduciaries, including startups, as Data Fiduciaries to whom specific provisions do not apply:

Section 5 (notice requirement)
Sub-sections (3) and (7) of Section 8 (data quality for decisions/disclosures; retention and erasure)
Section 10 (Significant Data Fiduciary obligations)
Section 11 (Data Principal's right to access information)

"Startup" means a private limited company, partnership firm, or limited liability partnership incorporated in India, eligible for and recognised as such under criteria and process notified by the department handling startup matters in the Central Government.

This exemption recognises that small and emerging organisations may face disproportionate compliance burdens from full DPDP Act obligations while posing lower risks due to limited scale of operations. The exemption enables startups to innovate and grow without immediate full compliance burdens, while maintaining core obligations (consent, security, rights to correction and erasure, grievance redressal).

E. Processing by State Instrumentalities (Section 17(4))

In respect of processing by the State or any instrumentality of the State:

Sub-section (7) of Section 8 (retention and erasure obligations)
Sub-section (3) of Section 12 (Data Principal's right to erasure)

Do not apply.

Additionally, where such processing is for a purpose that does not include making decisions affecting the Data Principal:

Sub-section (2) of Section 12 (Data Principal's right to correction, completion, updating)

Does not apply.

These exemptions recognise that governmental functions often require long-term retention of records (for historical, legal, or administrative purposes) and that individuals should not be able to unilaterally erase or alter government records. However, where government processing informs decisions affecting individuals, those individuals retain rights to correction to ensure accurate decision-making.

F. Exemptions for Certain Contexts (Section 17(1))

Certain provisions of the Act (Chapters II and III, and Section 16) do not apply in specific contexts:

Enforcing Legal Rights or Claims—processing necessary for enforcing any legal right or claim.

Judicial, Quasi-Judicial, Regulatory, or Supervisory Functions—processing by courts, tribunals, or bodies entrusted by law with performance of judicial, quasi-judicial, regulatory or supervisory functions, where necessary for such performance.

Criminal Justice and Law Enforcement—processing in the interest of prevention, detection, investigation or prosecution of any offence or contravention of any law.

Foreign Contracts—processing of personal data of Data Principals not within India pursuant to contracts with persons outside India by persons based in India.

Mergers and Acquisitions—processing necessary for schemes of compromise, arrangement, merger, amalgamation, reconstruction by demerger, transfer of undertaking, or division of companies, approved by a court, tribunal or other competent authority.

Financial Defaults—processing to ascertain financial information, assets and liabilities of persons who have defaulted on loans or advances from financial institutions, subject to compliance with disclosure provisions in other applicable law.

These exemptions recognise that in certain contexts—legal proceedings, law enforcement, corporate restructuring—full DPDP Act obligations would frustrate legitimate purposes or conflict with other legal frameworks. However, these are narrow exemptions applying only to the specified contexts and purposes.

G. Time-Limited Exemptions (Section 17(5))

The Central Government may, before expiry of five years from the Act's commencement, declare by notification that any provision shall not apply to specified Data Fiduciaries or classes of Data Fiduciaries for a specified period.

This sunset provision allows the Government to phase in compliance requirements for certain sectors or types of organisations, preventing disruption while enabling orderly transition.

H. National Security Exemption (Section 17(2)(a))

The Act does not apply to processing of personal data by such instrumentalities of the State as the Central Government may notify, in the interests of:

Sovereignty and integrity of India
Security of the State
Friendly relations with foreign States
Maintenance of public order
Preventing incitement to any cognizable offence relating to these interests

The exemption extends to processing by the Central Government of any personal data such instrumentalities furnish to it.

This exemption recognises that intelligence agencies, defense establishments, and security organisations require latitude in data processing for national security purposes. However, the exemption applies only to specifically notified instrumentalities, not to all government bodies, and only for the stated security purposes.

VIII. Enforcement and Penalties

The Data Protection Board of India, established under Section 18, exercises enforcement powers under the Act.

A. The Data Protection Board's Role

The Board receives and adjudicates:

Intimations of personal data breach
Complaints from Data Principals about breaches of their rights or violations by Data Fiduciaries or Consent Managers
References from Central or State Governments
Directions from courts

The Board may inquire into breaches and impose penalties specified in the Schedule.

For effective discharge of functions, the Board functions as a digital office, conducting proceedings online from receipt of intimation or complaint through disposal. The Board possesses powers equivalent to a civil court for summoning and enforcing attendance, receiving evidence, requiring document discovery, inspecting data and documents, and other prescribed matters.

B. Penalty Structure

The Schedule to the Act specifies penalties for different categories of breaches:

Up to ₹250 crore:

Breach of obligation to take reasonable security safeguards to prevent personal data breach

Up to ₹200 crore:

Breach of obligation to notify the Board or affected Data Principal of personal data breach
Breach of obligations regarding children's data

Up to ₹150 crore:

Breach of additional obligations of Significant Data Fiduciary

Up to ₹10,000:

Breach of duties of Data Principal

Up to applicable breach penalty:

Breach of terms of voluntary undertaking accepted by the Board

Up to ₹50 crore:

Breach of any other Act provision or rules

These represent maximum penalties; actual penalties depend on factors the Board considers.

C. Factors in Determining Penalties (Section 33(2))

In determining penalty amounts, the Board considers:

Nature, gravity and duration of breach—more serious and prolonged breaches warrant higher penalties.

Type and nature of personal data affected—breaches involving sensitive data (health, financial, children's data) incur higher penalties than those involving basic contact information.

Repetitive nature of breach—repeat violations indicate systemic non-compliance warranting enhanced penalties.

Whether the person realised gain or avoided loss from the breach—breaches generating economic benefit incur penalties reflecting that benefit.

Whether the person acted to mitigate breach effects and consequences, and the timeliness and effectiveness of such action—prompt, effective breach response mitigates penalties.

Whether the penalty is proportionate and effective to secure observance and deter breach—penalties must be sufficient to incentivise compliance, calibrated to the specific Data Fiduciary's circumstances.

Likely impact of the penalty on the person—penalties should not be so severe as to destroy organisations but must be meaningful enough to deter non-compliance.

This factors-based approach enables proportionate, contextualised penalties rather than arbitrary fixed amounts. The Board exercises discretion within the statutory maximums based on the specific circumstances of each case.

D. Voluntary Undertaking (Section 32)

At any stage of a proceeding, the Board may accept a voluntary undertaking from any person. The undertaking may include commitments to:

Take specified action within specified time
Refrain from taking specified action
Publicise the undertaking

Once the Board accepts a voluntary undertaking with the person's consent, the Board may vary its terms.

Acceptance of a voluntary undertaking bars further proceedings regarding the matters addressed in the undertaking, except where the person fails to adhere to its terms. Failure to adhere is deemed a breach of the Act, and the Board may proceed with penalties applicable to the original breach.

Voluntary undertaking provides a mechanism for resolving matters without contested proceedings and penalties. It incentivises self-reporting, cooperation, and remediation. For organisations that identify breaches and proactively propose remedial action, voluntary undertaking offers an alternative to adversarial enforcement.

IX. Implementation Roadmap for Organisations

The phased commencement of the Act and Rules creates a structured timeline for implementation.

A. Immediate Actions

Even before substantive compliance obligations take effect, organisations should:

Conduct data inventory—identify what personal data you process, from whom, for what purposes, under which legal bases, and with what sharing.

Map data flows—understand how personal data moves through your organisation and to third parties.

Identify gaps—compare current practices against Act requirements to identify compliance gaps.

Build awareness—educate leadership, management, and staff about DPDP Act requirements and implications.

Review vendor relationships—assess Data Processors' capabilities and contractual protections.

Establish governance—designate responsible persons, establish decision-making frameworks, and create accountability mechanisms.

B. Within 12 Months (Before Rule 4)

Rule 4, addressing Consent Manager registration and obligations, takes effect one year after Rules publication.

During this period:

Evaluate Consent Manager integration—assess whether your operations would benefit from using Consent Managers' platforms for consent management.

Monitor Consent Manager market development—observe which Consent Managers register with the Board and what services they offer.

Prepare consent infrastructure—regardless of Consent Manager use, ensure your consent mechanisms meet Act requirements (clear notice, free and specific consent, easy withdrawal).

C. Within 18 Months (Before Full Implementation)

Rules 3, 5-16, 22 and 23 take effect eighteen months after Rules publication, triggering substantive compliance obligations.

By this deadline:

Implement notice requirements (Rule 3)—ensure all Data Principals receive clear, compliant notices before consent requests.

Update consent mechanisms—bring consent processes into full compliance with Act requirements.

Implement security safeguards (Rule 6)—ensure encryption, access controls, logging, backups, and other measures meet standards.

Establish breach response processes (Rule 7)—create capability to detect breaches, assess impact, and notify the Board and Data Principals within required timeframes.

Implement retention and erasure processes (Rule 8)—establish systems to erase data when required, while maintaining one-year minimum retention for accountability.

Publish contact information (Rule 9)—make Data Protection Officer or other contact information prominently available.

Enable rights exercise (Rule 14)—create functioning mechanisms for Data Principals to access information, request corrections and erasure, and file grievances with 90-day response capability.

For children's data—implement verifiable parental consent mechanisms (Rules 10), ensure processing complies with prohibitions (Section 9).

For Significant Data Fiduciaries—appoint Data Protection Officer and independent auditor (Section 10), conduct Data Protection Impact Assessment and audit (Rule 13).

Prepare for cross-border transfer requirements—monitor for notifications specifying requirements (Rule 15), document transfers and implement safeguards.

Establish grievance redressal—implement effective mechanisms capable of responding to grievances within 90 days (Rule 14).

D. Ongoing Obligations

Post-implementation, maintain:

Continuous monitoring—oversight of processing activities, security measures, Data Processor performance, and compliance status.

Regular assessments—periodic review and testing of controls, updating as technologies and threats evolve.

Incident preparedness—maintaining and testing breach response capabilities.

Training and awareness—ongoing education for personnel on data protection requirements and practices.

Governance and accountability—management oversight, reporting, and continuous improvement.

For Significant Data Fiduciaries—annual Data Protection Impact Assessment and audit with reports to the Board.

X. Practical Takeaways by Organisational Function

Different organisational functions face distinct implications from the DPDP Act.

A. For Legal and Compliance Teams

Master the Act's structure—understand the consent versus legitimate use framework, obligations, rights, exemptions, and enforcement mechanisms.
Map legal bases—work with business units to identify the appropriate legal basis for each processing activity.
Draft and review notices—ensure notices meet Rule 3 requirements for clarity, completeness, and accessibility.
Update terms of service and privacy policies—align with Act requirements while maintaining clarity.
Establish vendor contracting standards—ensure Data Processor agreements include required provisions.
Create incident response protocols—define roles, procedures, and authorities for breach response and notification.
Liaise with the Board—manage intimations, complaints, references, and other Board interactions.
Monitor regulatory developments—track Board guidance, Government notifications, and enforcement trends.

B. For IT and Security Teams

Implement technical security safeguards—deploy encryption, access controls, logging, and monitoring consistent with Rule 6 requirements.
Establish data retention and erasure capabilities—create systems to implement retention policies and execute erasure requests.
Enable breach detection and response—implement monitoring and alerting capabilities to detect and respond to breaches promptly.
Facilitate rights exercise—build or procure systems enabling Data Principals to access, correct, and erase their data.
Manage Data Processor security—assess Processor security capabilities, monitor their performance, and enforce contractual obligations.
Implement data minimisation—configure systems to collect and retain only necessary personal data.
Document data flows—maintain current understanding of where personal data resides, how it moves, and who accesses it.
Conduct security testing—regularly assess security measures' effectiveness through penetration testing, vulnerability assessment, and control validation.

C. For Human Resources Departments

Classify employee data processing—determine which employee data processing qualifies under Section 7(i)'s employment purposes legitimate use versus requiring consent.
Update employee notices and policies—inform employees about personal data processing in employment context.
Establish employee data correction and erasure processes—enable employees to exercise rights regarding their personal data.
Address employee grievances—incorporate data protection matters into employee grievance mechanisms.
Manage background checks and verification—ensure pre-employment data processing complies with Act requirements.
Handle employment references and verification requests—process such requests consistent with legitimate uses and employee rights.
Coordinate with IT on employee monitoring—ensure any employee monitoring (email, system access, location tracking) has appropriate legal basis and is communicated to employees.

D. For Marketing Teams

Shift to consent-based marketing—unless processing qualifies as voluntary provision under Section 7(a), marketing communications require explicit consent.
Implement granular consent—enable Data Principals to consent specifically to marketing communications, separating this from consent for service provision.
Honour withdrawal promptly—create processes to cease marketing processing quickly upon consent withdrawal.
Avoid processing children's data for marketing—given Section 9(3)'s prohibition on targeted advertising to children, ensure marketing data sets exclude children.
Respect data minimisation—collect only personal data actually needed for marketing purposes, not "nice to have" data without specific use.
Coordinate with IT on marketing technology—ensure marketing automation, CRM systems, and analytics platforms comply with security and retention requirements.
Document marketing consent—maintain clear records of consent for marketing processing to demonstrate compliance if questioned.

E. For Customer Service Functions

Serve as rights exercise interface—customer service often receives Data Principal requests for access, correction, erasure, and grievance redressal.
Train staff on DPDP Act rights—ensure customer service personnel understand Data Principal rights and how to facilitate their exercise.
Establish escalation procedures—create clear escalation paths from customer service to legal, IT, or management for rights requests and grievances.
Track and respond to grievances—implement systems to track grievances, ensure timely responses (within 90 days), and document resolutions.
Coordinate data corrections—when customers report inaccurate data, ensure corrections propagate across systems and shared data is updated with recipients.
Handle erasure requests—coordinate with IT to verify erasure completion and notify Data Principals.
Maintain customer service records appropriately—balance retention for quality assurance, dispute resolution, and service improvement against erasure obligations.

XI. Conclusion

The Digital Personal Data Protection Act, 2023 represents India's commitment to recognising and protecting individual privacy rights while enabling the digital economy's growth. For organisations, the Act creates clear obligations balanced by reasonable flexibility through legitimate uses and exemptions.

Compliance is not merely a legal obligation but an opportunity to build trust with Data Principals. Organisations that embrace data protection principles—transparency, purpose limitation, data minimisation, security, accountability—position themselves advantageously in an increasingly privacy-conscious market. Consumers, employees, and business partners increasingly prefer organisations that demonstrate respect for personal data.

The phased implementation approach provides organisations with time to understand requirements, assess current practices, identify gaps, and implement necessary changes systematically. This is not a sprint but a sustained effort requiring coordination across legal, technology, operations, and management functions.

The Centre for Applied Data Protection (CADP) at KLE Society's Law College, Bangalore stands ready to support organisations navigating these requirements. Whether you need assistance with data mapping and gap assessment, implementing specific compliance measures, training your teams, or ongoing advisory support, CADP's expertise in both legal frameworks and practical implementation equips us to serve as your partner in DPDP Act compliance.

This analysis has examined what the Act requires. Our companion Implementation Guide translates these requirements into practical frameworks, tools, and processes for compliance. We encourage organisations to consult the Implementation Guide and reach out to CADP for tailored assistance.

The DPDP Act journey has begun. With understanding, planning, and appropriate support, organisations can navigate this transition successfully, emerging as trustworthy stewards of personal data in India's digital future.

About the Author: This analysis was prepared by the Centre for Applied Data Protection (CADP), KLE Society's Law College, Bangalore. CADP specialises in bridging legal frameworks with operational implementation, providing training, research, and advisory services on India's Digital Personal Data Protection Act.

For CADP's compliance advisory, please reach out here.