Written by

Sumeshwar Pandey

View Profile
12 min read

Consent Receipts: What to Store, Hash, and Timestamp

An engineering guide to designing DPDP-ready consent records and receipts with the right fields, hashes, timestamps, and event flows for defensible audits.
Key takeaways
  • Under the DPDP Act, the real consent risk sits in missing or weak records, not only in banners or forms; you need a canonical consent schema and event history that can be produced on demand.
  • Aligning your internal consent record with ISO/IEC TS 27560’s structure makes it easier to decide what to store in clear text, what to hash, and which timestamps are required for auditability.
  • Treat consent as an event-sourced pipeline: append-only state changes, hashed receipts, and deterministic propagation of give, refuse, withdraw, and expire events to downstream systems.
  • A small set of failure modes—missing notice versions, ambiguous purposes, lost withdrawals, and inconsistent cross-channel state—cause most DPDP consent problems and can be tested systematically.
  • Platforms such as Digital Anumarti - Service can provide a DPDP-focused consent ledger and receipt layer, but engineering teams still own schema design, integration quality, and monitoring.
Picture a message from your compliance officer: the Data Protection Board of India has forwarded a complaint from a Data Principal. The person claims they received an SMS credit offer on a specific date without ever consenting to marketing. The Board asks your organisation, as Data Fiduciary, to prove that this SMS and the underlying profiling were covered by valid consent at that time, with a copy of the notice and evidence of the interaction.
Legally, this is framed as a question of free, specific, informed consent under the DPDP Act. Operationally, it is a question of what your systems can show. Can you reconstruct which notice text, in which language, was shown on which screen or channel? Can you prove exactly when the Data Principal granted, refused, or withdrew consent for that purpose? Can you show how that consent state propagated to the campaign system that triggered the SMS? If the answer to any of these is no or maybe, the gap sits in your consent record and logging architecture, not in the wording of your banner.
In that context it helps to distinguish three layers that are often conflated. The consent interface is what the Data Principal sees and interacts with: banners, forms, IVR prompts, OTP flows. The internal consent record is the structured, system-facing representation that drives decisions and audits. The consent receipt is an optional, standardised artefact you can issue to the Data Principal summarising what was agreed at a point in time. DPDP focuses on your ability to demonstrate consent; standards such as ISO/IEC TS 27560 and the Kantara Consent Receipt specification describe how to represent it. Engineering teams have to make these layers work together so that any future regulator, board member, or complainant can be shown a defensible history, not just screenshots.
The Digital Personal Data Protection Act 2023 sets consent as the default legal basis for most non-exempt processing of digital personal data in India. Consent must be free, specific, informed, unconditional, and given through a clear affirmative action, with an equally simple mechanism for withdrawal. The Act and the forthcoming DPDP Rules 2025 expect Data Fiduciaries to be able to demonstrate that valid consent existed for a given processing activity, including the notice that was shown, the purposes that were described, and the moment at which consent was given or withdrawn; that expectation translates directly into consent record-keeping and logging requirements.[4]
Global privacy standards provide a useful engineering template for that history. ISO/IEC 29184 describes how online privacy notices and consent journeys should be structured and presented, with a focus on the content of notices and the interaction patterns used to obtain consent.[1]
ISO/IEC TS 27560 goes deeper on the internal data model, defining an interoperable, open, and extensible information structure for consent records and consent receipts, including requirements for lifecycle management of consent states.[2]
The Kantara Consent Receipt specification adds a concrete JSON-based receipt format targeted at individuals, covering authority, purposes, data categories, and links to notices and policies so that a consent record can be expressed in a human-readable artefact.[3]
For organisations that also operate under GDPR or follow EDPB consent guidance, there is comfortable overlap with DPDP: both regimes expect you to prove who consented, to what, when, and on the basis of which information. Indian implementations, however, need to reflect concepts such as Data Fiduciary and Data Principal, the role of consent managers, and domestic rules around purpose and storage limitation. Implementations can also look at work such as the PublicSchema ConsentRecord concept, which aligns fields across ISO/IEC TS 27560, the Kantara Consent Receipt, and other vocabularies to show what a detailed, standards-convergent consent schema can look like.[5]
A practical way to avoid consent gaps is to define a single canonical consent record schema that every channel and product can write to. A useful pattern is to align that schema with four logical groups that mirror the structure in ISO/IEC TS 27560: headers and metadata, parties, processing, and consent specifics. You can implement this as a relational model, a document model, or a hybrid, as long as you can reliably reconstruct these four groups for any consent event.
Core consent record groups aligned with ISO/IEC TS 27560 and DPDP terminology.
Group Role in record Example fields (non-exhaustive)
Headers and metadata Describe the consent record itself so you can manage lifecycle, migrations, and environments without touching personal data. consent_record_id, schema_version, created_at, last_updated_at, source_system, channel, environment, correlation_id
Parties Identify the Data Principal, Data Fiduciary, and any Data Processors or other parties involved in the processing context. subject_reference, subject_is_child, data_fiduciary_identifier, data_processor_identifiers, party_roles, links to processor agreements
Processing Capture what is being done with the data, for what purposes, on which categories, under which legal basis, and with what retention and transfer parameters. purpose_ids, data_category_ids, processing_operations, legal_basis, geographic_scope, cross_border_flags, expected_retention
Consent specifics Record the Data Principal’s choices over time and tie them to notices, purposes, channels, evidence, and receipts. consent_status, status_per_purpose, notice_id, notice_version, language_code, consent_given_at, consent_withdrawn_at, expiry, evidence_references, consent_receipt_identifier
Headers and metadata describe the consent record itself, not the person. Typical fields include a stable consent_record_id, a schema_version, created_at and last_updated_at timestamps, the source_system and channel (for example, web, Android, branch_kiosk, contact_centre), the environment (production or test), and an optional correlation_id for grouping related events in a single interaction. For DPDP audits, a clear separation between metadata about the record and the actual consent content helps you reason about lifecycle, retention, and migration without touching personal data.
The parties group identifies who is involved in the processing. At minimum this should include a subject_reference that links to your identity layer, a data_fiduciary_identifier (often a legal-entity identifier rather than a trading name), and zero or more data_processor_identifiers for vendors or group entities that perform processing on your behalf. In Indian B2B2C flows, such as diagnostic networks or marketplace models, there may be multiple Data Fiduciaries and processors in a single business flow; your schema should support structured party roles and clear references to underlying processor agreements rather than embedding free-text descriptions.
The processing group captures what is being done with the data. This is where you model purpose codes, data categories, processing operations, legal bases, and retention expectations. Instead of hard-coding text into the consent record, maintain separate catalogues for purposes and data categories with stable identifiers, machine-readable descriptions, and human-readable labels in the major languages you support. Each consent record then stores references, such as purpose_ids, data_category_ids, a legal_basis code indicating consent versus statutory obligation, and parameters such as geographic scope or cross-border transfer flags. That separation makes it easier to update notice wording or add languages without losing the original semantic intent.
Finally, the consent specifics group captures the Data Principal’s choices and how they change over time. Core elements include the consent_status (such as given, refused, withdrawn, expired), a granularity model that links each status to concrete purposes and channels, conditions such as expiry or review dates, references to notice_id and notice_version that were in force when the choice was made, and evidence_references pointing to logs, screen captures, OTP confirmations, or call recordings. This is also where you store a consent_receipt_identifier or signature if you generate receipts for Data Principals. As long as your internal schema can be projected into these four groups, you can build DPDP-ready receipts and logs even if your underlying database tables use different names or structures.

What to store, hash, and timestamp in the consent receipt

Once the information model is defined, the next design decision is how to balance auditability with data minimisation: which elements stay in clear text, which are hashed or pseudonymised, and what must be timestamped. It helps to draw a boundary between the internal consent record, which exists primarily for decisioning and compliance, and the external consent receipt that you may provide to the Data Principal. Receipts usually expose a subset of the record, often with additional cryptographic protections, while the internal record retains the links needed for system joins and investigations.
Identity information is usually the most sensitive part of the record. Internally, you typically need a stable, non-guessable subject_reference that joins to your identity store; this can be a synthetic ID or a token, not a raw mobile number or email address. The consent record should avoid duplicating direct identifiers; instead, it stores foreign keys or strongly pseudonymised tokens under strict access control. If you include identifiers on a consent receipt, use masked forms, such as partially redacted mobile numbers, or a hashed representation that allows you to confirm that a receipt belongs to a particular Data Principal without exposing the underlying identifier if the receipt is leaked. Whichever pattern you choose, record a subject_binding_timestamp indicating when the consent record was first associated with the Data Principal’s identity.
Notice and policy references almost always need to be stored in clear text identifiers with cryptographic checksums for integrity. Each consent event should include a notice_id, a notice_version, the language in which it was presented, and a notice_presented_at timestamp separate from the consent_given_at timestamp. To defend against later disputes about what the notice contained, store a notice_checksum, such as a cryptographic hash of a canonical JSON representation of the notice, and optionally a ui_variant or template_id indicating which layout was used. The consent receipt can embed both the human-readable notice summary and the checksum, so that you can later prove that the text has not been retroactively altered.
Purposes and processing operations are typically safe to store in clear text as structured codes, because they describe your behaviour rather than the Data Principal. The important design choice here is to make the purpose set explicit and immutable for a given consent event. One pattern is to compute a canonical, sorted list of purpose_ids and data_category_ids and then derive a purpose_set_signature by hashing that canonical string. The record stores both the individual codes and this signature; the receipt includes the signature. If anyone later questions whether additional purposes were silently added, you can recompute the signature from the receipt and compare it to what is in your ledger. Timestamps in this area include when each purpose was first consented to, last refreshed, and, if applicable, when consent for that purpose is scheduled to expire.
Consent state changes are best represented as an append-only event stream. Instead of overwriting a single status flag, write explicit events such as given, refused, withdrawn, renewed, and expired, each with an event_timestamp, a source, such as web_form or call_centre, and a reference to the previous state. For manual flows, capture an operator_identifier and interaction_channel so that you can distinguish system-initiated expiries from human actions. Most of these values can remain in clear text inside your internal logs, but you may choose to pseudonymise operator identifiers in long-term archives. The key timestamps here are consent_given_at, consent_withdrawn_at, consent_renewed_at, and consent_expired_at, which should all be stored in a normalised format such as UTC with an explicit offset; handling time zones correctly is essential when disputes depend on exact dates.
The evidence layer links consent events to what the system actually observed: IP addresses, device identifiers, OTP logs, or call recordings. Many of these elements are highly sensitive and should be minimised. A common pattern is to store short-lived raw values in operational logs and retain only hashed or truncated versions in the long-term consent ledger. For example, you might store the full IP address for a limited period in security logs but keep only a truncated IP prefix or a hash in the consent record, along with an evidence_reference to the security log entry. For call recordings, the consent record should hold a stable recording_id and an evidence_type such as voice, while the actual recording is stored and secured in your telephony system. Each evidence item should be associated with an evidence_created_at timestamp and an evidence_retention_until timestamp aligned with your legal and policy decisions.
Derived or aggregate values, such as consent acceptance rates by channel or the number of active consents for a given purpose, should normally be computed from the event stream rather than stored in individual consent records. Storing aggregates inside the base record makes it harder to reason about causality and increases the risk of stale or inconsistent data during audits. Keep the consent record focused on raw, reconstructible facts with clear timestamps and signatures; feed analytics and dashboards from your warehouses or stream processors that consume the same underlying events.
A simple piece of control-flow logic illustrates how these storage and timestamping decisions come together at request time. When any system wants to perform a consent-dependent operation, it should query the current consent state, enforce it, and log what happened in a way that can still be linked back to the original consent event without overexposing identity data. One representative pattern is sketched in the pseudocode below.
Request-time consent check and processing decision logging
function handleProcessingRequest(request):
    subject_ref = resolveSubjectReference(request)           # token, not raw PII
    purpose_code = mapBusinessActionToPurpose(request.action)

    consent = consentService.getCurrentConsent(
        subject_ref = subject_ref,
        purpose_code = purpose_code
    )

    decision_time = nowUtc()

    if consent is null or consent.status != "GIVEN":
        logProcessingDecision(
            subject_ref = subject_ref,
            purpose_code = purpose_code,
            decision = "DENY",
            reason = "NO_VALID_CONSENT",
            consent_record_id = consent.id if consent is not null else null,
            decision_time = decision_time
        )
        raise ConsentRequiredError()

    logProcessingDecision(
        subject_ref = subject_ref,
        purpose_code = purpose_code,
        decision = "ALLOW",
        consent_record_id = consent.id,
        consent_version = consent.version,
        decision_time = decision_time
    )

    performBusinessAction(request)
This control flow resolves a pseudonymous subject reference, maps the business action to a purpose code, looks up the current consent state, and either denies or allows processing. It never mutates the consent ledger during the check; instead it writes a separate processing_decision event linked by consent_record_id and decision_time so later audits can prove that each outbound action was evaluated against the consent state that existed at that moment.
With the schema in place, the next concern is how consent events flow through your architecture. At scale, three patterns appear most often. In a central consent service pattern, a dedicated service exposes APIs to capture, query, and revoke consent, backed by an append-only ledger and a notice catalogue. In a per-service pattern, each domain service maintains its own consent tables and logic, synchronising only loosely. In a hybrid pattern, a central ledger exists as the system of record, while domain services keep denormalised caches of consent state for latency-sensitive operations. For Indian organisations facing DPDP scrutiny and multi-channel consent, the central or hybrid patterns are usually easier to defend, because they give you a single evidentiary source while still allowing performance tuning.
A typical event flow for web or mobile consent capture starts at the UI but is owned by the central service. The front end resolves the Data Principal’s identity token and retrieves the active notice and purpose set from the consent service, rather than embedding them statically. When the Data Principal acts, the UI calls a consent API endpoint with subject_reference, purpose selections, notice_id, notice_version, channel, and context. The service validates that the notice is current, writes a consent_given or consent_refused event to the ledger, derives or updates the current aggregated state for that subject and purpose, and publishes a consent.changed event onto an event bus. It then returns an acknowledgement or receipt payload to the UI, which can be rendered or delivered via SMS or email. To make this idempotent, every client call carries a client_request_id; the service ignores duplicates with the same ID.
Offline and assisted channels, such as branch counters, diagnostics labs, or call centres, should be treated as specialised front ends to the same consent service, not as separate consent systems. For tablet-based flows, the device interacts with the same APIs as your web or mobile applications, with appropriate fallback handling when connectivity is intermittent. For paper forms, the realistic pattern is a capture-and-digitise process where staff transcribe choices into a consent capture UI that again calls the central service, while scanned forms or photos are stored as evidence and linked via evidence_references. For telephonic consent, the contact centre system records the call, but the agent screen still drives the consent APIs; the call_id is stored as evidence, and a follow-up SMS or email can provide the Data Principal with a copy of their choices.
Downstream systems consume consent in two main ways. Some operations, such as sending an outbound campaign or sharing data with a new processor, can afford a real-time check against the central service; gateways or orchestration layers call a consent decision API before executing the action. Other operations, such as filtering datasets for analytics or restricting visibility in a CRM, often rely on a local cache for performance. In the latter case, downstream systems subscribe to consent.changed events and update local flags, such as marketing_opt_in or research_opt_out, keyed by subject_reference. The high-risk failure mode here is stale state after withdrawal; you mitigate that by designing consumers to treat withdrawal events as high-priority, by defining explicit propagation SLAs, and by periodically reconciling local flags against the central ledger.
Under DPDP’s purpose and storage limitation principles, you also need to design retention and deletion into the pipeline. An append-only consent ledger does not mean personal data lives forever. A common pattern is to separate a hot, fully joined ledger from a cold, minimally identifiable archive. As retention periods expire, you move old consent events into encrypted cold storage, remove or pseudonymise direct links to identity where legal obligations allow, and keep only what is necessary to demonstrate how you behaved during a given period. Embedded per-service consent flags are then recomputed or dropped from operational databases as appropriate, while the evidentiary ledger remains queryable for regulators and dispute resolution.
The strongest consent schema and pipeline still fail if they are not validated and monitored. Most DPDP-era incidents trace back to a small set of predictable failure modes, which can be made explicit and controlled rather than discovered during a regulator enquiry.
Common consent-record failure modes and technical mitigations.
Failure mode Impact Key technical controls
Missing or incorrect notice references Cannot prove what information was shown to the Data Principal at consent time; weakens the argument that consent was informed. Enforce referential integrity between consent records and a notice registry; make notice_id and notice_version non-nullable; expose them in decision APIs and internal queries.
Ambiguous or bundled purposes Difficult to show that consent was specific; one flag may cover heterogeneous processing activities that should have been separated. Require each consentable item in the UI to map to a single, stable purpose code; govern purpose catalogues jointly with legal and product; avoid reusing codes for new semantics.
Lost or delayed withdrawal propagation Data continues to be processed after a Data Principal has withdrawn consent; creates direct regulatory exposure and user complaints. Model consent as an append-only event stream; treat withdrawal events as idempotent but high-priority; define propagation SLAs to downstream systems; reconcile local flags against the central ledger.
Inconsistent consent state across channels Call-centre, branch, and digital channels disagree on whether consent exists; disputes are harder to resolve and audits find conflicting evidence. Centralise consent state computation in one service and ledger; treat channel-specific tables as read-only caches; always render UIs from the central state rather than local overrides.
In-place edits to consent records Audit trails become unreliable; it is hard to prove that records were not modified after the fact to match desired outcomes. Route all writes through services that append new events instead of updating rows in place; store logs in write-once or append-only storage; restrict direct database access and periodically verify hash chains or signatures on archives.
Each failure mode suggests concrete technical controls: schema constraints and referential integrity, purpose catalogue governance, append-only event models, a single source of truth for consent state, and immutable or write-once logging for integrity. Making these assumptions explicit in your APIs and storage layer reduces the chance that a quick fix in one channel silently reintroduces old risks. Turning these patterns into a validation matrix gives QA and SRE teams something concrete to execute during development and before major rollouts.
Example validation matrix for DPDP-focused consent operations.
Area Example test What to verify
Notice integrity Capture consent against a known notice version, then update the notice to a new version and capture more consents. Existing records continue to reference the original notice_version, new records reference the new version, and both versions remain retrievable with their checksums.
Purpose granularity Inspect a sample of consent records and associated UIs for multi-purpose checkboxes or flags. Each consentable UI element maps to a single stable purpose code and the recorded purpose_ids accurately reflect the choices that were visible to the Data Principal.
Withdrawal propagation Trigger withdrawals from each channel and trace them through the event bus into CRM, campaign tools, data exports, and other key systems. All downstream systems stop processing based on the old consent state within the agreed propagation window; any lag beyond that fails the test and is treated as an incident.
Cross-channel consistency Alternate grant and withdrawal operations from different channels for the same subject and purpose over a short period. The central ledger shows a coherent event history and a single current state; every channel UI renders that state and no channel writes its own independent consent flag.
Retention and deletion behaviour Create test consents with short retention periods and run retention jobs in a non-production environment. Consent records and associated evidence are moved, pseudonymised, or deleted according to policy, and the retention or deletion itself is logged for later audit.
To make these controls operational, treat consent validation and monitoring as a recurring engineering workflow, not a one-off compliance project.
  1. Map consent flows, risks, and systems
    Inventory all channels that capture consent, all systems that rely on consent state, and the legal bases involved. Identify high-risk flows such as marketing, data sharing with processors, and cross-border exports where failure modes would have the greatest impact.
  2. Encode schema and API invariants
    Express assumptions such as non-null notice references, one-to-one UI-to-purpose mappings, and append-only consent events as explicit invariants in schema constraints, API contracts, and unit tests for the consent service.
  3. Automate validation in CI and pre-production
    Build test suites that simulate granting, refusing, and withdrawing consent from each channel, then verify downstream behaviour using the validation matrix. Run these suites in CI and pre-production; block releases that regress on consent guarantees.
  4. Instrument metrics and alerts around consent operations
    Emit metrics for consent service latency and error rates, event bus backlogs, cache refresh patterns, withdrawal propagation times, and the share of records missing critical fields. Connect these to alerting thresholds that trigger investigation before issues reach regulators or Data Principals.
  5. Schedule reconciliation and retention checks
    Run regular jobs that compare downstream consent flags to the central ledger and verify that retention and deletion jobs have executed as configured. Treat discrepancies as operational incidents with clear owners and remediation paths.
In production, monitoring should track both technical health and compliance posture. On the technical side, observe consent service latency and error rates, event bus backlogs, and cache refresh metrics. On the compliance side, track indicators such as the proportion of consent records missing notice_version or evidence_references, the distribution of time from withdrawal to enforcement in key downstream systems, the number of processing attempts denied due to missing consent, and any divergence detected in periodic reconciliations between local flags and the central ledger. Retention and deletion jobs should also be monitored and tested so that consent records and associated evidence are retained, pseudonymised, or deleted in line with agreed schedules, and so that deletion itself is logged in an audit-friendly way.
Even with a solid schema and validation matrix, production systems will occasionally surface consent anomalies. Treat these as structured troubleshooting exercises that trace symptoms back to specific breaks in the consent pipeline or record model.
  • Campaigns continue after a Data Principal withdraws consent: check whether downstream systems subscribe to consent.changed events and specifically handle withdrawal. Inspect event bus metrics for dropped or backlogged events, confirm that CRM or marketing tools map withdrawal to the correct opt-out flags, and look for manual overrides or stale caches that bypass the central decision service.
  • UI and ledger show different consent states: verify that all UIs render state from the central consent service rather than local tables. Check cache time-to-live settings, confirm that idempotency keys are being sent so repeated submissions do not create conflicting events, and recompute the current state from the raw event history to see which view is wrong.
  • You cannot reconstruct which notice was shown during a dispute: audit the consent records for missing or invalid notice_id and notice_version fields, and verify that your notice catalogue retains historical versions with checksums. Fix UI integrations that fail to send notice references, and add schema constraints so such records cannot be written in future.
  • Duplicate consent records appear for the same subject and purpose: investigate how client_request_id or other idempotency keys are generated and enforced. Ensure the consent service treats duplicates for the same subject, purpose, and request ID as a single logical event. For historical data, write a migration that deduplicates events while preserving the original append-only history.
Digital Anumarti - Service positions itself as a DPDP-focused consent management and governance platform, externalising many of the consent record and receipt patterns described here. It is built around a central consent ledger, real-time consent tracking, event-driven propagation of consent state, multi-language consent capture, and audit-ready artefacts aligned with India’s Data Fiduciary and Data Principal concepts. In documented healthcare deployments, it has been used to digitise consent capture at the point of care, link consents to specific processor agreements, generate hashed consent receipts alongside clinical outputs, and ensure that withdrawals move data from active systems into encrypted retention stores instead of leaving them in operational flows.[6]
For technical evaluators deciding whether to build or buy, the key question is which parts of the consent lifecycle you want to own directly and which you are comfortable delegating to a DPDP-native platform. Digital Anumarti - Service can provide the consent ledger, receipt generation, and much of the integration scaffolding, while your engineering team focuses on embedding consent checks into business workflows and data pipelines. If you want to benchmark your in-house design against a production-tested DPDP consent architecture, you can review the platform details and technical documentation on the Digital Anumarti - Service site.

Where Digital Anumarti - Service already implements these consent patterns

Digital Anumarti - Service

1

Hashed consent receipts in diagnostic lab workflows

In one diagnostic labs deployment, Digital Anumarti - Service generates secure, hashed consent receipts that are provided alongside the final pathology report to demonstrate that patient data was processed under an explicit, recorded consent decision.

Why it matters for you

If your organisation sends laboratory results or similar outputs to multiple parties, this pattern shows how receipts can travel with the artifact and provide immediate evidence that sharing and profiling were covered by valid consent.

2

Linking consent to Data Processor agreements

Digital Anumarti - Service exposes APIs that bind each patient’s recorded consent to the specific Data Processor agreements in place with third-party testing facilities in a diagnostic network.

Why it matters for you

For complex B2B2C data flows, this linkage helps engineering teams enforce purpose limitation at integration points and makes it easier to explain processor responsibilities during DPDP audits.

3

Revocation pipelines that move data out of active systems

In a hospital deployment, when a patient revokes consent after discharge, Digital Anumarti - Service triggers a cascading update that moves the patient’s records from active operational databases into encrypted cold-storage retention logs, removing them from active processing while preserving them for medico-legal obligations.

Why it matters for you

This shows a practical pattern for handling DPDP withdrawals without breaking clinical record-keeping: operational systems stop using the data, but an evidentiary trail remains available for disputes and statutory retention.

4

API-driven consent ledger integrated with EHR systems

At a specialised clinic, Digital Anumarti - Service integrated an API-driven consent ledger with the Electronic Health Records system so that front-desk tablets could capture granular consent and map it directly to clinical workflows.

Why it matters for you

If your stack includes legacy clinical or line-of-business systems, this example demonstrates that a central consent ledger can be overlaid without rewriting the core application, while still eliminating paper forms and manual reconciliations.

5

Server-side preference centre tied to CRM platforms

In an elective healthcare deployment, Digital Anumarti - Service provided a server-side preference centre that used event-driven syncing and webhooks to immediately update CRM systems when individuals rejected marketing cookies or opted out of outreach.

Why it matters for you

This pattern reduces the risk that withdrawals are lost between your consent UI and outbound engagement tools, and gives engineering and marketing teams a clear handoff contract at the API and webhook layer.

6

Multilingual consent capture at the point of care

At a high-throughput clinic, Digital Anumarti - Service powered a multilingual consent capture interface in Hindi and English on front-desk tablets, with structured records written to the central consent ledger.

Why it matters for you

For Indian deployments where Data Principals interact in multiple languages, this shows how to keep the back-end schema and receipts stable while still presenting notices and purpose descriptions in the language most appropriate for the patient.

Evidence Healthcare diagnostics case study
Once the basic consent record and pipeline are defined, most engineering teams run into a recurring set of edge cases: how far to go in issuing Data Principal-facing receipts, how to structure multi-language notices, what to do about offline and assisted consent capture, how to handle children’s data, and how long to retain the resulting logs. These questions often do not have single right answers, because they depend on your risk appetite and the sectors you operate in, but there are engineering patterns that narrow the options.
The answers that follow focus on the implementation perspective: how to adjust your schema and event flows so that, whatever policy choices your legal and compliance colleagues make, your systems can enforce them consistently and produce defensible evidence if the DPDP Board or a Data Principal asks you to prove what happened.
FAQs

The DPDP Act and the DPDP Rules focus on your ability to demonstrate valid consent and honour withdrawals; they do not prescribe a specific technical format for consent receipts or explicitly require that you issue them to every Data Principal. What is essential is a reliable internal consent record and event history that can be produced and explained when challenged. Consent receipts, as described in ISO/IEC TS 27560 and the Kantara specification, are best viewed as a good practice that makes your records more interoperable and improves transparency to Data Principals. Many organisations start by hardening their internal consent ledger, then add a receipt layer for higher-risk flows or upon Data Principal request, using the same underlying schema. From an engineering standpoint, designing your internal records so that a standard-compliant receipt can be generated later is the safest approach, even if you do not initially expose receipts by default.

DPDP’s purpose and storage limitation principles mean you should not retain personal data, including consent logs and receipts, longer than necessary for the purposes for which it was processed and for any legal or regulatory obligations such as dispute-handling or statutory limitation periods. The exact duration depends on your sector and risk profile, so retention periods should be set with legal and compliance input, not only by engineering. From a system design perspective, it helps to separate three layers. The operational consent state, used for real-time decisioning, is retained as long as you rely on consent for processing. The evidentiary ledger, which records who consented to what and when, is typically retained for at least as long as you might reasonably face a challenge about that processing, and possibly longer if sectoral rules require it. Deep archives may then keep only pseudonymised or hashed artefacts that can still prove system behaviour without exposing full identity data. Whatever you choose, implement retention as explicit jobs that move or delete data, log those actions, and are tested regularly.

With India’s language diversity, it is common for Data Principals to interact with notices in Hindi, English, or regional languages while back-end systems operate in English. Your consent schema should therefore treat language as a first-class property. The notice registry should store a canonical notice definition and per-language variants with stable identifiers; each consent event must capture both the canonical notice_id and the language_code actually shown. Receipts can then render the notice summary and purpose descriptions in the chosen language while still embedding canonical identifiers and checksums that your systems understand. When you hash or sign receipts, include the language code and canonical notice checksum rather than the rendered text, so that small typographical or layout differences across languages do not break verification. For voice-based or assisted flows, you can treat the script version and language as you would a visual template, with the consent record pointing to the script identifier that was read out.

For offline and assisted channels, the key is to avoid creating separate, opaque consent systems. Front-desk tablets, kiosks, and agent desktops should act as clients of the same consent APIs that power your web and mobile flows, so that every consent event ends up in the central ledger with the same schema. When consent is captured on paper, staff should transcribe choices into a digital consent capture interface as soon as practical, linking the scanned form or photograph as an evidence_reference. For contact-centre scenarios, record the call according to your telephony and regulatory requirements, but treat the agent’s screen as the authoritative source of the structured consent event: it sends subject_reference, purposes, notice_version, and channel to the consent service, which writes the event and stores the call_id as evidence. Where you send follow-up OTPs or confirmations, log those as additional evidence items tied to the same consent_record_id. This pattern keeps your evidentiary story consistent even when the initial touchpoint is not digital self-service.

Processing children’s data usually attracts stricter scrutiny, and under DPDP it often requires verifiable consent from a parent or lawful guardian. Your consent schema needs to make this explicit. In the parties group, include fields such as subject_is_child, guardian_reference, and guardian_relationship, along with a verification_method indicating how you confirmed the guardian’s authority, for example via an OTP to a registered mobile number or cross-checks against existing account data. In the consent specifics group, you may need child_specific_purposes or flags indicating that certain purposes, such as targeted marketing, are disabled regardless of consent. Evidence references should point to whatever artefacts demonstrate parental consent, such as signed forms or recorded statements. Many organisations also choose shorter retention periods for identifiers in children’s consent records, pseudonymising or deleting direct identifiers earlier while keeping enough structure to prove that additional safeguards were applied.

Sources
  1. The Digital Personal Data Protection Act, 2023 - Government of India / IndiaCode
  2. Summary – Digital Personal Data Protection Rules, 2025 - Data Security Council of India (DSCI)
  3. Guide to the GDPR: Consent - Information Commissioner’s Office (ICO, UK)
  4. Consent Receipt Specification - Kantara Initiative
  5. ISO/IEC TS 27560:2023 – Privacy technologies — Consent record information structure - International Organization for Standardization (ISO) / IEC
  6. Promotion page

Related pages

Updated At May 18, 2026

What Evidence Do You Need to Defend Consent before the DPB?

Executive guide for Indian leadership teams on evidence needed to prove valid consent under the DPDP Act before the Data Protection Board and how to embed it into operations.

 Updated At May 20, 2026

Database Schema Design for Consent Artifacts and Purpose Metadata

A technical guide for Indian engineering leaders on designing database schemas for consent artifacts and purpose metadata under the DPDP Act, RBI Account Aggregator-style consents, and audit-ready consent operations.

 Updated At Apr 18, 2026

Reference Architecture: From Consent Banner to Consent Ledger

A business-style technical guide for technical evaluators that covers reference architecture— from consent banner to consent ledger, implementation details, and

 Updated At Apr 18, 2026

Building a Consent-Aware API

A business-style technical guide for technical evaluators that covers building a consent-aware api, implementation details, and the controls needed for

 Updated At May 31, 2026

Consent Token vs JWT: Designing Permission-Aware Systems

For Indian B2B engineering leaders: a practical comparison of consent tokens vs JWT claims, and how to design DPDP-aligned, permission-aware architectures with revocation, purpose limitation, and auditability.

 Updated At Apr 18, 2026

Log Retention, Deletion, and Audit Trails: Building an Evidence Program

A business-style piece for technical evaluators that explains log retention, deletion, and audit trails— building an evidence program and turns policy

 Updated At Apr 18, 2026

Retail Audit Trail: Evidence across Web, App, Support, and Stores

A business-style article for technical evaluators focused on retail audit trail— evidence across web, app, support, and stores so retail and D2C teams can grow

 Updated At Apr 18, 2026

Consent Logging for Regulated Financial Services

A business-style article for technical evaluators about consent logging for regulated financial services, aimed at regulated finance teams balancing customer

 Updated At Apr 18, 2026

Versioning Privacy Policies and Re-Consent Flows

A business-style technical guide for technical evaluators that covers versioning privacy policies and re-consent flows, implementation details, and the controls

 Updated At May 20, 2026

Testing DPDP Consent Flows: A QA Checklist

Turn India’s DPDP Act consent rules into testable behaviours. A technical QA checklist, consent state machine, and validation matrix for defensible consent operations.