India DPDPA 2023 compliance gap analysis: what the Act requires before rules are notified
Sienna VanceApril 29, 2026
Key takeaways
The DPDP Act 2023 received Presidential assent in August 2023 and is in force. The implementing rules have not been notified and the Data Protection Board has not been constituted as of early 2025. Organisations waiting for rules before beginning compliance work are building a compressed remediation timeline against a penalty structure of up to INR 250 crore.
DPDPA consent must be free, specific, informed, unconditional, and signified through a clear affirmative action. Bundled consent, where personal data processing terms are accepted as part of general service terms, does not satisfy this standard. Most assessed India-market organisations are using bundled consent.
Significant Data Fiduciary designation triggers additional obligations including a Data Protection Officer, Data Protection Impact Assessment requirements, and periodic audits. The criteria for designation will be specified in rules, but the Act's language indicates volume and sensitivity thresholds. Organisations near those thresholds should not wait for formal designation to begin preparing.
DPDPA cross-border transfer is permitted except to countries notified as restricted by the central government. No restricted country list has been published yet. Organisations with global data flows should map those flows now so they can assess compliance quickly once the list is published.
The most consistent technical gap in assessed organisations is the absence of functional data principal rights mechanisms: the Act grants rights to access, correction, erasure, and grievance redress, but most organisations have no implemented mechanism through which a data principal can actually exercise those rights.
TL;DR
The DPDPA 2023 exists. The enforcement machinery does not yet. That gap is temporary and organisations treating it as a compliance holiday are misreading the situation. The Act's text is specific enough to identify material compliance gaps right now, before rules are notified: consent mechanisms that do not meet the affirmative action standard, data principal rights that are described in privacy policies but not implemented as functional product features, and breach notification obligations that require detection timelines most organisations cannot meet. The time to close those gaps is before the Data Protection Board is constituted, not after.
What pre-rules DPDPA compliance looks like from the inside
A mid-sized Bengaluru SaaS company processing personal data of approximately 800,000 Indian users completed an internal DPDPA readiness review in late 2024. The review concluded that existing GDPR-aligned consent mechanisms and privacy policies covered DPDPA requirements, that the Splunk SIEM deployment handled audit logging obligations, and that no immediate action was required pending implementing rules.
External assessment found: consent collected through a single checkbox accepting terms of service that incorporated personal data processing terms, with no separate affirmative action for personal data processing. The privacy policy described data principal rights to access, correction, and erasure, but no mechanism existed in the product interface through which a user could submit any of those requests. The Splunk deployment logged security events at the system level. It did not log which personal data records were accessed by which internal users, meaning the organisation could not respond to a data principal access request with a complete record of their data or demonstrate to a regulator what data had been accessed in a breach. Cross-border data flows to US-based analytics and CRM platforms were undocumented.
The internal review was not wrong that implementing rules add specificity. It was wrong that the Act's existing text creates no obligations. Section 6 of the DPDPA specifies the consent standard in terms that are clear without rules: free, specific, informed, unconditional, and signified through a clear affirmative action. A checkbox accepting service terms does not meet that standard under the Act's existing text, regardless of what rules subsequently specify.
What the DPDP Act requires now, without implementing rules
The DPDP Act 2023 is structured in two layers. The Act itself specifies principles, rights, obligations, and penalty frameworks. Implementing rules will specify procedural details: timelines, formats, Significant Data Fiduciary designation criteria, restricted country lists for cross-border transfers, and DPBI operational procedures. Organisations often treat this structure as meaning that nothing is enforceable until rules are notified. That is incorrect.
The Act's existing text creates identifiable obligations. Section 4 restricts processing to specified purposes with consent or legitimate use. Section 6 specifies the consent standard. Sections 11 through 14 specify data principal rights. Section 8 imposes accuracy, storage limitation, and security obligations on Data Fiduciaries. Section 9 specifies children's data obligations including parental consent requirements. These provisions are in force. Their implementing detail will be specified in rules, but their substance is not contingent on rules.
The practical compliance work that can and should happen before rules are notified: mapping current consent mechanisms against Section 6's affirmative action standard, building functional data principal rights mechanisms against Sections 11 through 14, mapping cross-border data flows against the Act's transfer framework so assessment against the restricted country list can happen quickly once published, and building breach detection and notification infrastructure against the Act's notification obligation even though the timeline will be specified in rules.
Example
Section 6(1) of the DPDPA specifies that consent must be 'free, specific, informed, unconditional and unambiguous with a clear affirmative action.' Section 6(2) specifies that the request for consent must be presented 'in clear and plain language' and separately from any other information. A single checkbox accepting terms and conditions that include personal data processing terms fails on two counts: it is not a separate request for consent and it does not constitute a clear affirmative action for personal data processing specifically. This is not a rules-dependent interpretation. The Act's text is explicit. Organisations currently relying on bundled consent are non-compliant with Section 6 as written.
The children's data obligation under Section 9 is one of the most technically demanding provisions in the Act. Section 9(1) requires verifiable parental consent before processing personal data of children. 'Verifiable' is a technical requirement, not a documentation one. A checkbox confirming the user is over 18 is not verifiable parental consent. The mechanisms that constitute verifiable consent (government identity verification, payment method verification as a proxy for adult status, or other reliable verification methods) are technically complex to implement and have significant UX implications. Organisations with any possibility of child users need to begin designing this mechanism before rules specify the exact verification standard, because the implementation timeline for robust age verification is months, not weeks.
Technical control gaps found in India-market organisations assessed against DPDPA obligations
Assessment base: Vulnox assessment data, India-market organisation engagements assessed against DPDPA 2023 obligations, 2024 to 2025
Consent mechanisms that bundle personal data processing with service terms acceptance
In assessed India-market organisations, consent for personal data processing was collected through a single checkbox or click-through accepting terms of service that incorporated privacy policy terms. The consent was technically recorded. It was not a separate, specific affirmative action for personal data processing as Section 6 requires. In some cases, pre-ticked boxes were used for optional data collection categories. In others, continued use of the service was treated as implied ongoing consent. All three patterns fail the Section 6 standard without rules needing to add any further specification.
An organisation whose consent mechanism does not satisfy Section 6 has no valid legal basis for personal data processing under consent. All downstream processing based on that consent is unsupported. When the Data Protection Board is constituted and begins adjudicating complaints, consent mechanism compliance will be among the first areas examined because it is documentable: the DPBI can visit the registration flow and assess whether the consent request meets the Section 6 standard without conducting a technical audit.
Data principal rights described in privacy policies but not implemented as functional product features
Sections 11 through 14 of the DPDPA grant data principals the right to access a summary of their personal data, to correction and erasure of inaccurate or incomplete data, to grievance redress, and to nominate another person to exercise rights on their behalf. In assessed organisations, all four rights were described in privacy policies. None were implemented as functional mechanisms in the product interface. A data principal attempting to exercise any of these rights would find a policy description and no mechanism. The policy accurately described the obligation. The product did not implement it.
A data principal who cannot exercise a right described in the privacy policy has a direct complaint basis to the DPBI under Section 13. The DPBI complaint mechanism will be the first active enforcement tool available once the Board is constituted. Organisations without functional rights mechanisms are creating a direct, accessible complaint pathway. The compliance gap is not invisible: it is discoverable by any data principal who tries to use the product to exercise their rights.
Internal audit logging that covers security events but not personal data access at record level
Section 8(7) requires Data Fiduciaries to maintain accurate and complete personal data and implies logging capability sufficient to respond to data principal access requests and to scope breach notifications. In assessed organisations, SIEM deployments logged system-level security events: authentication, privilege escalation, network anomalies. They did not log which specific personal data records were accessed by which internal users during normal operations. A data principal access request under Section 11 asks for a summary of personal data processed. Without record-level access logging, the organisation cannot confirm what data was accessed when, or rule out access that should not have occurred.
Record-level access logging is not a nice-to-have in a DPDPA-compliant environment. It is the technical infrastructure that makes Section 11 access request responses accurate, makes breach scope determination possible, and makes the Data Fiduciary's security obligation under Section 8 demonstrable. A SIEM that logs security events but not personal data access is doing the right job for security operations and the wrong job for DPDPA compliance.
Cross-border data flows to analytics, CRM, and marketing platforms undocumented against the Act's transfer framework
Section 16 of the DPDPA permits cross-border transfers of personal data except to countries notified by the central government as restricted. No restricted country list has been published as of early 2025. Assessed organisations used this absence to defer cross-border transfer mapping entirely. The mapping is necessary before the list is published, not after. An organisation that has not mapped its data flows cannot assess compliance against the restricted country list within a reasonable timeframe after publication. The restricted country list, when published, will require rapid assessment. Organisations without a current data flow map cannot do that assessment quickly.
The absence of a published restricted country list is not a compliance holiday for cross-border transfer obligations. It is a window to complete the mapping that will be required the moment the list is published. Assessed organisations that have not mapped transfers to US-based analytics platforms, EU-based CRM systems, and other international data processors will face a compressed response timeline when the list appears.
Existing GDPR compliance does not translate to DPDPA compliance
Common belief
Organisations with GDPR compliance programs are well positioned for DPDPA compliance because the frameworks share foundational privacy principles. GDPR-compliant consent mechanisms, data subject rights implementations, and breach notification procedures can be adapted to DPDPA with minimal additional work.
What we found
In assessed organisations with GDPR compliance programs who believed DPDPA compliance was substantially addressed, the most consistent gap was consent mechanism compliance: GDPR-compliant consent that relied on legitimate interest for broad processing categories, with no equivalent DPDPA legal basis mapped. The second most consistent gap was the nomination right under Section 12, which no assessed organisation had implemented because it has no GDPR equivalent and was not on the GDPR-to-DPDPA mapping that compliance teams had conducted.
GDPR and DPDPA share privacy principles at a high level of abstraction. Their specific requirements diverge in ways that make GDPR compliance a partial preparation for DPDPA at best and a source of misplaced confidence at worst.
The consent divergence is the most operationally significant. GDPR permits processing under multiple legal bases including legitimate interest, contract performance, legal obligation, and explicit consent. DPDPA's legal bases are consent and defined legitimate uses. The legitimate uses under DPDPA are narrower and more specifically defined than GDPR's legitimate interest basis. An organisation that has built its processing on GDPR legitimate interest may not have a valid DPDPA legal basis for the same processing.
The consent standard also differs. GDPR requires a freely given, specific, informed, and unambiguous indication of agreement. DPDPA requires the same plus that it be unconditional, signified through a clear affirmative action, and requested separately from other information in clear and plain language. GDPR-compliant consent mechanisms often use implied consent for certain processing or rely on legitimate interest to avoid consent entirely. Neither approach maps cleanly to DPDPA.
Data principal rights under DPDPA include a nomination right (the ability to designate another person to exercise rights on one's behalf) that has no direct GDPR equivalent. The practical implementation of this right requires a mechanism that no GDPR compliance program will have built.
The penalty structure that changes the compliance calculation
DPDPA penalties reach up to INR 250 crore (approximately USD 30 million) for failure to implement reasonable security safeguards, and up to INR 200 crore for failure to notify the DPBI and affected data principals of a personal data breach
Digital Personal Data Protection Act 2023, Schedule. These penalty levels represent the maximum, with actual penalties determined by the Data Protection Board based on factors including the nature and gravity of the breach, the type of personal data affected, whether the breach was repetitive, and whether the Data Fiduciary took remedial action. The breach notification penalty is particularly significant: it applies to failure to notify, not to the breach itself, making breach detection and notification infrastructure a direct penalty risk.
Significant Data Fiduciary designation will trigger additional obligations including mandatory Data Protection Impact Assessment, periodic audits, and appointment of a Data Protection Officer
DPDP Act 2023, Section 10. Designation criteria will be specified in rules but the Act indicates they will be based on volume and sensitivity of personal data processed. Organisations near reasonable threshold estimates (millions of data principals, sensitive personal data categories) should not wait for formal designation to begin preparing the additional obligations, because the implementation timeline for these requirements is longer than the response time that will follow designation.
Section 9 children's data obligation requires verifiable parental consent before processing, with penalties up to INR 200 crore for violations
DPDP Act 2023, Section 9 and Schedule. The verifiable standard is technically demanding. Age verification mechanisms robust enough to satisfy 'verifiable' are not the same as a checkbox. Organisations with any possibility of child users who have not begun designing compliant age verification and parental consent mechanisms are accumulating technical debt against a high-penalty obligation.
Where DPDPA compliance programs consistently fail to look
The nomination right under Section 12
Section 12 grants data principals the right to nominate another individual to exercise their data rights in the event of death or incapacity. This right requires a functional mechanism: a way to register a nomination, a way for the nominated person to verify their identity and the nomination, and a process for the Data Fiduciary to respond to the nominated person rather than the data principal. No GDPR equivalent exists. No assessed organisation had built this mechanism. It will be discoverable by a DPBI complaint from a nominee attempting to exercise rights on behalf of a deceased or incapacitated data principal.
Consent withdrawal mechanisms that are as easy as consent collection
Section 6(4) requires that withdrawing consent be as easy as giving it. If consent is given through a checkbox at registration, withdrawal must be achievable through a comparable action, not through a support ticket, email request, or account deletion. In assessed organisations, consent withdrawal was described in the privacy policy as a right. The mechanism to exercise it in the product was not present or required contacting support. This is a direct Section 6(4) violation under the Act's existing text.
Processing of children's data by platforms with no age verification
Section 9 applies when a platform processes personal data of children. It does not require the platform to know it is processing children's data. The obligation attaches to the possibility of processing. Platforms with no age verification mechanism are processing data of children without verifiable parental consent if children are using the platform. The 'verifiable' standard will be specified in rules, but the obligation exists under the Act's existing text.
Grievance redress mechanism under Section 13
Section 13 requires Data Fiduciaries to establish a grievance redress mechanism and a named contact for data principal grievances. The mechanism must be functional and responsive. A privacy policy email address is not a grievance redress mechanism in the Section 13 sense. The mechanism requires a defined response process, a timeline for response, and an escalation path to the DPBI if the grievance is not resolved. In assessed organisations, the privacy policy listed a contact email. No defined response process, timeline, or escalation documentation existed.
What India-market organisations say before DPDPA gap analysis, and what assessment finds
The implementing rules have not been notified. We are waiting for rules before investing in compliance.
Root cause:The Act's existing text creates identifiable obligations that do not require rules for interpretation. Section 6's consent standard, Section 11 through 14's data principal rights, Section 9's children's data obligations, and Section 8's security and accuracy obligations are in force. The implementing rules add procedural specificity: timelines, formats, designation criteria. They do not create the underlying obligations. Organisations that wait for rules will face compressed remediation timelines against a penalty structure that is already specified in the Act.
We are GDPR compliant. DPDPA requirements are substantially covered.
Root cause:GDPR compliance addresses a different regulatory standard. The divergences that matter operationally: DPDPA's narrower legal bases compared to GDPR's legitimate interest, the affirmative action consent standard compared to GDPR's indication of agreement, the nomination right under Section 12 with no GDPR equivalent, and the children's data verifiable consent standard that is more demanding than GDPR's age verification approach in most implementations. An organisation that has mapped its GDPR compliance to DPDPA at the principle level has not assessed whether its specific implementations meet the DPDPA standard.
Our existing SIEM covers our logging and audit requirements.
Root cause:SIEM deployments log security events. DPDPA compliance requires logging that supports data principal access request responses and breach scope determination, which means record-level personal data access logging. These are different log sources serving different purposes. A SIEM that captures authentication events and network anomalies does not capture which personal data records were accessed by which internal users during normal operations. That information is needed to respond accurately to a Section 11 access request and to determine the scope of data affected in a breach notification scenario.
We do not process sensitive personal data. DPDPA risk is low for us.
Root cause:DPDPA's basic obligations apply to all personal data processing, not only sensitive personal data. Sensitive personal data triggers higher consent requirements (explicit consent specified separately) and will likely affect Significant Data Fiduciary designation thresholds. But the consent standard, data principal rights obligations, grievance redress mechanism, breach notification obligation, and children's data requirements apply to personal data generally. An organisation processing only name, email, and usage data is still subject to Section 6's consent standard, Section 11 through 14's rights obligations, and Section 9 if children may be users.
How DPDPA enforcement will develop once rules are notified
The first DPBI enforcement actions, within 12 months of Board constitution, will target consent mechanism failures and data principal rights implementation gaps, because both are directly verifiable without technical audit: a regulator can visit a product's registration flow and attempt to exercise a data principal right without internal access.
Regulators establishing enforcement authority typically begin with violations that are easy to document and difficult to contest. Consent mechanism compliance is assessable through the product interface. Data principal rights implementation is assessable by attempting to exercise a right. Both produce clear evidence without requiring internal system access. The DPBI will have limited technical audit capacity initially and will concentrate enforcement where evidence is accessible. This pattern is consistent with how GDPR enforcement developed in its first two years.
Confidence: highPublished DPBI enforcement actions within 12 months of Board constitution. If the first actions concentrate on data breach failures or Significant Data Fiduciary obligations rather than consent and rights, this prediction is wrong.The restricted country list for cross-border transfers, when published, will require a rapid assessment response that most organisations cannot complete in under 30 days because they have not mapped their cross-border data flows in advance.
Cross-border data flow mapping is not a short project for organisations with multiple international service dependencies. Analytics platforms, CRM systems, marketing automation, cloud infrastructure, and security tooling all create data flows. Organisations that have not mapped these flows will need weeks to months to complete the mapping once a restricted country list triggers the compliance question. Organisations with current mapping can assess in days. The list will be published with a compliance timeline. That timeline will be insufficient for organisations starting from no map.
Confidence: highThe restricted country list, when published, accompanied by a compliance timeline of 90 days or more, which would reduce the urgency of pre-mapping. A short timeline confirms the prediction.
The pre-rules period is the best compliance investment window, not a reason to wait
Organisations treating the absence of implementing rules as a compliance holiday are making an expensive calculation error. The rules will add procedural specificity to obligations that already exist in the Act's text. When they are notified, they will come with a compliance timeline. That timeline will be shorter than the time needed to redesign consent mechanisms, build data principal rights features, implement record-level access logging, and map cross-border data flows from a standing start. The organisations that will handle the rules notification well are the ones that have already closed the gaps identifiable from the Act's existing text. The organisations that will scramble are the ones that mistook regulatory preparation for rules-waiting.
Counterargument
The counterargument is that investing heavily in DPDPA compliance before rules are notified risks building to the wrong specification: rules might change the technical requirements in ways that require rework. This is a real risk and it is not zero. The response is to focus pre-rules investment on the obligations that are clearly specified in the Act and are unlikely to change materially in rules: the consent affirmative action standard, the data principal rights mechanism, the grievance redress requirement, and the cross-border transfer flow mapping. These are the areas where pre-rules investment has the lowest specification risk and the highest readiness payoff.
One thing to do this week
Test your consent mechanism against Section 6 of the DPDP Act. Open your product's registration or onboarding flow. Identify where personal data processing consent is collected. Ask three questions: Is the consent request presented separately from the service terms? Does it require a clear affirmative action (not a pre-ticked box, not implied by continued use)? Is the withdrawal mechanism as easy to find and use as the consent collection? If the answer to any of the three is no, you have a Section 6 gap that exists under the Act's current text, before rules, and that will be the first thing a DPBI complaint or investigation examines. Fix that first. Everything else can follow.
Further Reading
Gap Analysis
gap analysis servicesDigital Footprint
digital footprint analysisAPAC cybersecurity and privacy compliance frameworks: the complete guide
India DPDPA 2023 compliance gap analysis and what the Act requires before rules are finalisedNIST SP 800-30 Risk Assessment Guide
NIST SP 800-30 risk guideOWASP Web Security Testing Guide
OWASP security testing guideCompliance Gap Analysis Guide
compliance gap analysis guide
Frequently Asked Questions
What does the DPDP Act 2023 require now, before implementing rules are notified?
The DPDP Act 2023 is in force and its existing text creates identifiable obligations without implementing rules. Section 6 specifies the consent standard: free, specific, informed, unconditional, signified through a clear affirmative action, and requested separately from other information. Sections 11 through 14 specify data principal rights including access, correction, erasure, grievance redress, and nomination. Section 9 requires verifiable parental consent before processing children's personal data. Section 8 imposes data accuracy, security, and storage limitation obligations. Rules will add procedural specificity such as timelines and formats. They do not create the underlying obligations, which are in force now.
How does DPDPA 2023 consent differ from GDPR consent?
DPDPA Section 6 requires consent that is free, specific, informed, unconditional, and signified through a clear affirmative action, with the consent request presented separately from other information in clear and plain language. GDPR requires freely given, specific, informed, and unambiguous indication of agreement. The key DPDPA additions are the unconditional requirement and the separate presentation requirement. GDPR also permits processing under legitimate interest, legal obligation, and contract performance bases that are broader than DPDPA's defined legitimate uses. Organisations relying on GDPR legitimate interest for processing may not have a valid DPDPA legal basis for the same processing.
What are the penalties for DPDPA 2023 non-compliance?
The DPDPA Schedule specifies penalties up to INR 250 crore for failure to implement reasonable security safeguards to prevent personal data breaches. Failure to notify the Data Protection Board and affected data principals of a personal data breach carries penalties up to INR 200 crore. Children's data obligation violations carry penalties up to INR 200 crore. The Data Protection Board will determine actual penalties based on factors including the nature and gravity of the violation, the type of personal data affected, repetition, and whether remedial action was taken. The penalty structure is specified in the Act and does not require implementing rules to be operative.
What is a Significant Data Fiduciary under DPDPA and what additional obligations apply?
Section 10 of the DPDPA allows the central government to designate certain Data Fiduciaries as Significant Data Fiduciaries based on criteria to be specified in implementing rules, expected to include volume and sensitivity of personal data processed. Significant Data Fiduciary designation triggers additional obligations: appointment of a Data Protection Officer based in India, appointment of an independent data auditor, periodic Data Protection Impact Assessments, and compliance with additional standards to be specified. Organisations processing large volumes of personal data or sensitive personal data categories should not wait for formal designation to begin preparing these obligations, because the implementation timeline for a functioning DPO appointment and DPIA process is longer than the response time that will follow designation.
How does DPDPA 2023 handle cross-border data transfers?
Section 16 of the DPDPA permits cross-border transfer of personal data except to countries notified by the central government as restricted. No restricted country list has been published as of early 2025. The practical compliance requirement is to map current cross-border data flows before the list is published, so that compliance assessment can happen quickly once the list appears. Organisations with undocumented transfers to international analytics, CRM, cloud, and marketing platforms will face a compressed assessment timeline when the list is published. The absence of the list is not a reason to defer flow mapping.
What does the DPDPA nomination right require organisations to implement?
Section 12 grants data principals the right to nominate another individual to exercise their data rights in the event of death or incapacity. Implementing this right requires a functional mechanism: a way to register a nomination within the product or service, a process for the nominated person to verify their identity and the existence of the nomination, and a response process for handling rights requests from nominees rather than data principals. This right has no GDPR equivalent and no assessed organisation has built a compliant implementation. It will be the first observable compliance gap when a nominee attempts to exercise rights and finds no mechanism.
What is the most important consent mechanism change organisations need to make for DPDPA compliance?
Section 6 requires that consent be obtained through a clear affirmative action and that the consent request be presented separately from other information. Bundled consent, where personal data processing terms are accepted as part of service terms through a single checkbox or click-through, fails both requirements. The most important change is separating the personal data processing consent request from the service terms acceptance and ensuring it requires a distinct affirmative action. Section 6(4) additionally requires that withdrawal of consent be as easy as giving it, meaning a withdrawal mechanism that requires contacting support or deleting an account does not satisfy the standard.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.