What Is a Consent Artefact Under the DPDP Act, and What Must It Contain?
A consent artefact is the record that proves consent under the DPDPA. Here is what the term means and the exact fields a compliant record must contain.
A vendor evaluation call mentions "consent artefacts," a compliance consultant references the same phrase in a different context, and a DPO is left checking whether this is a formally defined DPDPA term or something borrowed from elsewhere. It is a fair question, and the answer shapes what a compliant consent record needs to hold.
A consent artefact under the DPDP Act is the structured digital record that captures the details of a specific consent event, tied to a named purpose, a notice, and a Data Principal, in a form that can be produced as evidence later. The term itself comes from outside the DPDPA statute, which matters for how strictly to apply it and where the actual field-level requirements come from.
This article sets out where the term originates, what a consent artefact needs to contain under DPDPA specifically, and how the requirement differs between a regular Data Fiduciary and a registered Consent Manager.
Where the Term Consent Artefact Comes From
Consent artefact is not a term defined in the Digital Personal Data Protection Act, 2023, or in the DPDP Rules, 2025. It originates in India's Data Empowerment and Protection Architecture, and its practical implementation in the financial sector through the Account Aggregator framework regulated by the Reserve Bank of India.
Under the RBI's Account Aggregator Master Directions, an Account Aggregator must formulate a standardised consent artefact for every data-sharing request. Clause 6.3 of the Master Directions sets out what that artefact must contain: the customer's identity, the nature of the financial information requested, the purpose of collection, the identity of the recipient, and the consent's creation and expiry dates, among other fields.
The DPDP Rules, 2025 build the Consent Manager role on this same architecture. Rule 4, read with the First Schedule, describes a Consent Manager as an interoperable platform through which a Data Principal gives, manages, reviews, and withdraws consent, closely mirroring what an Account Aggregator does for financial data. The term consent artefact has carried over into DPDPA discussions as the natural label for the equivalent record, even though the Act and Rules describe the underlying requirements without using that exact phrase.
What a Consent Artefact Means in the DPDPA Context
In the DPDPA context, a consent artefact is the record a Data Fiduciary, or a registered Consent Manager, keeps as evidence that a specific, valid consent event took place for a named purpose, and can produce that record if the Data Principal, an auditor, or the Data Protection Board asks for it.
Because the term itself sits outside the statute, its content is not spelled out as a single checklist in one section. It has to be assembled from three places: the consent standard in Section 6, the notice requirements in Section 5 and Rule 3, and the record-keeping obligations placed on Consent Managers under the First Schedule of the DPDP Rules. Treating the artefact as a generic definition, without mapping it to these three sources, leaves genuine gaps in what a compliant record needs to hold.
The Fields a Compliant Consent Artefact Must Contain
A consent artefact built to satisfy DPDPA needs the following fields, mapped to specific sections of the Act and Rules.
Data Principal reference. A stable identifier for the individual, which does not need to be the raw personal data itself and is often a token or account reference, so the record can be matched back to the person without becoming an additional processing risk.
Data Fiduciary identity. The name and contact details of the organisation collecting the consent, and the Data Protection Officer or designated contact where applicable.
Purpose of processing. The specific purpose the consent was collected for, stated at the same level of granularity Section 6 requires, not a broad category covering several unrelated purposes.
Data categories covered. The personal data fields this specific consent authorises processing for, limited to what the stated purpose needs.
Notice version and reference. A link to the exact version of the Section 5 notice shown at the time of consent, since notices are revised over time and the artefact needs to show which version the Data Principal saw.
Consent action and timestamp. How the affirmative action was given, such as a checkbox tick or an SMS confirmation, and the exact date and time it occurred.
Consent status. Whether the consent is currently active, denied, or withdrawn, with a timestamp for each status change.
Withdrawal mechanism reference. A record of how the Data Principal can withdraw consent, satisfying Section 6(4)'s requirement that withdrawal be as easy as giving consent.
Grievance channel reference. A pointer to the grievance redressal process under Section 13, including how to reach the organisation and the Data Protection Board.
Recipient or channel detail, where relevant. For a Consent Manager routing consent to multiple Data Fiduciaries, the specific Data Fiduciary the consent applies to.
How This Differs for a Consent Manager Versus an Ordinary Data Fiduciary
Most organisations processing personal data directly are not Consent Managers, and the distinction matters for how strictly the artefact needs to be built.
An ordinary Data Fiduciary keeps its own consent records to demonstrate its own compliance. The fields above still apply, since they trace back to Section 6 and Section 5 regardless of who is keeping the record, but the format and interoperability requirements that apply to a registered Consent Manager do not.
A registered Consent Manager, once Rule 4 comes into force on 13 November 2026, carries additional obligations under the First Schedule of the DPDP Rules. These include maintaining records of every consent given, denied, or withdrawn, along with the notices that accompanied each request, retaining those records for a minimum of seven years, and providing the Data Principal access to the records in machine-readable form on request. A Consent Manager's consent artefacts also need to work across every Data Fiduciary onboarded to the platform, which is where the interoperability requirement borrowed from the Account Aggregator model becomes directly relevant.
Why the Artefact Matters When a Grievance or Board Query Arrives
Section 6 places the burden of proving valid consent on the Data Fiduciary, not on the Data Principal raising a question about it. When a grievance under Section 13 names a specific consent, or the Data Protection Board asks how a particular consent was obtained, the organisation needs to produce the artefact, not describe its general consent process.
This is a useful way to think about the artefact fields listed above. Each one answers a specific question a regulator or a Data Principal is entitled to ask: what was the person told, what did they agree to, when, and how can they change their mind. A compliance team that has already mapped its records against these fields is answering that question from an existing record, instead of reconstructing the answer after the fact.
For a closer look at how these records need to be stored so they hold up as evidence, our guide on append-only audit logs and why DPDPA compliance evidence must be tamper-proof covers the storage side of this question in more depth.
A Quick Self-Check for Your Consent Records
Before assuming your current consent logs would hold up as a compliant artefact, it is worth checking them against these questions.
Does every consent record show the specific purpose it was collected for, instead of a general category?
Can you trace a given consent back to the exact notice version the Data Principal saw at the time?
Does your system log a timestamp for consent given, and a separate timestamp for any later withdrawal?
If the Data Protection Board asked for a specific consent record today, could your team produce it within a defined timeframe?
If you operate or plan to operate as a Consent Manager, does your record format work consistently across every Data Fiduciary on your platform?
Where OneConsent Fits
OneConsent captures each consent event with the purpose, notice version, timestamp, and status fields described above, so the record it generates maps directly to what Section 6 and Section 5 expect a compliant artefact to contain. Consent evidence and audit trail capabilities keep this record time-stamped and available for retrieval, instead of reconstructed manually when a grievance or a Board query arrives.
The consent sync hub carries status changes, including withdrawal, across every connected system, so the artefact reflects the Data Principal's current choice consistently, instead of a snapshot from a single channel.
A Practical Next Step
If your compliance team is currently relying on generic consent logs instead of records mapped to Section 6 and Section 5 requirements, a useful starting point is reviewing your existing consent data against the field list above and identifying which fields are missing.
Book a demo to review how a structured consent artefact would look against your current systems, or visit OneConsent to explore the platform in more detail.
Frequently Asked Questions
Have more questions?
Search our full DPDP knowledge base for more answers.