You may only process personal data for a lawful purpose, and only with consent or under one of the specific legitimate uses the Act allows. Those uses are narrow and named, covering things like employment, medical emergencies and legal obligations. There is no general "legitimate interest" basis of the kind GDPR provides, which catches businesses that have built their processing around it. Every activity in your business needs a basis you can name and defend, and activities that have no basis have to stop or be re-consented.
Before collecting anything you must give a notice that stands on its own, understandable without reading anything else you publish. It has to itemise every field of personal data you are collecting and state the specific purpose for each, along with a link to withdraw consent, exercise rights and complain to the Board. It must be available in English or any of the 22 languages in the Eighth Schedule, at the person's choice. A privacy policy buried inside your terms of service does not satisfy any of this, which is how most businesses currently fail it.
Consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action. You cannot bundle five purposes into one tick, and you cannot collect more data than the stated purpose actually requires. Withdrawal has to be as easy as giving consent was, and once someone withdraws you must stop processing and make your vendors stop too. Anything in a consent that infringes the Act is invalid to that extent, so an over-broad consent does not protect you.
Where consent is your basis and a question arises in a proceeding, the burden of proof sits entirely with you. You must be able to show both the notice that was given and the consent that followed it. Most consent systems record the click and the timestamp but not the version of the notice the person actually saw, which proves nothing about what they agreed to. Without that link between notice and consent, a consent record is an assertion rather than evidence.
This is not a risk-based judgement call. The Rules specify the minimum: encryption, obfuscation, masking or tokenisation; access control on the systems holding personal data; logs, monitoring and review to detect unauthorised access; backups for continuity; and retention of logs and personal data for one year. You must also put security obligations into your processor contracts. This obligation carries the largest penalty in the Act, up to ₹250 crore, which makes it the first place any assessment should look.
Alongside the technical controls, you must show the policies, governance and trained people that make compliance work in practice. This is the obligation that turns a set of tools into a defensible position. It is evidenced through documentation, training completion records, review cadences and named ownership, not through the technology itself. It is also what the Board would look at when deciding whether your failure was systemic or a lapse.
On becoming aware of a breach you must intimate every affected person individually, without delay, telling them what happened, what it means for them, what you are doing about it and what they can do to protect themselves. The Board gets an immediate description and then a full report within 72 hours, covering the facts, the cause, the remedial measures and what you told the affected people. There is no severity threshold, so a small breach is as notifiable as a large one. Separately, CERT-In already requires reporting of data breaches within six hours of noticing them, and that duty applies today.
People can request a summary of the data you hold, the processing you carry out, and the identity of every other business and processor you shared it with. They can require you to correct, complete, update or erase their data, and you must act on that request. They can also nominate another individual to exercise these rights if they die or become incapacitated. You have to publish how requests are made and what details you need to identify the person, so a working, published process is itself part of the obligation.
You must provide a readily available grievance mechanism covering any act or omission relating to someone's personal data or their exercise of rights, and respond within the period the Rules set. The mechanism has to be prominently published, and you must implement the technical and organisational measures that let you actually meet the response window. Done properly this protects you, because a person is required to exhaust your grievance process before approaching the Board. A weak mechanism removes that protection and sends complaints straight to the regulator.
Data must be erased once the purpose is served or consent is withdrawn, whichever comes first, and you must cause your processors to erase their copies too. For large e-commerce, online gaming and social media platforms above the user thresholds the Rules set, data must be erased after three years of inactivity, and the person must be warned at least 48 hours before it happens. Separately, the Rules require a minimum one-year retention of personal data, traffic data and logs. Reconciling an erasure duty with a retention floor, on top of your tax and sector obligations, is where most businesses get stuck.
Where personal data is likely to be used to make a decision that affects someone, or disclosed to another business, you must ensure it is complete, accurate and consistent. This is narrower than a general data quality duty, and that scoping matters: it bites precisely where the consequences for the individual are real, such as credit decisions, eligibility checks, employment screening and pricing. If your systems hold three different versions of a customer record and a decision is made on the wrong one, the obligation has been breached.
Anyone under 18 is a child, with no lower threshold. You need verifiable parental consent before processing any child's data, and you must carry out due diligence that the person claiming to be the parent is an identifiable adult. Tracking, behavioural monitoring and targeted advertising directed at children are prohibited outright, with no consent available to permit them. You must also not undertake any processing likely to cause a detrimental effect on a child's wellbeing, whatever consent you hold. Comparable rules apply to lawful guardians of persons with disability, where the guardian must be verified as court or authority appointed. Penalties reach ₹200 crore.
You remain responsible for compliance irrespective of any agreement to the contrary, so a contract can allocate cost between you and a vendor but cannot move the legal liability. You must have a valid contract in place before engaging any processor for activity related to offering goods or services. That contract has to carry the security obligations down, and you must be able to make the processor cease processing on withdrawal and erase on instruction. If your cloud provider, CRM or payment gateway mishandles data you gave them, the Board looks at you.
Personal data may be transferred outside India, subject to any requirements the Government specifies, and no country restrictions have been notified so far. The binding constraints today come from elsewhere: RBI requires payment system data to be stored in India, DoT requires subscriber data and call records here, IRDAI imposes its own rules, and health data under the national health ecosystem must remain in India. Businesses designated as Significant Data Fiduciaries may also face localisation on specified categories. If you run on a foreign cloud, your sector rather than the Act usually decides what is allowed.
The Government may designate a business or class of businesses as a Significant Data Fiduciary, based on the volume and sensitivity of data processed, the risk to people's rights, and considerations of state security and public order. Designation adds an India-based Data Protection Officer answerable to your board, an independent data auditor, an annual Data Protection Impact Assessment and audit reported to the Board, and a duty to verify that your algorithmic systems do not put people's rights at risk. No designations have been made yet, which means this is a preparation question rather than a current duty, and preparing quietly beats reacting publicly.
The Act does not only govern data you collect from now on. Everyone who gave you consent before the Act commenced must be given a fresh notice, describing the personal data you hold, the purpose you process it for, how to exercise their rights and how to complain to the Board. You may continue processing until they withdraw consent, but the notice itself is not optional and must be given as soon as reasonably practicable. For a business with a large existing customer base this is a substantial one-time project, and almost nobody has budgeted for it.
The Central Government may require you to furnish information for specified purposes at any time, and directions issued by the Data Protection Board are binding on you. In some cases you may be directed not to disclose that a request was made. The Board has the powers of a civil court in relation to summoning people, taking evidence and inspecting records. Being able to retrieve your notices, consent records, logs and evidence quickly is part of compliance, not an administrative afterthought.
You must prominently publish the business contact details of a person who can answer questions about how you handle personal data, on your website or app. Those details must also be repeated in every response you send to someone exercising their rights, which is a system behaviour rather than a web page and is routinely missed. If you are designated a Significant Data Fiduciary, this person must be your Data Protection Officer. It is one of the few obligations anyone, including a regulator, can verify from outside your business in seconds.
Not yet, and we will not pretend otherwise. The penalty provisions have not commenced, and the Data Protection Board has no members appointed on the public record. Full enforcement arrives in May 2027. But two things already bind you today: CERT-In requires breach reporting within six hours, and the SPDI Rules of 2011 still apply because the provision repealing them has not commenced. Most businesses are already non-compliant with both.
Because most of DPDP is an engineering problem. Notices, consent records, erasure, rights portals, encryption and logging are all built, not advised. We have delivered privacy compliance work under GDPR in Europe and HIPAA in the United States, two of the strictest regimes in the world. The legal opinions, contract drafting and independent audit come from our partner law and accounting firms, who are independent of the team that builds the controls, as the Act requires for audit.
You can, and many will. Two things make it expensive. The work does not shrink while you wait, and the supply of people who can do it does not grow. Every business facing the same fixed date will be looking for the same help in the same months. The other cost is technical: consent and erasure designed into a system are features, and retrofitted into a live one they are rebuilds.
Yes. The Act sets no revenue or headcount threshold. A ten-person company with a customer database has the same core obligations as a listed enterprise. The Government has the power to exempt certain classes of business, including startups, but no such exemption has been notified. Planning on the assumption that one will arrive is a risk, not a strategy.
A fair question to ask a firm you are hiring to protect data. We work from the minimum access needed, prefer metadata and schema over record-level data wherever discovery allows, and sign the same processing terms we would advise you to require from any vendor. If we hold anything of yours, it is returned or deleted at the end of the engagement, with confirmation in writing.
It puts you well ahead, but not across the line. Several DPDP requirements have no GDPR equivalent, including re-notifying customers who consented before the Act, the specific form the notice must take, the absence of any severity threshold for breach notification, and the duties the Act places on individuals. GDPR also has a legitimate interest basis that DPDP does not, so processing you rely on today may have no home under this Act.
No, though it helps. ISO 27001 is a security management standard. DPDP is a data protection law with obligations ISO does not touch, including notice, consent, erasure, rights requests and breach reporting timelines. Your ISMS gives you a strong evidence base for the security safeguards, which is one obligation of eighteen. There is also no DPDP certification of any kind, so no certificate makes you compliant.
Parts of it, yes. Policy drafting and training are achievable in house if you have the capacity. The harder parts are data discovery across systems nobody has mapped, building consent records that hold up as evidence, and reconciling retention rules that point in opposite directions. Most businesses that start alone come back for those three.
No. The Act makes you responsible for your processors irrespective of any agreement to the contrary. A contract can allocate cost between you and a vendor, but it cannot move the legal liability. If your cloud provider or CRM mishandles data you gave them, the Board looks at you.
Both. Employee records, payroll, attendance, CCTV and biometric attendance are all personal data. The Act does allow processing for employment purposes without separate consent, but that only removes the consent requirement. Notice, security, retention, rights and breach obligations all still apply to your workforce data exactly as they do to customer data.
Any entity processing personal data in India is in scope. So is an entity outside India that offers goods or services to people in India, even with no office, staff or subsidiary here. Group companies are separate persons under the Act, so sharing data between your Indian and overseas entities is a disclosure, not an internal transfer, and needs to be papered accordingly.
Under DPDP itself, generally yes. The Act permits transfer abroad subject to conditions the Government may set, and no country restrictions have been notified. The real constraints come from your sector. RBI requires payment data in India, IRDAI and DoT impose their own rules, and health data under the national health ecosystem must stay in India. Your sector, not the Act, usually decides this.
They have to be given a fresh notice. The Act requires you to go back to everyone who consented before it commenced, tell them what data you hold, why you process it and how to exercise their rights. For a business with a large customer base this is a project on its own, and almost nobody has budgeted for it. It also has to be done as soon as reasonably practicable, not at the deadline.
No, and you should not try. The assessment produces a sequenced plan, and the sequence matters. Discovery comes first because nothing else can be scoped without it. Security safeguards come early because they carry the largest penalty. Consent and rights work follows once you know what data you hold. Retention and vendor work can run in parallel.
Most of it runs alongside normal operations. Discovery is read-only and touches nothing. Policy, contract and training work happens in parallel. The parts that change systems, consent capture, rights handling and erasure, are built and tested before anything goes live. The sequence exists precisely so that nothing is rebuilt under pressure.
You need one accountable owner and access to the people who know your systems. In practice that is a few hours a week from a technical lead during discovery, decisions from whoever owns legal or finance, and a named point of contact throughout. We do not run an engagement that requires your team to become privacy specialists.
It depends entirely on how much data you hold and how many systems hold it. A business with one product and a single database is a very different exercise from one with fifteen years of acquisitions and no data map. We will not quote a number without looking, and any firm that quotes before seeing your estate is guessing. The assessment produces a costed plan, and you decide what to do with it.
Only if the Government designates you a Significant Data Fiduciary, and no designations have been made yet. If it does, the role has to be an individual based in India who answers to your board, which is not something an outside firm can be for you. Every business, designated or not, must publish a contact who can answer questions about how it handles personal data. That role we can fill.
Almost certainly not. A Consent Manager is a specific licensed entity registered with the Data Protection Board, requiring an Indian company with at least two crore in net worth and independent certification. Registration opens in November 2026. Running your own consent system is a completely different thing and needs no registration at all.
It will. Several parts are still unwritten, including Significant Data Fiduciary designations, cross-border restrictions and the standards for consent platforms. A corrigendum has already amended the Rules once. Nothing we build depends on the unsettled parts, and tracking changes is part of our ongoing service, not a separate charge.
Legally, the obligations sit with you and cannot be transferred to a vendor, which is what the Act says about every processor. What we are accountable for is the work we deliver: that the controls we build match what the Rules require, that the evidence is documented, and that we tell you plainly where the law is unsettled rather than guessing. Commercial terms are set out in the engagement contract.