Data Fiduciary Liability For Inaccurate Consent Records : When You Cannot Prove When, How, Or Why You Collected The Data

Introduction : The Digital Personal Data Protection Act, 2023 (the "DPDP Act"), changes how India approaches personal data by establishing one primary principle: consent. However, what is not known by many is the fact that the statute requires that not only is consent obtained but that the data fiduciary can explain how consent has been obtained and from where the data was obtained. Section 6(10) places the responsibility on the data fiduciary to show that a legally valid notice was issued and consent was obtained according to the Act. This changes the focus from "whether consent has been given by the data principal" to "whether the organization can prove when and how the consent was provided.

This is a larger operational issue than the consent criterion itself for the majority of Indian businesses. "Consent pop ups," "cookie notification," and "checkboxes for terms of service" are things we see all around us. In contrast, there is no evidence of the existence of auditable, timestamped, purpose-driven and versioned records of all consent events. This blog analyzes situations in which a data fiduciary will be unable to provide such proof, pinpoints the failure points in logs, version control, and bundled with withdrawal; explains how to present this evidence to government officials, and provides a practical checklist for maintaining records.

Legal Provisions

A. Notice as the Foundation for Provable Consent

According to Section 5 of the Act, a data fiduciary is required to inform the data principal of any information they want to collect from the data principal before receiving the consent. Notice must include a detailed description of personal data they are collecting, the purpose of this information, and methods the data principal can use to withdraw the consent or raise any complaints. Section 6(10) makes it mandatory to provide evidence that a notice was sent and consent was obtained in accordance with the law. This means that a data fiduciary cannot fulfill evidentiary requirements only by providing a consent log; they have to provide a proof that refers to the relevant version of the notice.

B. The Consent Standard and the Burden of Proof

Consent must be provided in line with the requirements set out in Section 6(1) and must be ‘free, specific, informed, unconditional, and unequivocal’ as indicated by some ‘positive act’ on the part of the data owner and must limit itself to the information required for the particular purpose. As stated by Section 6(2), to the extent of any violations of the provisions of the Act, such part of the consent is ineffective. By virtue of Sections 6(4) and 6(5), data owners are entitled to withdraw their consent at any time, and such withdrawal must be as simple as providing the consent, with all consequences of the withdrawal to be sound by the data owner not affecting validity of processing before the withdrawal. As per Section 6(10), the issue is that where giving consent is the basis of processing, it is the data fiduciary’s responsibility to prove in the relevant proceedings that the notice was provided and consent was given in accordance with the provisions of the Act.

C. General Obligations of the Data Fiduciary

Section 8 creates expansive duties for the data fiduciary. Amongst others, it includes ensuring completeness, accuracy and consistency of personal data in cases where it is likely to be used in the decision made about the data principal (i.e. person whose data is being processed), providing reasonable security measures and ensuring that the processing stops and the data is deleted when the purpose for which it has been collected is not met and storing it is not required for other purposes as per the relevant law. If we read these provisions together with Section 6(10), this means that the fiduciary must ensure that its records properly show that the consent was given and that the documents and data stay coherent and accurate.

D. The DPDP Rules, 2025: Consent Managers and Logging Standards

The rules set out in the 2025 Digital Personal Data Protection Rules that became effective on 13 November 2025 have provided for the fulfilment of such responsibilities. Consent Managers (individuals who are registered intermediaries through whom a Data Principal can provide, manage, revoke or withdraw consent) must keep records of any and all consents, notifications as well as data-sharing activities for at least seven years, and also keep all logs and records regarding consent activities in accordance with data-sharing rules in general. In reference to their obligations, important Data Fiduciaries will also have to comply with the same requirements that include maintaining a so-called consent ledger or a log of activities necessary for proof of compliance with section 6(10). While in this instance the requirements for retention and auditing proof follow the requirements imposed on Consent Managers, it is not difficult to draw conclusions about the relation between the mentioned requirements and compliance expectations set for data fiduciaries generally.

E. Penalties for Non-Compliance

Section 33 grants the Board of Data Protection the authority to impose a fine based on an investigation, in accordance with the schedule that categorizes fines by type of offense. A penalty of up to Rs. 250 crore is imposed for security failures and a fine of up to Rs. 200 crore for failing to report a breach of data. The rest of the cases are classified as violations of other rules under the Act and can incur an additional fine of up to Rs. 50 crore. In the failure of proof under Section 6(10), the fine would also be levied under the provisions of the rest of provision; however, it can correspond with violation of other cases as unauthorized processing of data without proven consent also means unauthorized processing resulting in penalties under various types of infringements due to a single breach of the evidentiary requirement.

Legal Analysis

A. What "Cannot Prove" Actually Means

Thanks to Section 6(10), three different questions around consent are collapsed into a single obligation that the applicant has to prove: when consent was obtained, how it was obtained, and for which purpose. The fiduciary may fail on any one of these requirements even when it possesses a document in the form of consent log that, on the face of it, looks valid. While important, having a document without a timestamp does not establish that consent was obtained before the processing of data because it might lead to difficulties if a new purpose or category of data is introduced and waivers have to be produced subsequently. In the same way, having a record without information on the actual mechanism of obtaining consent (as in, which button was clicked) does not enable one to determine how consent was obtained. Having a record without a particular purpose attached is sufficient to make it impossible to establish what exactly the data subject has agreed to.

B. Logs as the Evidentiary Backbone

A valid consent record should do more than just register that the user clicked "accept." In order to meet the requirements of Section 6(10), it should include at least a unique identifier for the data subject, the exact date and time of the consent event, the particular version of the notice ingested, information about the content and purposes of the data involved, and the information regarding the action taken. If a consent manager is employed, its identifier should be stored as well, as the law considers the 7-year record of the consent manager to be another source for the truth. An entry that consists of the Boolean expression "consent = true" does not provide any background information and will not hold up in front of the Board, as there is no evidence of how, when, and why it was registered.

C. Version Control: The Silent Failure Point

Privacy statements and policies have evolved. When an organization makes alterations to its privacy statement it must prove what version of the privacy statement was seen by the person at the time when the consent was originally given. It would be failing to comply with Section 6(10) if the organization was unable to prove that the consent given was informed consent. In most cases the organization is guilty of this failure because it states that it has been version controlling the policy but has sometimes failed to do the same with consent records. Therefore consent obtained in year one and based on a privacy notice with much smaller purposing could not be used for processing carried out under a broader privacy notice which was implemented three years later.

D. Bundled Consent: A Record That Proves the Wrong Thing

Section 6(1) states that consent must be limited and specific to whatever is deemed necessary for the specific goal in mind. Furthermore, as shown in the illustration in Section 6, one can see that if one particular action of consent serves at the same time two purposes, one of which is truly necessary and the other unrelated, such as getting the contacts in the telemedicine application, the consent shall be regarded as limited to what was really necessary for the situation. Therefore, even though there exists a thorough record of this “consent,” which contains time of the approval and a click that proves consent, this record does not meet requirement of Section 6(10) in the sense that this log provides consent for a "bundle" of purposes without specifying whether the consent was given for each purpose contained in that bundle. The issue here is that there is a record but it documents consent in a form that shall be treated as invalid according to the Act because it contains too much. Therefore, it should be emphasized that segmented consent capture is what makes the consent record legally acceptable according to the law.

E. Withdrawal: The Same Problem in Reverse

According to Section 6(4), it is as simple to withdraw consent as it is to give consent and such withdrawal must result in compliance with Section 8 (combined with the eraser provisions of this Act). If a fiduciary has carefully logged the giving of consent, but has not done so to the same extent when it comes to the withdrawal process as well as when and how processing was stopped, then it is also confronted with another evidentiary gap. The key question in a Board process is whether consent was given in the first place, and whether the fiduciary then followed the requirements with regard to withdrawals stipulated in the Act. The answer to that question is made more difficult by having to demonstrate compliance with the prohibition on processing in every system and place where personal data is used.

F. How Evidence Should Be Presented to the Regulator

The Indian Data Protection Board has been meant to be a digital-first body that is semi-judicial in nature. The phrasing seen in Section 6(10) mentioning that the fiduciary will be "obliged to prove" indicates that the Board is going to look for documentary and system-generated proof instead of verbal assurances and policy statements. For an individual complaint, it is required that a fiduciary should present a timeline that can be reconstructed: notice version served, consent event with time and method of consent provided, any additional purposes later on, and the withdrawal event stating when it was made. The most convincing evidence is when the logs were saved in a form that cannot be tampered with so as to allow the Board not to trust any records that could have potentially been modified. In cases where a Consent Manager is used, it is required to compare one's own log with the independent records of the Consent Manager from the past seven years; the fact that the two are consistent in each other will strengthen the evidence provided, while inconsistency will be read unfavorably.

Relevant Case Law and Comparative Authority

Justice K.S. Puttaswamy (Retd.) v. Union of India, (2017) 10 SCC 1: The Supreme Court's acknowledgement of privacy of information and privacy of the self as aspects of a privacy right conferred by Article 21 forms the constitutionality foundation on which the DPDP Act's architecture of consent. The importance given to the autonomy of individuals in the use of their personal data results in consent being seen as a dynamic and verifiable relationship, rather than a mere form of documentation required under Section 6(10) regarding the burden of proof.

Practical Implications

The practical implication of Section 6 (10) is that compliance with consent cannot be determined by evaluating the consent interface alone; it must be determined by whether backend systems are able to recreate individual evidence bases for any data subject who files a complaint. This has implications that go beyond penalties: in the context of M&A diligence, the failure to provide uncontroversial and verifiable consent can be interpreted as a significant liability; in the context of Board investigations, the presence of gaps in the evidence puts the burden of proof onto the fiduciary; and in the normal course of business, a company that cannot explain why it received consent cannot defend the activity in the event of a complaint.

Conclusion

• The primary point that can be derived from the knowledge of Clause 6(10) is that the consent under DPDP act is not just something an organization obtains, but it is also something that it needs to maintain for long as the situation necessitates proving it to a particular data principal, notice version and purpose even after several years. Organizations that consider consent capture to be a one-time user experience choreography instead of a long-term recordkeeping practice covering aspects like version control, purpose-segmented tracking, etc., and drift away from this practice due to limit of time, might not be able to satisfy the requirements even though their initial records might be correct and the overarching practices might seem okay. Below is a checklist that mentions the minimum expectations from a fiduciary.

• A log of consent events which notes the date and time consent was provided, separately from when the account or other relationship was created.

• A unique link exists between each data principal consent event and the specific version and language of the consent notice seen.

• Consent flags by purpose rather than a single blanket, 'accept all,' flag, which ensures proof of consent.

• The precise affirmative act which was undertaken for the obtaining of consent (e.g., button pressed, checkbox checked, OTP verified), which shows that the act was active and not the default option.

• A record of any Consent Manager ID used and cross-checked with the fiduciary's internal registration.

• A record of withdrawal that notes the date the withdrawal was called for and the date of completion of processing within every internal system and externals.

• The storage of withdrawal and consent logs as append-only or tamper-evident, to ensure its authenticity if challenged.

• Periodic internal reconciliation between the active consent state recorded in the log and the personal data actually being processed in production systems.

• A designated internal owner, such as the Data Protection Officer for Significant Data Fiduciaries, responsible for sign-off on the consent recordkeeping framework and for producing records in response to a grievance or Board inquiry.

Author: Vinayak Garg in case of any queries please contact/write back to us via email to content@khuranaandkhurana.com or at  Khurana & Khurana, Advocates and IP Attorney

Endnotes / References

1. Digital Personal Data Protection Act, 2023, s. 5

2. Digital Personal Data Protection Act, 2023, s. 6(1)

3. Digital Personal Data Protection Act, 2023, s. 6(2), 6(4), 6(5)

4. Digital Personal Data Protection Act, 2023, s. 6(10)

5. Digital Personal Data Protection Act, 2023, s. 8 (India).

6. Digital Personal Data Protection Rules, 2025, notified 13 November 2025, First Schedule, Part A and Part B

7. Digital Personal Data Protection Act, 2023, s. 33 and Schedule

8. Justice K.S. Puttaswamy (Retd.) v. Union of India, (2017) 10 SCC 1 (Supreme Court of India).

9. Planet49 GmbH v. Verbraucherzentrale Bundesverband, Case C-673/17, Judgment of 1 October 2019 (Court of Justice of the European Union).

10. General Data Protection Regulation (EU) 2016/679, art. 7(1).