You have your consent banner live. Users are clicking "Accept." Your analytics show opt-in rates. But when you open your database and ask yourself, "If the Data Protection Board requested proof that Ramesh Patel gave consent on March 14 for marketing emails, could I produce it in ten minutes?" - the answer, for most companies, is no.
Consent collection and consent record-keeping are two different problems. The first is a UX challenge. The second is a compliance and evidentiary challenge. Most organisations solve the first and ignore the second until an audit forces the question.
This guide walks through exactly what a DPDP-compliant consent record looks like: the fields you must capture, the retention periods you must observe, the storage architecture that holds up under scrutiny, and the operational processes that keep your records accurate over time.
Key Takeaways
- Under Section 6 of the DPDP Act 2023, the burden of proving valid consent falls on the Data Fiduciary. If you cannot produce the record, the consent is assumed not to exist.
- A compliant consent record must capture nine core fields: identity of the Data Principal, timestamp, purpose(s), notice version, consent mechanism, affirmative action taken, channel, withdrawal status, and language of the notice presented.
- The DPDP Rules 2025 require consent records and related notices to be retained for a minimum of seven years, or longer if mandated by any other law or contractual obligation.
- Access logs for systems processing personal data must be retained for at least one year under Rule 8 of the DPDP Rules 2025.
- Consent records should be immutable, timestamped, and stored separately from the operational data they authorise, creating an independent audit trail.
Why Do Consent Records Matter Under DPDP?
Two reasons: one legal, one operational.
The legal reason is Section 6(7) of the DPDP Act 2023. It states that in any proceeding where a question arises about whether consent was given, the Data Fiduciary must prove that notice was provided and consent was obtained as required by the Act. The burden of proof is on you. Not on the Data Principal. Not on the regulator. You.
This is a reversal from how many Indian businesses currently operate. Under the old IT Act framework, the standard was vague enough that "we have a checkbox on our website" was treated as sufficient. Under DPDP, a checkbox without a corresponding record of who checked it, when, for which purposes, and in response to which notice is a checkbox that proves nothing. For full background on the DPDP Act 2023 consent requirements, see our complete guide.
The operational reason is equally important. Consent records are the foundation your compliance programme rests on. Without them, you cannot respond to Data Principal withdrawal requests accurately, you cannot demonstrate compliance during a data audit, and you cannot verify that downstream data processing aligns with the consent originally given.
I have seen organisations discover, during their first serious compliance review, that they had three years of customer data collected through a consent mechanism that logged nothing except a binary "accepted / not accepted" flag. No timestamp. No purpose granularity. No notice version. They had thousands of consent events and zero usable consent records.
What Must a Consent Record Contain?
The DPDP Act and Rules do not prescribe a rigid consent record schema. What they do prescribe are the elements of valid consent (Section 6) and the Data Fiduciary's obligation to prove it (Section 6(7)). Working backward from those requirements, a compliant consent record needs nine core fields.
The Nine-Field Consent Artefact
| # | Field | What to Capture | Why It Matters |
|---|---|---|---|
| 1 | Data Principal Identity | User ID, account identifier, or session token. Not necessarily full name; a unique, resolvable identifier is sufficient. | Links the consent event to a specific individual for retrieval during DSR requests or Board inquiries. |
| 2 | Timestamp | Exact date and time of consent, in ISO 8601 format with timezone (e.g., 2026-04-15T14:32:07+05:30). | Establishes when consent was given. Required for proving compliance during the period between consent and any subsequent withdrawal. |
| 3 | Purpose(s) Consented To | Each specific purpose as a separate, identifiable item. "Marketing" is not specific enough; "Email newsletters about product updates" is. | Section 6(1) requires consent to be "specific." Granular purpose logging proves specificity. |
| 4 | Notice Version | The version identifier of the privacy notice or consent notice presented at the time of consent. | If your notice changes, you need to know which version the Data Principal actually saw and agreed to. |
| 5 | Consent Mechanism | The specific UI element or process through which consent was captured: opt-in checkbox, toggle switch, consent banner selection, written form, verbal confirmation. | Proves that consent was obtained through a "clear affirmative action" as required by Section 6(1). |
| 6 | Affirmative Action | The exact action the Data Principal took: checked a box, clicked "Accept," toggled a switch from off to on, signed a form. | Distinguishes valid consent from inferred consent. Pre-ticked boxes and implied-by-continued-use patterns do not satisfy DPDP requirements. |
| 7 | Channel | Website, mobile app, in-store kiosk, email, phone call, WhatsApp Business, paper form (digitised). | Contextualises the consent event. A consent captured via a 3-inch mobile screen has different UX implications than one captured on a desktop browser. |
| 8 | Withdrawal Status | Current status (active / withdrawn), with a linked withdrawal record if applicable. | Section 6(4) gives Data Principals the right to withdraw consent at any time. Your record must reflect the current state, not just the original grant. |
| 9 | Language of Notice | The language in which the consent notice was presented (English, Hindi, Tamil, etc.). | The DPDP Rules 2025 require notices in accessible languages. Recording which language was presented demonstrates compliance with that requirement. |
These nine fields form the minimum viable consent artefact. Some organisations add supplementary fields: IP address at time of consent, device type, browser user agent, referring URL. These are useful for forensic purposes but are not strictly required by the Act.
What About Legitimate Uses? Do They Need Records Too?
Yes, though the record looks different. For processing under legitimate uses (Section 7), you do not have a consent event to log. What you need is a documented justification: which specific Section 7 ground applies, what processing activity it covers, and the reasoning for why consent is not required.
Here is the structure:
| Field | What to Document |
|---|---|
| Processing Activity | Description of what data is processed and why |
| Section 7 Ground | The specific sub-section: 7(a) voluntary provision, 7(b) employment, 7(c) medical emergency, 7(d) safety, 7(e) legal compliance, 7(f) public interest |
| Justification | Why this processing qualifies under the stated ground |
| Data Categories | What personal data is involved |
| Review Date | When this justification was last reviewed and confirmed |
Keep these justification records alongside your consent records. If the Data Protection Board asks "on what basis are you processing this data?" you need to produce either a consent record or a legitimate use justification. Having neither is the worst possible answer.
How Long Must You Retain Consent Records?
The DPDP Rules 2025 establish two retention floors that directly affect consent records.
Seven-year retention for consent records and notices. The DPDP Rules 2025 require Data Fiduciaries to retain records of consent, associated notices, and records of data sharing for a minimum of seven years, or longer if mandated by any other law or contractual agreement.
One-year retention for access logs. Rule 8 requires Data Fiduciaries and Data Processors to retain logs (access events, modification events, consent withdrawals, deletion triggers, security incidents) for a minimum of one year.
Here is how these translate to operational requirements:
| Record Type | Minimum Retention | Source | Practical Notes |
|---|---|---|---|
| Consent artefact (the nine fields above) | 7 years from the date of consent | DPDP Rules 2025 | Retain even after the Data Principal withdraws consent or requests data erasure. The consent record itself is your proof of lawful processing during the active period. |
| Privacy notice versions | 7 years from last use | DPDP Rules 2025 | Every version of your consent notice that any Data Principal saw must be retrievable. Use version control. |
| Consent withdrawal records | 7 years from withdrawal | DPDP Rules 2025 | Log when consent was withdrawn, through which mechanism, and what processing stopped as a result. |
| System access logs (personal data) | 1 year minimum | DPDP Rules 2025, Rule 8 | The Data Protection Board may audit these during investigations. |
| Data sharing records | 7 years from date of sharing | DPDP Rules 2025 | Track which third parties received data, when, and under what consent basis. |
A common mistake: deleting consent records when a Data Principal requests data erasure under Section 12. The erasure right applies to the Data Principal's personal data, not to your compliance records about that data. You erase their marketing preferences, their profile data, their transaction history as appropriate. You do not erase the record that proves they consented to you processing that data in the first place. That record is your legal shield; destroying it leaves you unable to demonstrate that your past processing was lawful.
How Should You Store Consent Records?
The architecture of your consent record storage matters more than most compliance teams realise. A consent record that exists only as a row in your application database, mingled with user profile data and subject to the same update and delete operations, is a consent record that can be accidentally modified, overwritten, or purged.
Three Principles for Consent Record Storage
Principle 1: Immutability. Once a consent artefact is created, it should never be modified. If a Data Principal grants consent, then withdraws it, then re-consents, that is three separate records, not one record updated twice. Each event gets its own timestamped, append-only entry.
Principle 2: Separation. Consent records should be stored separately from the operational data they authorise. Your CRM stores customer data. Your consent record store proves you had the right to put that data in the CRM. These are different systems with different access controls, different retention policies, and different deletion rules.
Principle 3: Retrievability. You need to be able to query by Data Principal, by purpose, by time range, and by status. When a Data Principal exercises their right to access under Section 11, part of their request may be "show me what I consented to." When the Board investigates, their question may be "show me all consent records for marketing emails collected between January and March 2026." Both queries must return results quickly.
Storage Options: Manual vs. Automated
For organisations at different scales, the practical implementation varies:
| Approach | Suitable For | Pros | Cons |
|---|---|---|---|
| Spreadsheet-based tracking | Very small businesses (under 10 employees, under 1,000 Data Principals) | Low cost, simple to start | No immutability, no audit trail, manual entry errors, fails at scale |
| Database table with append-only writes | Mid-size businesses with engineering capacity | Full control, integrates with existing stack | Requires custom development, ongoing maintenance, no built-in compliance features |
| Consent management platform | Businesses processing data from 1,000+ Data Principals | Purpose-built, immutable records, automated logging, regulatory reporting features | Cost, vendor dependency |
| Blockchain-anchored records | Enterprises with regulatory pressure for tamper-proof evidence | Cryptographic immutability, third-party verifiable | Over-engineered for most SMBs, complexity, cost |
For most Indian SMBs in the 20 to 200 employee range, the second or third option is the practical sweet spot. A dedicated database table with append-only writes and a simple admin interface for retrieval covers the requirements without over-engineering. If your organisation already uses a consent management tool for your website banner, check whether it also stores the full consent artefact, many tools capture the consent signal but discard the evidentiary detail.
What Does the Consent Lifecycle Look Like in Practice?
Consent is not a one-time event. It has a lifecycle: grant, active use, modification, withdrawal, and post-withdrawal retention. Your record-keeping system must handle every stage.
Stage 1: Consent Grant
The Data Principal encounters your consent notice and takes an affirmative action. Your system creates a consent artefact with all nine fields. This is the moment of truth for your logging infrastructure.
Here is what that record should look like:
Sample Consent Artefact
- Data Principal ID: USR-2026-04-15-7842
- Timestamp: 2026-04-15T14:32:07+05:30
- Purposes: [email_product_updates, email_promotional_offers]
- Notice Version: privacy-notice-v3.2
- Consent Mechanism: Website opt-in form (granular checkboxes)
- Affirmative Action: User checked "Product update emails" and "Promotional offers" individually; left "Third-party partner offers" unchecked
- Channel: Desktop web browser (complyzero.com/signup)
- Status: Active
- Notice Language: English
Note the granularity. The Data Principal consented to two purposes and declined a third. That distinction is the difference between specific consent and bundled consent. Your record must reflect the declined items as clearly as the accepted ones.
Stage 2: Active Consent Period
During this period, you process data in accordance with the consented purposes. Your system should periodically verify that active processing aligns with active consent records. If your marketing team starts sending SMS promotions but the consent record only covers email, that is processing without a valid basis.
Stage 3: Consent Modification
The Data Principal updates their preferences. Perhaps they withdraw consent for promotional offers but keep product updates. Your system creates a new consent artefact reflecting the updated state, linked to the original. The original record remains unchanged and retained.
Stage 4: Consent Withdrawal
Section 6(4) gives Data Principals the right to withdraw consent at any time. Withdrawal must be as easy as giving consent. When a withdrawal is processed:
- Create a withdrawal record (timestamp, which purposes withdrawn, mechanism of withdrawal)
- Stop processing for the withdrawn purposes
- If all purposes are withdrawn, trigger your data retention review: is there another lawful basis for retaining any of the data?
- The original consent record stays in your system for the full seven-year retention period
Stage 5: Post-Withdrawal Retention
After withdrawal, the consent record transitions from an active compliance document to a historical evidence record. It proves that the processing you conducted between grant and withdrawal was lawful. It must be retained, accessible, and immutable for the full retention period.
Building a Consent Record Audit Trail
Beyond individual consent artefacts, you need a system-level audit trail that captures every interaction with consent data. This is distinct from the consent artefact itself; it is the log of who accessed, queried, or acted on consent records.
The DPDP Rules 2025 require retention of access logs for at least one year. For consent records specifically, I recommend maintaining these audit logs for the same duration as the records they reference (seven years), because the Board's question is not just "did consent exist?" but "was your consent management system operating properly?"
Your audit trail should capture:
- Who accessed or queried consent records (user identity, role)
- When the access occurred (timestamp)
- What they accessed (which Data Principal's records, which query)
- Why (DSR fulfilment, compliance review, routine administration)
- What action was taken (view only, export, status change)
This trail protects you against internal disputes ("who marked that consent as withdrawn?") and external scrutiny ("show us your consent management process, not just the records").
Common Mistakes in Consent Record-Keeping
Having built consent management systems at multiple organisations, I see the same failures repeatedly.
Logging consent but not the notice. You have a record that the Data Principal consented on April 15, 2026. When the Board asks "what exactly did they consent to?", you point to your current privacy notice. But you updated that notice in June 2026. The version the Data Principal actually read no longer exists. Without notice version control, your consent record is incomplete. Maintain a versioned archive of every consent notice, linked to the consent artefacts that reference it.
Treating consent as binary. A single "accepted" or "rejected" field. This fails the specificity requirement. DPDP requires consent to be specific to each purpose. Log each purpose separately, with its own acceptance or rejection status.
No withdrawal records. The system tracks when consent was given but has no record of when (or whether) it was withdrawn. When a Data Principal exercises their withdrawal right, both the withdrawal event and the subsequent cessation of processing need to be documented.
Deleting consent records during data erasure. As covered above, the consent record is not the Data Principal's personal data for the purpose of erasure requests. It is your compliance evidence. A company that purges consent records alongside user data during an erasure request has destroyed its own proof of lawful processing.
Relying on email receipts as consent records. "We sent them a welcome email, so we know they signed up." An email confirmation proves a signup occurred. It does not prove that a DPDP-compliant notice was presented, that specific purposes were disclosed, or that an affirmative action was taken. Email receipts are supplementary evidence at best.
A Phased Implementation Plan for Consent Record-Keeping
If you are starting from scratch or retrofitting an existing system, here is a practical implementation sequence:
Phase 1: Baseline (Week 1-2)
- Audit your current consent collection points. List every touchpoint where you collect consent: website forms, app flows, offline processes, email signups, cookie banners. Cross-reference against your DPDP compliance checklist.
- For each touchpoint, assess what is currently logged. Most organisations find significant gaps between what their consent banner captures and what the Act requires.
- Define your consent artefact schema using the nine-field model above.
Phase 2: Implementation (Week 3-5)
- Build or configure your consent record storage. Ensure append-only writes, separation from operational databases, and query capability by Data Principal, purpose, and date range.
- Update each consent collection touchpoint to capture all nine fields and write them to the consent record store.
- Implement notice version control. Every change to your consent notice creates a new version with a unique identifier.
- Build the withdrawal workflow: when a Data Principal withdraws consent, a withdrawal record is created, linked to the original consent artefact, and processing ceases.
Phase 3: Operations (Week 6 onward)
- Establish a monthly review to verify that active processing aligns with active consent records. Catch any new processing activities that started without corresponding consent updates.
- Set up automated retention management. Consent records older than seven years are flagged for review and archival or secure deletion.
- Train your team. Customer support, marketing, and product teams should understand what consent records exist, how to query them for DSR requests, and what not to modify.
A 50-person company can complete Phases 1 and 2 in roughly five weeks with one engineer and one compliance lead working part-time on the project. Phase 3 is continuous but light: a few hours per month of review and maintenance.
Frequently Asked Questions
What is a consent artefact under the DPDP Act?
A consent artefact is a structured, timestamped, digital record of a Data Principal's consent event. It captures who consented, when, to which purposes, through which mechanism, and in response to which notice. The DPDP Act 2023 does not use the term "consent artefact" explicitly, but Sections 6 and 6(7) together create the requirement: consent must be specific, informed, and provable. The consent artefact is the operational mechanism for meeting that burden of proof. As of April 2026, no prescribed format exists; the nine-field model described in this guide is derived from the Act's requirements and compliance best practice.
How long must I keep consent records under DPDP?
The DPDP Rules 2025 require Data Fiduciaries to retain records of consent, associated notices, and data sharing records for a minimum of seven years, or longer if required by other laws or contractual obligations. Access logs for personal data systems must be retained for at least one year under Rule 8. Consent records should be retained even after a Data Principal withdraws consent or requests data erasure, as they serve as evidence of lawful processing during the active consent period.
Can I delete consent records when a Data Principal requests data erasure?
No. The right to erasure under Section 12 of the DPDP Act applies to the Data Principal's personal data, not to your compliance records about that data. Consent records prove that your past processing was conducted with a valid legal basis. Deleting them would leave you unable to demonstrate lawful processing if the Data Protection Board inquires about data you previously held. Erase the operational data (profile, transaction records, marketing preferences) as required. Retain the consent artefact for the full seven-year retention period.
Do I need separate consent records for each purpose?
Yes. Section 6(1) of the DPDP Act requires consent to be "specific." A single consent record covering "all marketing activities" does not meet this standard. Each distinct purpose (product update emails, promotional offers, third-party data sharing, analytics tracking) should be recorded as a separate consent signal within the artefact, with its own acceptance or rejection status. This granularity is what allows you to honour partial withdrawal: a Data Principal can withdraw consent for promotional offers while maintaining consent for product updates, and your records must reflect each independently.
What if I collected consent before the DPDP Act came into force?
Section 5(2) of the DPDP Act addresses pre-existing data. If you collected personal data before the Act's enforcement, you must provide a retrospective notice to Data Principals as soon as reasonably practicable. The challenge for consent records is that many organisations collected pre-Act data under IT Act standards that did not require granular, purpose-specific consent logging. Going forward, you should: (1) issue the retrospective notice as required by Section 5(2), (2) begin logging consent records in the nine-field format from the date of compliance, and (3) document the gap for pre-existing data, noting that it was collected under prior legal standards with a record of the retrospective notice sent.
Simplify Your DPDP Compliance
This article is for informational purposes and reflects the DPDP Act 2023 and DPDP Rules 2025 as understood at the time of writing. For guidance specific to your business, we recommend consulting a qualified data protection professional.
Building a consent record system from scratch takes weeks of engineering time and ongoing maintenance. ComplyZero's self-serve platform handles consent collection and record-keeping out of the box: every consent event is logged with full artefact detail, stored immutably, retrievable by Data Principal or purpose, and retained for the required period. Set up in 15 minutes, not 15 weeks.
Simplify Your DPDP Compliance
This article is for informational purposes and reflects the DPDP Act 2023 and DPDP Rules 2025 as understood at the time of writing. For guidance specific to your business, we recommend consulting a qualified data protection professional.
ComplyZero handles the complexity for you: consent management, privacy notices in 22 languages, DSR workflows, and audit-ready compliance records. Get your business DPDP-ready in minutes, not months.
Get Started Free