The DPDP Act 2023 & Rules 2025 in Plain English

Section 4 lays down the foundational rule for all personal data processing in India. A Data Fiduciary may process personal data only if one of two conditions is met: the Data Principal has given consent, or the processing falls under a recognised legitimate use.

The Act also defines what counts as a "lawful purpose" — it is any purpose that is not expressly forbidden by law. In other words, if no statute prohibits the activity, it can qualify as a lawful purpose. However, having a lawful purpose alone is not enough; you still need either consent or a legitimate use ground to actually process the data.

This two-track structure shapes everything that follows. If you rely on consent, Sections 5 and 6 govern how you must obtain and manage it. If you rely on a legitimate use, Section 7 lists the specific situations where consent is not required.

Every time a Data Fiduciary requests consent, it must accompany or precede that request with a notice. This notice must tell the Data Principal three things: first, what personal data will be collected and for what purpose; second, how the Data Principal can exercise their rights under Section 6(4) (withdrawal of consent) and Section 13 (rights such as correction, erasure, and grievance redressal); and third, how to file a complaint with the Data Protection Board.

For personal data that was already being processed before the Act came into force, the Data Fiduciary must give the same notice as soon as reasonably practicable. Processing may continue until the Data Principal actually withdraws consent — there is no automatic cut-off — but the notice obligation still applies.

The notice must be available in English or any language listed in the Eighth Schedule to the Constitution of India. This covers 22 languages including Hindi, Bengali, Tamil, Telugu, Marathi, Gujarati, Kannada, Malayalam, Odia, Punjabi, Assamese, and Urdu, among others.

Rule 3 adds further detail on what makes a notice compliant. The notice must be understandable on its own — a person should not need to read other documents to make sense of it. It must use clear, plain language with an itemised description of the personal data being collected and the specified purposes for which it will be used. Finally, it must provide communication links that allow the Data Principal to withdraw consent, exercise their rights, and file complaints with the Board.

Section 6 is the most operationally detailed section of the Act. It sets out ten sub-sections that together define how consent must be obtained, managed, and withdrawn.

To be valid, consent must meet seven criteria: it must be free (not coerced), specific (tied to particular data and purposes), informed (the Data Principal understands what they are agreeing to), unconditional (not bundled with unrelated conditions), unambiguous (leaving no room for doubt about the Data Principal's intention), given through a clear affirmative action (such as ticking a box or clicking a button — silence or pre-ticked boxes do not count), and limited to the personal data that is necessary for the specified purpose. If a Data Fiduciary collects more data than necessary for the stated purpose, the consent for the excess data is not valid.

Any portion of a consent request that infringes the Act is invalid to that extent. This means if part of your consent form violates the Act, the rest may still hold, but the offending portion is struck down.

The consent request itself must be presented in clear, plain language. The Data Principal must be given the option to read the request in English or any Eighth Schedule language. The request must also include contact details of the Data Protection Officer or an authorised person who can answer questions.

Withdrawal of consent is a fundamental right. The Data Principal may withdraw consent at any time. Critically, the ease of withdrawing consent must be comparable to the ease of giving it. If consent is given with a single click, withdrawal should not require filling out a form, sending an email, and waiting for a response.

Once consent is withdrawn, the consequences fall on the Data Principal — for example, they may lose access to a service that requires that data. However, any processing that took place before withdrawal remains lawful. The Data Fiduciary must stop processing within a reasonable time after withdrawal, unless another legal basis (such as a legitimate use) authorises continued processing.

The burden of proof sits squarely with the Data Fiduciary. If a dispute arises, the Data Fiduciary must prove that notice was given and valid consent was obtained. This makes proper record-keeping essential.

The Act introduces the concept of a Consent Manager — an entity through which Data Principals can give, manage, review, and withdraw consent. Think of it as a consent dashboard that sits between individuals and the organisations that process their data.

A Consent Manager is accountable to the Data Principal and acts on their behalf. This means the Consent Manager takes instructions from the individual, not from the Data Fiduciary.

Every Consent Manager must be registered with the Data Protection Board. Rule 4 sets out the conditions for registration, which are detailed in the First Schedule, Part A. To qualify, a Consent Manager must be a company incorporated in India, have a net worth of at least two crore rupees, demonstrate adequate technical and operational capacity, and obtain an independent certification.

The Board reviews applications and may either register or reject a Consent Manager. Registration can also be suspended or cancelled if the Consent Manager fails to meet its obligations.

The obligations of a Consent Manager are set out in the First Schedule, Part B. They must enable consent management through an interoperable platform — meaning it works across different Data Fiduciaries, not just one. Personal data passing through the platform must not be readable by the Consent Manager itself. Records must be maintained for seven years. Subcontracting is prohibited — the Consent Manager must perform its functions directly. And there must be no conflicts of interest.

While consent is the primary basis for processing, the Act recognises that requiring consent in every situation would be impractical or counterproductive. Section 7 defines nine legitimate uses where processing is permitted without consent.

First: voluntary provision without objection. If a Data Principal voluntarily provides their personal data for a specified purpose and has not indicated that they do not consent, the Data Fiduciary may process it. For example, if a customer willingly fills out a feedback form, that data can be processed for the stated purpose without a separate consent step — as long as the individual has not signalled otherwise.

Second: State provision of subsidies, benefits, and services. The State may process personal data to provide subsidies, benefits, services, certificates, licences, or permits. This applies when the Data Principal has previously consented to such processing, or when the data comes from government databases. This covers programmes like Aadhaar-linked benefit transfers or digital locker-based document issuance.

Third: State functions under law or sovereign interests. The State may process personal data when performing functions authorised by law or when acting in the interest of sovereignty, integrity, or security of India.

Fourth: legal disclosure obligations. When any person is legally obligated to disclose information to the State — for instance, under tax laws or regulatory reporting requirements — that processing does not require the Data Principal's consent.

Fifth: compliance with judicial orders. Processing personal data to comply with any judgment, decree, or order of a court or tribunal does not require consent.

Sixth: medical emergencies. When there is a threat to the life or health of the Data Principal or any other individual, personal data may be processed to respond to the emergency. This covers situations such as sharing a patient's medical history with emergency responders.

Seventh: epidemic and public health response. During epidemics, disease outbreaks, or threats to public health, personal data may be processed for medical treatment purposes without consent.

Eighth: disaster and public order situations. Personal data may be processed to ensure safety and provide assistance during disasters or breakdowns of public order.

Ninth: employment purposes. An employer may process employee data for purposes related to safeguarding the employer from loss or liability. This explicitly covers corporate espionage prevention, trade secret protection, and providing services to employees who are themselves Data Principals. For example, an employer may monitor work email to protect trade secrets, or process employee data to administer payroll and benefits.

Rule 5 adds an important constraint for State processing under these provisions. When the State processes personal data under a legitimate use, it must follow the standards set out in the Second Schedule. These require that processing be lawful, limited to data that is necessary, backed by reasonable efforts for accuracy, retained only as long as needed, and protected by reasonable security safeguards.

Section 8 sets out eleven sub-sections covering the core duties of every Data Fiduciary. These obligations apply regardless of any contractual arrangements with third parties and regardless of whether the Data Principal has performed their own duties under the Act.

Accountability is non-delegable. Sub-section (1) makes clear that a Data Fiduciary remains responsible for complying with the Act even if a Data Processor handles the actual processing. You cannot outsource your compliance obligations through a contract.

Data Processors must be engaged under valid contracts. Sub-section (2) requires that any Data Processor — a third party that processes data on your behalf — may only be engaged under a valid contract. This means written agreements with clear terms about how data will be handled.

Data accuracy matters. Sub-section (3) requires the Data Fiduciary to ensure completeness, accuracy, and consistency of personal data, but only in two specific scenarios: when that data may be used to make decisions affecting the Data Principal, or when it may be disclosed to another Data Fiduciary. For example, if you use personal data to decide whether to approve a loan, or if you share customer data with a partner company, you must make sure it is complete and accurate.

Technical and organisational measures are mandatory. Sub-section (4) requires appropriate technical and organisational measures to be in place. This is a broad obligation — the Act does not prescribe specific technologies, but expects measures proportionate to the risk.

Security safeguards to prevent breaches. Sub-section (5) requires reasonable security safeguards to prevent personal data breaches. What counts as "reasonable" depends on the nature and volume of data, as further detailed in Rule 6.

Breach notification is mandatory. Sub-section (6) requires the Data Fiduciary to notify both the Data Protection Board and each affected Data Principal in the event of a personal data breach. The specifics of timing and content are covered in Rule 7.

Erasure obligations. Sub-section (7) requires the Data Fiduciary to erase personal data when consent is withdrawn or the specified purpose is no longer being served — whichever happens first. The Data Fiduciary must also ensure that any Data Processor it has engaged erases the data as well. Retention is permitted only when required by law.

Deemed purpose fulfilment. Sub-section (8) introduces a time-based trigger: if a Data Principal does not approach the Data Fiduciary or exercise any rights for a prescribed period of time, the specified purpose is deemed to have been fulfilled. This means the erasure obligation kicks in automatically after a period of inactivity. Sub-section (11) clarifies that "not having approached" means the Data Principal has not initiated any contact — whether in person, electronically, or in physical written form.

Published contact information. Sub-section (9) requires every Data Fiduciary to publish the contact details of its Data Protection Officer or an authorised person who can handle queries. Rule 9 adds that this must be done prominently on the Data Fiduciary's website or app, and the same contact information must be included in every response sent to a Data Principal.

Grievance redressal. Sub-section (10) requires the establishment of an effective grievance redressal mechanism. This is not optional — every Data Fiduciary must have a process through which Data Principals can raise concerns and receive responses.

While Section 8(5) of the Act requires "reasonable security safeguards," Rule 6 translates that into concrete minimum requirements. These are not optional best practices — they are mandatory baselines.

Encryption and data protection techniques. Data Fiduciaries must use encryption, obfuscation, masking, or virtual tokens to protect personal data. The Rule does not mandate a specific encryption standard, but the expectation is that data must not be stored or transmitted in a form that can be easily read if intercepted or accessed without authorisation.

Access controls. Access to computer resources containing personal data must be controlled. This means not everyone in the organisation should have access to all personal data — access should be limited based on role and necessity.

Logging, monitoring, and review. Data Fiduciaries must maintain logs, conduct monitoring, and perform reviews aimed at detecting unauthorised access to personal data. This is not a one-time setup — it requires ongoing vigilance.

Backup and continuity measures. Backup measures must be in place to ensure that personal data processing can continue even if data is compromised. This covers scenarios like ransomware attacks or accidental deletion.

Minimum retention for detection purposes. Logs and personal data must be retained for a minimum of one year. This retention is specifically to enable detection, investigation, and remediation of breaches — it exists alongside (and is separate from) the erasure obligations under Section 8(7).

Contractual provisions with Data Processors. When a Data Processor handles personal data on your behalf, your contract with them must include provisions for maintaining security safeguards. The Data Fiduciary cannot simply hand over data without ensuring the Processor will protect it.

Appropriate technical and organisational measures. As a catch-all, Rule 6 reiterates the requirement for appropriate technical and organisational measures. This ensures that the list above is treated as a floor, not a ceiling — additional measures may be needed depending on the nature and volume of data being processed.

Rule 7 sets out the breach notification process in two tracks: one for the Data Principal and one for the Data Protection Board.

Notification to the Data Principal must happen without delay. It must be sent through the Data Principal's user account or via a registered communication channel. The notification must include: a description of the breach, the consequences that may result from it, the measures the Data Fiduciary has taken in response, the safety measures the Data Principal can take on their end, and the contact information of the person the Data Principal can reach for more information.

Notification to the Board follows a two-stage process. The first stage — without delay — must include a description of the breach, the nature and extent of the data affected, the timing of the breach, and the likely impact. The second stage — within 72 hours — requires a more detailed submission: updated and comprehensive information about the breach, the facts, circumstances, and reasons behind it, the mitigation measures taken, findings about who or what caused the breach, the remedial measures put in place, and a report on how affected Data Principals have been notified.

The 72-hour window is significant. It starts from the time the Data Fiduciary becomes aware of the breach — not from when the breach occurred. Given that a detailed investigation, root cause analysis, and Data Principal notification report must all be ready within this window, organisations need a pre-established breach response plan to meet this deadline.

The Act's default rule under Section 8(7) is straightforward: erase personal data when consent is withdrawn or the specified purpose is no longer being served — whichever happens first. The Data Fiduciary must also ensure that any Data Processor it has engaged erases the data. The only exception is when retention is required by another law.

Section 8(8) adds an automatic trigger. If a Data Principal does not approach the Data Fiduciary or exercise any of their rights for a prescribed period of time, the specified purpose is deemed to have been fulfilled. Once that happens, the erasure obligation kicks in. This prevents organisations from retaining data indefinitely by arguing the purpose is still technically alive.

Rule 8 prescribes specific retention periods for certain categories of large-scale Data Fiduciaries. E-commerce entities with two crore or more registered users must retain data for three years. Online gaming intermediaries with fifty lakh or more registered users must retain data for three years. Social media intermediaries with two crore or more registered users must retain data for three years.

Before erasing data, the Data Fiduciary must inform the Data Principal at least 48 hours in advance. This gives the individual an opportunity to take action — such as downloading their data — before it is deleted.

Separately, all Data Fiduciaries — regardless of size or category — must retain logs and personal data for a minimum of one year. This retention is mandated by Rule 6 for the purpose of detecting, investigating, and remediating security breaches, and it operates independently of the erasure timelines above.

Section 9 establishes a protective regime for children's personal data. Under the Act, a child is any person under the age of 18.

Verifiable parental consent is required. Before processing a child's personal data, the Data Fiduciary must obtain verifiable consent from the child's parent. Rule 10 specifies how this verification works: the parent's identity and age must be confirmed using reliable details, which may come from the Data Fiduciary's own records, details voluntarily provided by the parent, or verification through an authorised entity such as Digital Locker.

For persons with disability, Rule 11 requires that the Data Fiduciary verify the identity of a lawful guardian who has been appointed by a court or a designated authority.

Harm prevention. Section 9(2) prohibits processing of data that is likely to cause a detrimental effect on a child's well-being. This is a broad standard — it applies regardless of the type of data or the purpose of processing.

Tracking and advertising ban. Section 9(3) prohibits three specific activities in relation to children: tracking, behavioural monitoring, and targeted advertising. This means a Data Fiduciary cannot use a child's data to build a behavioural profile, monitor their online activity for commercial purposes, or serve them personalised advertisements.

Exemptions exist. Sections 9(4) and 9(5) allow the Central Government to grant exemptions. The requirement for verifiable parental consent and the tracking and advertising ban may be relaxed for prescribed classes of Data Fiduciaries or for prescribed purposes. Additionally, the Central Government may lower the age threshold below 18 for specific Data Fiduciaries that process children's data in a verifiably safe manner.

Rule 12 lists the specific exemptions currently in place. The following categories are exempt from the child-specific provisions: clinical establishments, mental health professionals, and allied health professionals (for healthcare purposes); educational institutions (for tracking student progress and ensuring safety); childcare centres; and child transport services. Exempt purposes include: government functions that benefit children, State provision of subsidies, creation of email accounts, restricting access to harmful content, and age verification processes.

Not all Data Fiduciaries are treated equally under the Act. Section 10 empowers the Central Government to designate certain organisations as Significant Data Fiduciaries (SDFs). This designation is based on factors such as the volume and sensitivity of personal data processed, the risk to the rights of Data Principals, the potential impact on sovereignty and integrity of India, the risk to electoral democracy, the security of the State, and public order.

Once designated as an SDF, three additional obligations apply. First, the SDF must appoint a Data Protection Officer (DPO). This is not a nominal role — the DPO must be based in India, must represent the SDF in dealings with the Board and Data Principals, must be answerable to the Board of Directors, and must serve as the point of contact for grievance redressal.

Second, the SDF must appoint an independent data auditor to conduct compliance evaluations. This auditor must be external and independent — the SDF cannot audit itself.

Third, the SDF must undertake periodic Data Protection Impact Assessments (DPIAs) and periodic audits. These are not one-time exercises but recurring obligations.

Rule 13 adds further detail and additional requirements. DPIAs and audits must be conducted at least once every twelve months — making them annual obligations. Any significant observations from these assessments must be reported to the Data Protection Board.

Rule 13 also introduces an algorithmic accountability requirement: SDFs must verify that any algorithmic software they use does not pose a risk to the rights of Data Principals. This covers automated decision-making systems, recommendation engines, and similar technologies.

Finally, Rule 13 addresses data localisation. The Central Government, on the recommendation of a committee, may restrict certain categories of personal data from leaving India. When such a restriction is in place, the affected SDF must ensure that the specified personal data is stored and processed within India's borders.

Section 11 gives you the right to go back to any organisation you previously gave consent to and ask: what data do you have on me, and what are you doing with it? This right applies specifically to Data Fiduciaries to whom you have given consent — it is not a general right to query any organisation.

When you exercise this right, the Data Fiduciary must provide three categories of information. First, a summary of the personal data being processed and the processing activities undertaken with it. Second, the identities of all other Data Fiduciaries and Data Processors with whom your data has been shared, along with a description of what data was shared with each. Third, any other information about your personal data and its processing that may be prescribed by rules.

For example, if you signed up for a food delivery app and consented to it collecting your location data, order history, and payment details, you can ask the app to tell you exactly what data it holds about you, what it is doing with that data, and which third parties — such as payment processors, delivery partners, or analytics companies — have received any of it.

There is one exception. The obligation to disclose the identities of other Data Fiduciaries and Data Processors does not apply where data was shared with another Data Fiduciary that is authorised by law to obtain the data for the prevention, detection, investigation, or prosecution of offences, or for dealing with cyber incidents. In other words, if your data was shared with a law enforcement agency under a legal mandate, the original Data Fiduciary is not required to tell you about that specific sharing.

Rule 14 adds practical requirements for how this right is exercised. The Data Fiduciary and any Consent Manager must publish on their website or app the means through which a Data Principal can make requests, along with the identifiers required. An "identifier" can be a customer ID, application reference number, enrolment ID, email address, mobile number, or licence number — whatever the organisation uses to look you up in its systems.

Section 12 gives you the right to request four specific actions on the personal data you previously consented to being processed: correction of inaccurate or misleading data, completion of incomplete data, updating of data that is no longer current, and erasure of data you want deleted.

The correction right is straightforward. If a Data Fiduciary holds data about you that is wrong or misleading, you can ask them to fix it. If data is incomplete — for example, your address is partially recorded — you can ask them to complete it. If your phone number or employer has changed, you can ask them to update it.

Erasure works differently. When you request erasure, the Data Fiduciary must delete your data unless retention is necessary for the specified purpose for which you originally consented to processing, or unless another law requires the data to be retained. For instance, a financial services company may be required under anti-money laundering regulations to retain your records for a certain number of years, even if you ask for deletion.

Consider a practical example. You signed up for an e-commerce platform five years ago. You no longer use it, and you want your data removed. You can submit an erasure request. The platform must comply — unless it has a legal obligation to retain your data (such as tax records) or the data is still needed for a purpose you consented to that has not yet been fulfilled.

Rule 14 governs the procedure. Data Fiduciaries must publish on their website or app the means for making correction and erasure requests, along with the required identifiers. Grievance redressal timelines must also be published, with a reasonable period not exceeding 90 days for a response. Additionally, a Data Principal may nominate individuals to exercise these rights on their behalf.

Section 13 establishes a right to grievance redressal. Every Data Principal has the right to readily available means of registering a grievance with a Data Fiduciary or Consent Manager. This is not a vague promise — the Act requires that the mechanism be readily available, meaning it must be easy to find and easy to use.

Once a grievance is filed, the Data Fiduciary or Consent Manager must respond within a prescribed period. Rule 14 sets this period at a reasonable timeframe not exceeding 90 days. The exact number of days may vary by organisation, but 90 days is the outer limit.

There is an important procedural requirement: a Data Principal must exhaust the grievance mechanism of the Data Fiduciary or Consent Manager before approaching the Data Protection Board. You cannot skip the internal process and go directly to the Board. This is designed to give organisations a chance to resolve issues before regulatory intervention.

In practice, this means that if you believe a food delivery app is not complying with your data correction request, your first step is to use the app's grievance mechanism. If they do not respond, or if their response is unsatisfactory, you then have the right to escalate the matter to the Data Protection Board.

Rule 14 requires that the grievance redressal timelines be published on the Data Fiduciary's website or app, so you know upfront how long the process should take.

Section 14 addresses what happens to your data rights when you can no longer exercise them yourself. Every Data Principal has the right to nominate any individual who, in the event of the Data Principal's death or incapacity, can step in and exercise the Data Principal's rights under the Act.

"Incapacity" is defined as the inability to exercise rights due to unsoundness of mind or infirmity of body. This covers situations such as a serious illness that leaves a person unable to manage their own affairs, or a mental health condition that prevents informed decision-making.

The nominee does not need to be a family member. The Act says "any individual" — this gives the Data Principal full flexibility to choose a trusted person.

This provision matters because personal data does not disappear when someone dies or becomes incapacitated. Without a nominated person, there would be no one authorised to request information about the data, correct it, or ask for its deletion. The nominee steps into the Data Principal's shoes for all rights under the Act.

Rule 14 supports this by allowing the nomination process to be carried out through the means published by the Data Fiduciary on its website or app, using the same identifier-based system used for other rights requests.

Section 15 is one of the most distinctive features of the DPDP Act. Most data protection laws around the world — including the GDPR, CCPA, and LGPD — treat individuals purely as rights-holders. The DPDP Act takes a different approach: it also assigns duties to the Data Principal.

There are five duties. First, you must comply with all applicable laws while exercising your rights under the Act. Your data protection rights do not override other legal obligations.

Second, you must not impersonate another person while providing personal data to a Data Fiduciary. If you pretend to be someone else when signing up for a service or submitting a form, you are in breach of this duty.

Third, you must not suppress any material information when providing personal data for the purpose of obtaining a government-issued document. This covers applications for unique identification numbers (such as Aadhaar), proof of identity, proof of address, and similar documents. For example, if you are applying for a passport and deliberately withhold information that is relevant to your application, you are in breach.

Fourth, you must not register a false or frivolous grievance or complaint with a Data Fiduciary or the Data Protection Board. This duty is designed to prevent the misuse of grievance mechanisms — using them as a tool for harassment or to waste an organisation's resources.

Fifth, when exercising the right to correction or erasure under Section 12, you must furnish only verifiably authentic information. If you submit a correction request with false information, you are in breach of this duty.

Breach of any of these duties can attract a penalty of up to ten thousand rupees under the Act. While this amount may seem modest, the existence of duties on individuals is itself significant — it establishes the principle that data protection is a two-way relationship between organisations and individuals.

Section 16 takes a permissive approach to cross-border data transfers. The Central Government may, by notification, restrict transfer of personal data to specific countries or territories. This means transfer is allowed by default — you do not need pre-approval — unless the government has published a notification restricting transfer to the destination country.

This is called a "negative list" model. Instead of maintaining a list of approved countries (the approach taken by the GDPR, which grants adequacy decisions to qualifying jurisdictions), India will maintain a list of restricted countries. If a country is not on the restricted list, data can flow freely to it.

For businesses, this means the default position is favourable. Unless and until the Central Government publishes a restriction notification naming a particular country, you can transfer personal data there. However, organisations should monitor government notifications, because the restricted list could be updated at any time.

Section 16(2) adds an important clarification: the cross-border transfer provision does not restrict the applicability of any other Indian law that provides a higher degree of protection or imposes stricter restrictions on data transfers. If another statute imposes tighter controls — for instance, sector-specific regulations in banking or telecommunications — those controls continue to apply on top of Section 16.

Rule 15 introduces a specific compliance requirement. When making personal data available outside India, the Data Fiduciary must meet any requirements the Central Government specifies regarding making personal data available to a foreign State, any person or entity controlled by a foreign State, or any agency of a foreign State. This means that even when transferring data to a non-restricted country, if the recipient is a foreign government entity or is controlled by one, additional requirements may apply.

Section 17 is the longest and most complex exemption provision in the Act. It contains five sub-sections, each creating a different type of exemption. Understanding what is exempted — and what still applies — is essential for compliance planning.

Sub-section (1) provides partial exemptions from most of the consent and rights framework. Six categories of processing are exempt from Chapter II (consent and grounds for processing), Chapter III (Data Principal rights), and Section 16 (cross-border transfers). However, even for these categories, Section 8(1) — the non-delegable compliance responsibility of the Data Fiduciary — and Section 8(5) — the obligation to maintain reasonable security safeguards — continue to apply. The six categories are: processing necessary for enforcing legal rights or claims; processing by courts, tribunals, or regulatory bodies performing judicial, quasi-judicial, regulatory, or supervisory functions; processing for the prevention, detection, investigation, or prosecution of offences; processing personal data of non-Indian Data Principals under contracts with persons outside India; processing related to mergers, amalgamations, or reconstructions approved by courts; and processing necessary for ascertaining the financial information, assets, and liabilities of loan defaulters under the Insolvency and Bankruptcy Code 2016.

Sub-section (2) provides complete exemptions from the entire Act. First, the Central Government may exempt any State instrumentality from the Act entirely, where the exemption is necessary for sovereignty or integrity of India, security of the State, friendly relations with foreign States, public order, or prevention of incitement to cognisable offences. Second, processing for research, archiving, or statistical purposes is exempt from the entire Act, provided the data is not used for making decisions about specific Data Principals and the processing is carried out in accordance with prescribed standards. Rule 16 specifies that these standards are set out in the Second Schedule to the Rules.

Sub-section (3) creates class-based exemptions — and this is where the startup exemption lives. The Central Government may exempt classes of Data Fiduciaries, including startups, from six specific provisions: Section 5 (notice requirements), Section 6 (consent requirements), Section 8(3) (data accuracy obligations), Section 8(7) (data erasure obligations), Section 10 (Significant Data Fiduciary obligations), and Section 11 (right to information). A "startup" is defined as a private limited company, partnership firm, or limited liability partnership incorporated in India and recognised as a startup per criteria set by the Central Government. This exemption is significant because it reduces the compliance burden on early-stage companies. However, even exempt startups remain subject to Section 8(1) — they cannot outsource their compliance responsibility — and Section 8(5) — they must still maintain reasonable security safeguards. The exemption is also subject to conditions the Central Government may specify.

Sub-section (4) provides a specific exemption for the State. The State is exempt from Section 8(7) and Section 8(8) — the obligations to erase data when consent is withdrawn or the purpose is fulfilled, and the deemed purpose fulfilment on inactivity. The State is also exempt from Section 12(3) — the obligation to erase data on request from the Data Principal. Additionally, where processing has no legal effect on the Data Principal, the State is exempt from Section 12(2) — the obligation to correct, complete, or update data on request.

Sub-section (5) is a transitional provision. The Central Government may, for a period of up to five years, declare that any provision of the Act does not apply to specified Data Fiduciaries. This gives the government a tool to phase in compliance requirements gradually. An organisation that receives a transitional exemption today could be required to comply fully within five years.

The Data Protection Board of India is established by the Central Government under Section 18. It is a body corporate — meaning it has its own legal identity, can sue and be sued, and operates independently. The Board's headquarters are located at a place notified by the Central Government.

The Board consists of a Chairperson and such number of other Members as the Central Government notifies. Section 19 requires that Members have specialised expertise in data governance, law, information technology, or the digital economy. At least one Member must be an expert in law. The selection process for the Chairperson involves a Search-cum-Selection Committee chaired by the Cabinet Secretary, as specified in Rule 17.

Members are appointed for a 2-year term and are eligible for reappointment. Under Rule 18, the Chairperson receives a salary of ₹4.5 lakh per month and Members receive ₹4 lakh per month. No provision is made for house or car allowances. Members are deemed public servants under Section 25, which means they are subject to anti-corruption laws and official conduct standards.

Section 21 provides safeguards against arbitrary removal. A Member can be disqualified if they are insolvent, convicted of an offence, incapable of performing duties, have a financial interest that conflicts with their role, or have abused their position. However, no Member can be removed without being given a hearing — a basic procedural protection.

Section 22 imposes a 1-year cooling-off period after a Member's term ends, during which they cannot accept employment with any Data Fiduciary. This prevents the revolving-door problem where regulators move directly into roles with the entities they were overseeing.

The Board is designed to function as a digital office. Section 23 provides that proceedings are conducted digitally. One-third of Members constitute a quorum, decisions are taken by majority vote, and the Chairperson has a casting vote in the event of a tie. Rules 19 and 20 further specify that inquiries must be completed within 6 months, extendable by 3 months, and that the Board must adopt digital office functioning throughout its operations.

Section 27 defines four pathways through which the Board takes action. First, when a Data Fiduciary notifies the Board of a personal data breach, the Board can direct urgent remedial measures, conduct an inquiry, and impose penalties. Second, when a Data Principal files a complaint about a violation of their rights, the Board can inquire and penalise. Third, when a complaint is filed regarding a Consent Manager, the Board can inquire and penalise. Fourth, when the Central Government makes a reference to the Board, the Board can inquire and penalise.

After any inquiry, the Board may issue binding directions under Section 27(2), but only after giving the party a hearing. This ensures that no penalty or direction is imposed without the affected party having an opportunity to present their case.

Section 28 sets out the Board's procedural framework. The Board first determines whether there are sufficient grounds to proceed with a complaint or breach notification. If no sufficient grounds exist, the Board closes the matter. If grounds exist, the Board proceeds with an inquiry following the principles of natural justice — which means fair hearing, no bias, and reasoned decisions.

The Board has civil court powers for the purposes of its inquiries. It can summon and examine persons, require the production of documents, and receive evidence. However, Section 28 includes an important limitation: the Board shall not prevent access to any Data Fiduciary's premises or seize any equipment in a manner that would affect the Data Fiduciary's operations. This reflects a deliberate legislative choice to avoid the disruptive raid-and-seize approach seen in some other regulatory regimes.

The Board may pass interim orders during the course of an inquiry — for example, directing a Data Fiduciary to take immediate steps to contain a breach while the full inquiry continues.

False or frivolous complaints carry consequences. Section 28 empowers the Board to warn a complainant or impose costs if it finds that a complaint was false or frivolous. This discourages misuse of the complaint mechanism.

Section 29 provides the right of appeal. Any person aggrieved by a decision or direction of the Data Protection Board may appeal to the Appellate Tribunal — which is the Telecom Disputes Settlement and Appellate Tribunal (TDSAT), a body established under the TRAI Act 1997 that has been given jurisdiction over DPDP matters.

The appeal must be filed within 60 days of the Board's decision. The Tribunal may extend this deadline if it is satisfied that there was sufficient cause for the delay. Once an appeal is filed, the Tribunal has the power to confirm, modify, or set aside the Board's decision. The Tribunal must dispose of the appeal within 6 months.

Rule 22 specifies that appeals are filed digitally. The filing fee is determined per the TRAI Act and may be waived by the Tribunal. Payment is accepted via UPI. The Tribunal is guided by the principles of natural justice — meaning the same fairness standards that apply at the Board level also apply on appeal.

From the Tribunal's decision, a further appeal lies to the Supreme Court of India. This creates a three-tier structure: Board (first instance) → TDSAT (first appeal) → Supreme Court (final appeal).

Section 30 provides that any order of the Tribunal is executable as if it were a decree of a civil court. This means that if a party refuses to comply with a Tribunal order, enforcement mechanisms available for civil court decrees — including attachment and execution proceedings — can be used.

Section 31 introduces an alternative to the adversarial process: the Board may direct parties to attempt mediation at any stage of proceedings. This allows disputes to be resolved through negotiation rather than formal adjudication, potentially saving time and cost for all parties.

Section 32 creates a mechanism for resolving enforcement matters without a full adjudication. At any stage of proceedings before the Board, the person against whom proceedings have been initiated may offer a voluntary undertaking. This is, in practical terms, a compliance agreement — a formal promise to the Board that the party will take (or refrain from) specific actions.

The undertaking can include commitments to take particular corrective actions, to refrain from certain conduct, or to publicise the undertaking itself. The Board has discretion to accept or reject the undertaking — it is not obligated to accept one.

If the Board accepts the undertaking, it has a powerful consequence: further proceedings on the matter are barred. The case is effectively closed, and the Board cannot continue to pursue penalties for the same conduct. This gives Data Fiduciaries an incentive to offer meaningful corrective commitments early in the process, as it provides certainty and avoids the risk of penalty proceedings.

However, breaching an accepted voluntary undertaking carries serious consequences. A breach of the undertaking is deemed to be a breach of the Act itself. This means the Board can initiate fresh proceedings, and the penalty for the breach is the penalty that would have applied to the original violation. The undertaking mechanism is therefore not a way to escape liability — it is a way to resolve it through action rather than payment, with a penalty backstop if the commitment is not honoured.

Section 33(1) provides that when the Board finds a significant breach of the Act, it may impose a penalty as specified in the Schedule, but only after giving the person a hearing. The word "significant" is important — it signals that the Board has discretion to assess the seriousness of a breach before imposing penalties.

The Schedule to the Act sets out seven categories of breach and their maximum penalties. These are upper limits — the Board determines the actual amount based on the circumstances of each case. The penalty table is as follows:

Breach 1: Failure to take reasonable security safeguards to prevent a personal data breach, as required by Section 8(5) — penalty up to ₹250 crore. This is the highest penalty in the Act. If a data breach occurs because an organisation did not implement basic security measures, this is the provision that applies.

Breach 2: Failure to notify the Board and affected Data Principals of a personal data breach, as required by Section 8(6) — penalty up to ₹200 crore. Knowing about a breach and failing to report it is treated almost as seriously as failing to prevent it.

Breach 3: Breach of obligations relating to children's data under Section 9 — penalty up to ₹200 crore. This covers failures to obtain verifiable parental consent, processing children's data in ways that cause harm, and related violations.

Breach 4: Breach of additional obligations that apply to Significant Data Fiduciaries under Section 10 — penalty up to ₹150 crore. These include failing to appoint a Data Protection Officer, failing to conduct Data Protection Impact Assessments, or failing to conduct periodic audits.

Breach 5: Breach of Data Principal duties under Section 15 — penalty up to ₹10,000. This applies to individuals, not organisations. If a Data Principal files a false or frivolous complaint, provides false information while exercising their rights, or suppresses material information, they face this penalty.

Breach 6: Breach of a voluntary undertaking accepted under Section 32 — penalty up to the amount that would have been applicable for the original breach. If an organisation promised corrective action to avoid a ₹250 crore penalty and then failed to follow through, the full original penalty becomes applicable.

Breach 7: Any other breach of the Act or Rules not covered above — penalty up to ₹50 crore. This is the catch-all category.

Section 33(2) lists seven factors the Board must consider when determining the actual penalty amount. These are: (a) the nature, gravity, and duration of the breach; (b) the type and nature of personal data affected; (c) whether the breach is repetitive in nature; (d) any gain made or loss avoided as a result of the breach; (e) what mitigation actions the person took after the breach; (f) proportionality and effectiveness of the penalty as a deterrent; and (g) the likely impact of the penalty on the person. These factors mean the Board does not automatically impose the maximum — it must weigh the circumstances of each case.

Section 34 directs that all penalties collected under the Act are credited to the Consolidated Fund of India. Section 42 gives the Central Government power to amend the Schedule by notification, but the amended penalty for any breach cannot exceed twice the amount originally specified in the Schedule. This means the ₹250 crore maximum for security safeguard failures could, by future government notification, increase to a maximum of ₹500 crore.

Section 37 introduces a consequence that goes beyond financial penalties. If the Data Protection Board has penalised a Data Fiduciary on two or more occasions, the Board may advise the Central Government to direct any intermediary to block public access to that Data Fiduciary's platform or services.

This is not an automatic process. The Board advises, and the Central Government decides whether to act on that advice. But the provision signals that repeat offenders face a potential business-ending consequence — not just fines, but the loss of ability to reach users in India.

The threshold is two or more penalties, not two or more complaints. This means the Board must have completed proceedings and actually imposed penalties at least twice before this power becomes available. A Data Fiduciary that resolves matters through voluntary undertakings, or that prevails in proceedings, would not trigger this provision.

For organisations that operate digital platforms or online services in India, this is the provision that carries the most operational risk. A financial penalty, even a large one, can be absorbed or appealed. A blocking order removes the ability to operate entirely.

Section 38 establishes the supremacy clause. The DPDP Act is "in addition to" other laws — meaning it does not replace existing legislation. However, if there is a conflict between the DPDP Act and any other law in force, the DPDP Act prevails. This is a critical provision for compliance planning. Wherever another law sets a lower standard for data protection, the DPDP Act's higher standard applies.

Section 39 removes civil court jurisdiction for any matter that the Data Protection Board is empowered to determine. No civil court can entertain any suit or proceeding in respect of any matter that the Board has jurisdiction over. This channels all data protection disputes through the Board → TDSAT → Supreme Court pathway and prevents parallel litigation in civil courts.

Section 35 provides good faith protection for the Central Government, the Board, the Chairperson, Members, officers, and employees. No suit or legal proceeding can be brought against them for anything done in good faith under the Act. This protects regulators from personal liability when they exercise their powers reasonably.

Section 36 gives the Central Government the power to call for information from the Board, Data Fiduciaries, and intermediaries. Rule 23 specifies the purposes for which the government may exercise this power: matters relating to sovereignty or security, performing functions under any law, and assessing whether Data Fiduciaries should be designated as Significant Data Fiduciaries. Rule 23 also includes a secrecy provision: if the government determines that disclosing the fact of the information request would prejudice sovereignty or security, the Data Fiduciary must not reveal the request to anyone without the government's permission.

Section 43 gives the Central Government a power to remove difficulties in implementing the Act, exercisable within three years of the Act's commencement. This is a standard Indian legislative provision that allows the government to issue orders resolving ambiguities or practical obstacles that arise during the initial implementation period.

Section 40 grants rulemaking power across 26 different matters specified in the Act. Section 41 requires that all rules and notifications made under the Act be laid before Parliament for 30 days, during which Parliament may modify or annul them. This provides democratic oversight of the delegated legislation.

Section 44 amends three existing laws to align them with the new data protection framework. These are not minor housekeeping changes — they fundamentally shift where data protection law lives in the Indian legal system.

First, the TRAI Act 1997 is amended to give the Telecom Disputes Settlement and Appellate Tribunal (TDSAT) jurisdiction over appeals from the Data Protection Board. TDSAT already handles telecom-related disputes and has established procedures for complex technical matters. By routing DPDP appeals through TDSAT, the Act leverages an existing institution rather than creating a new appellate body.

Second — and this is the most significant change — the Information Technology Act 2000 is amended in two critical ways. Section 43A of the IT Act, which required body corporates to pay compensation for negligent handling of sensitive personal data, is omitted entirely. Additionally, Section 87(2)(ob) of the IT Act, which gave the government power to make rules regarding sensitive personal data or information (the basis for the SPDI Rules 2011), is also omitted. These deletions mean that the DPDP Act is now the sole, comprehensive law governing personal data protection in India. The IT Act's previous data protection provisions — and the rules made under them — no longer have statutory backing.

Third, the Right to Information Act 2005 is amended. Section 8(1)(j) of the RTI Act, which previously provided a complex exemption for personal information held by public authorities, is simplified. The previous version required a balancing test between the right to information and the individual's right to privacy. The amended version streamlines this exemption to align with the DPDP Act's framework.

For organisations that previously relied on the IT Act's Section 43A or the SPDI Rules for their data protection compliance framework, this change is decisive. Those provisions are gone. Compliance now means compliance with the DPDP Act and Rules.