Consent Database Schema: SQL, JSONB, ERD and Audit Queries
Copyable PostgreSQL and JSONB patterns for versioned purposes, guardian consent, immutable events, tombstones, fast indexes, audit queries and safe migration.
The DPDP Act does not prescribe one database schema. A robust design separates principals, guardians, notices, purposes, artifacts, purpose-level decisions, immutable events and processing-decision logs.
Version purpose and notice definitions instead of overwriting them. Each consent event should point to the exact versions that existed when the choice was captured.
Use partial indexes for current grants, unique version/idempotency constraints, event-time indexes and targeted JSONB GIN indexes; do not index every evidence field by default.
Model guardian authority explicitly, and use tombstones or unlinking workflows to erase identity links without silently destroying justified non-identifying audit structure.
Current status (29 August 2026): DPDP definitions are in force, while substantive consent, children’s-data and related operational duties are scheduled around May 2027. RBI Account Aggregator artefacts apply only in their sectoral scope.
Consent schema: answer first and current status
A single opt-in boolean cannot reconstruct a consent-dependent processing decision. Store a versioned consent artifact plus purpose-level items and immutable events that identify the principal or tombstone token, accountable fiduciary, optional guardian or representative, notice and purpose versions, data scope, choice, validity, channel, evidence reference, and grant or withdrawal timeline.
Current-status note (29 August 2026): the DPDP Act’s definitions are in force. Substantive consent, notice, withdrawal and children’s-data provisions and most operational Digital Personal Data Protection Rules, 2025 are scheduled for the 18-month commencement tranche, around May 2027. Design now, but confirm official notifications before treating a duty or date as operative. No official SQL or JSON schema is mandated.
Keep sectoral models scoped correctly. RBI Account Aggregator consent artefacts are structured, machine-readable records for the regulated AA ecosystem; they are a useful reference, not a universal DPDP database specification. Apply RBI, health or other sector rules only where the product and entity fall within their scope.
ERD entities and relationships
The ERD should make ownership and history explicit: principal 1—N consent_artifact; guardian principal 0—N consent_artifact; notice 1—N notice_version; purpose 1—N purpose_version; consent_artifact 1—N consent_item; consent_item N—1 purpose_version; consent_artifact 1—N consent_event; and processing_decision N—1 consent_item or another documented lawful-basis record.
Keep legal entities, systems, processing activities, data categories and recipients as separate catalogues linked by versioned relationship tables. This prevents a later rename or scope change from rewriting historical meaning. Include effective_from/effective_to and provenance on each catalogue version.
Use immutable identifiers for events and versions, but avoid direct identifiers as primary keys. principal.subject_ref should be a tenant-scoped pseudonymous reference. When an identity link must be erased, move to a controlled tombstone workflow rather than replacing the entire audit chain with a fictional consent state.
Mapping DPDP and RBI consent concepts to core schema entities.
Regulatory or domain concept |
Schema representation |
Notes |
|---|---|---|
Data principal |
principal table with stable identifiers and status |
Links to consent artifacts, processing events, and rights requests. |
Data fiduciary |
organisation / data_fiduciary table and relationships to systems and processing activities |
Captures which legal entity is responsible for processing under each purpose. |
Data processor |
data_processor table and join table linking processor agreements to processing activities and systems |
Enables queries such as which processors are authorised for a given purpose and dataset. |
Consent |
consent_artifact (header), consent_item (line items), and consent_event_log (history) |
Separates interaction-level artefacts from per-purpose decisions and time-ordered events. |
Specified purpose |
purpose table with code, description, category, lawful basis, and policy references |
Referenced by consent_item, processing_activity, and retention_policy mappings. |
Withdrawal of consent |
withdraw events in consent_event_log plus status and valid_to changes on consent_item |
Supports both historical reconstruction and fast current-state checks for can_process. |
Consent manager / Account Aggregator |
consent_manager table referenced from consent_artifact and event log, with AA-specific extension fields where needed |
Allows your systems to distinguish direct consents from those mediated by consent managers or AAs without changing decision logic. |
Copyable PostgreSQL and JSONB schema
The SQL below is an illustrative PostgreSQL starting point: normalized columns carry fields used for constraints and fast decisions, while JSONB stores bounded evidence snapshots and extension data. Adapt types, partitioning, tenancy, row-level security, encryption, key management and retention to your workload; do not paste it into production without review.
PostgreSQL schema, JSONB event, indexes and audit queries
-- Illustrative PostgreSQL 15+ schema. Review tenancy, RLS, encryption and retention.
CREATE TABLE principal (
tenant_id uuid NOT NULL,
id uuid NOT NULL,
subject_ref text NOT NULL,
is_child boolean NOT NULL DEFAULT false,
guardian_principal_id uuid,
status text NOT NULL CHECK (status IN ('ACTIVE', 'TOMBSTONED')),
created_at timestamptz NOT NULL DEFAULT now(),
tombstoned_at timestamptz,
PRIMARY KEY (tenant_id, id),
UNIQUE (tenant_id, subject_ref),
FOREIGN KEY (tenant_id, guardian_principal_id)
REFERENCES principal (tenant_id, id),
CHECK (guardian_principal_id IS NULL OR guardian_principal_id <> id)
);
CREATE TABLE principal_tombstone (
tenant_id uuid NOT NULL,
subject_tombstone_token text NOT NULL,
erased_at timestamptz NOT NULL,
erasure_reason text NOT NULL,
erasure_job_id text NOT NULL,
legal_hold boolean NOT NULL DEFAULT false,
PRIMARY KEY (tenant_id, subject_tombstone_token)
);
CREATE TABLE notice_version (
tenant_id uuid NOT NULL,
id uuid NOT NULL,
notice_id uuid NOT NULL,
version integer NOT NULL CHECK (version > 0),
language_code text NOT NULL,
content_sha256 bytea NOT NULL,
effective_from timestamptz NOT NULL,
effective_to timestamptz,
PRIMARY KEY (tenant_id, id),
UNIQUE (tenant_id, notice_id, version)
);
CREATE TABLE purpose_version (
tenant_id uuid NOT NULL,
id uuid NOT NULL,
purpose_id uuid NOT NULL,
version integer NOT NULL CHECK (version > 0),
purpose_code text NOT NULL,
description text NOT NULL,
lawful_basis text NOT NULL,
effective_from timestamptz NOT NULL,
effective_to timestamptz,
policy jsonb NOT NULL DEFAULT '{}'::jsonb,
PRIMARY KEY (tenant_id, id),
UNIQUE (tenant_id, purpose_id, version)
);
CREATE TABLE consent_artifact (
tenant_id uuid NOT NULL,
id uuid NOT NULL,
principal_id uuid,
subject_tombstone_token text,
guardian_principal_id uuid,
guardian_authority_ref text,
notice_version_id uuid NOT NULL,
consent_version bigint NOT NULL CHECK (consent_version > 0),
event_type text NOT NULL CHECK (event_type IN
('GIVEN','REFUSED','WITHDRAWN','EXPIRED','LEGACY_IMPORTED')),
previous_artifact_id uuid,
captured_at timestamptz NOT NULL,
effective_at timestamptz NOT NULL,
channel text NOT NULL,
idempotency_key text NOT NULL,
evidence jsonb NOT NULL DEFAULT '{}'::jsonb,
payload_sha256 bytea NOT NULL,
created_at timestamptz NOT NULL DEFAULT now(),
PRIMARY KEY (tenant_id, id),
UNIQUE (tenant_id, idempotency_key),
UNIQUE (tenant_id, principal_id, consent_version),
FOREIGN KEY (tenant_id, principal_id) REFERENCES principal (tenant_id, id),
FOREIGN KEY (tenant_id, guardian_principal_id) REFERENCES principal (tenant_id, id),
FOREIGN KEY (tenant_id, notice_version_id) REFERENCES notice_version (tenant_id, id),
FOREIGN KEY (tenant_id, previous_artifact_id) REFERENCES consent_artifact (tenant_id, id),
FOREIGN KEY (tenant_id, subject_tombstone_token)
REFERENCES principal_tombstone (tenant_id, subject_tombstone_token),
CHECK (num_nonnulls(principal_id, subject_tombstone_token) = 1)
);
CREATE TABLE consent_item (
tenant_id uuid NOT NULL,
id uuid NOT NULL,
artifact_id uuid NOT NULL,
purpose_version_id uuid NOT NULL,
status text NOT NULL CHECK (status IN ('GIVEN','REFUSED','WITHDRAWN','EXPIRED')),
valid_from timestamptz NOT NULL,
valid_to timestamptz,
data_category_ids text[] NOT NULL DEFAULT '{}',
resource_scope jsonb NOT NULL DEFAULT '{}'::jsonb,
PRIMARY KEY (tenant_id, id),
UNIQUE (tenant_id, artifact_id, purpose_version_id),
FOREIGN KEY (tenant_id, artifact_id) REFERENCES consent_artifact (tenant_id, id),
FOREIGN KEY (tenant_id, purpose_version_id) REFERENCES purpose_version (tenant_id, id),
CHECK (valid_to IS NULL OR valid_to > valid_from)
);
CREATE TABLE consent_event (
tenant_id uuid NOT NULL,
event_id uuid NOT NULL,
artifact_id uuid NOT NULL,
event_type text NOT NULL,
effective_at timestamptz NOT NULL,
actor_ref text NOT NULL,
idempotency_key text NOT NULL,
payload jsonb NOT NULL,
PRIMARY KEY (tenant_id, event_id),
UNIQUE (tenant_id, idempotency_key),
FOREIGN KEY (tenant_id, artifact_id) REFERENCES consent_artifact (tenant_id, id)
);
CREATE TABLE processing_decision (
tenant_id uuid NOT NULL,
decision_id uuid NOT NULL,
principal_id uuid,
subject_tombstone_token text,
purpose_version_id uuid NOT NULL,
consent_item_id uuid,
request_or_job_id text NOT NULL,
decision text NOT NULL CHECK (decision IN ('ALLOW','DENY')),
reason_code text NOT NULL,
policy_version text NOT NULL,
decided_at timestamptz NOT NULL,
PRIMARY KEY (tenant_id, decision_id)
);
-- Decision-path and audit indexes; add only after checking real query plans.
CREATE INDEX consent_item_active_lookup
ON consent_item (tenant_id, purpose_version_id, valid_from)
WHERE status = 'GIVEN' AND valid_to IS NULL;
CREATE INDEX consent_artifact_principal_timeline
ON consent_artifact (tenant_id, principal_id, effective_at DESC);
CREATE INDEX consent_event_artifact_timeline
ON consent_event (tenant_id, artifact_id, effective_at, event_id);
CREATE INDEX processing_decision_audit
ON processing_decision (tenant_id, principal_id, purpose_version_id, decided_at DESC);
CREATE INDEX consent_item_scope_gin ON consent_item USING gin (resource_scope);
-- Copyable JSONB event example: schema and catalogue versions remain explicit.
INSERT INTO consent_event
(tenant_id, event_id, artifact_id, event_type, effective_at, actor_ref, idempotency_key, payload)
VALUES
('11111111-1111-1111-1111-111111111111',
'22222222-2222-2222-2222-222222222222',
'33333333-3333-3333-3333-333333333333',
'GIVEN', now(), 'subject:sub_hmac_72d9', 'capture:web:01J6Z8',
'{"schema_version":1,"consent_version":7,"notice_version":4,
"purpose_versions":[{"purpose_code":"marketing.sms","version":3}],
"guardian":{"required":false,"authority_ref":null},
"evidence":{"uri":"vault://evt/01J6Z8","sha256":"5ac2..."}}'::jsonb);
-- Audit 1: ALLOW decisions after a withdrawal became effective.
SELECT d.*
FROM processing_decision d
JOIN consent_item i ON i.tenant_id = d.tenant_id AND i.id = d.consent_item_id
WHERE d.decision = 'ALLOW'
AND i.status = 'WITHDRAWN'
AND d.decided_at >= i.valid_to;
-- Audit 2: gaps or forks in the per-principal consent-version chain.
WITH ordered AS (
SELECT tenant_id, principal_id, id, consent_version, previous_artifact_id,
lag(id) OVER (PARTITION BY tenant_id, principal_id ORDER BY consent_version) AS expected_previous,
lag(consent_version) OVER (PARTITION BY tenant_id, principal_id ORDER BY consent_version) AS previous_version
FROM consent_artifact WHERE principal_id IS NOT NULL
)
SELECT * FROM ordered
WHERE (previous_version IS NOT NULL AND consent_version <> previous_version + 1)
OR (previous_version IS NOT NULL AND previous_artifact_id IS DISTINCT FROM expected_previous);
-- Tombstoning should run in one controlled transaction:
-- 1) insert principal_tombstone, 2) relink justified artifacts to its token,
-- 3) delete or unlink the principal, 4) record the erasure job and verification result.Illustrative PostgreSQL 15+ starting point with normalized decision fields, bounded JSONB evidence, guardian references, tombstones, version and idempotency constraints, partial/GIN indexes, and two audit queries. It is intentionally incomplete for production: add row-level security, encryption, partitioning, key management, retention jobs and tested migration scripts for your environment.
A consent artifact is the immutable event header. It points to principal or subject_tombstone_token, optional guardian_principal_id and guardian_authority_ref, notice_version_id, event and consent versions, timestamps, channel, evidence digest and previous artifact. Require guardian fields only when policy says a guardian is needed, and keep verification evidence behind an access-controlled reference.
A consent item records one purpose-version decision and validity window. Derive current state from the latest committed event or maintain a transactionally consistent projection; never mutate an old grant into a withdrawal. Use unique principal/purpose/version or idempotency constraints to prevent forked chains and duplicate retries.
Purpose versioning, indexes and retention
Represent purpose as a stable identity plus immutable purpose_version rows containing the exact machine code, human text, language, lawful-basis configuration, data scope, recipients and effective dates. A new description or scope creates a new version; historical artifacts keep their original purpose_version_id.
Keep data categories and processing activities separate and versioned. A risk label or sectoral classification can guide controls, but the DPDP Act does not create a general “sensitive personal data” category. Link only the categories, operations, systems and recipients actually relevant to each purpose version.
Index decision paths, not every column: partial B-tree indexes for active grants; composite indexes on tenant/principal/purpose_version; event indexes on artifact and effective_at; unique idempotency and monotonic-version constraints; and a targeted GIN index only for JSONB keys you genuinely query. Partition high-volume event and decision logs by time or tenant after measuring access patterns.
Events, tombstones and audit queries
Maintain an append-only event log and a current-state projection. Events such as GIVEN, REFUSED, WITHDRAWN, EXPIRED, PURPOSE_SUPERSEDED, NOTICE_SUPERSEDED, GUARDIAN_CHANGED, TOMBSTONED and LEGACY_IMPORTED carry effective time, actor, prior version, payload digest and idempotency key.
Use tombstones to separate identity erasure from event integrity. A tombstone should contain a non-reversible, tenant-scoped token, erased_at, erasure_reason, legal_hold flag if justified, and the job or request that performed unlinking. It must not permit ordinary re-identification or become an excuse for indefinite retention.
On withdrawal, append version N+1, close the relevant consent_item validity, update the projection in the same transaction, publish an outbox event, invalidate downstream caches and record enforcement acknowledgements. Audit queries should detect ALLOW decisions after withdrawal, missing version links, duplicate versions, orphan guardians, artifacts without notice versions and purposes still using superseded definitions.
Common failure modes in consent operations and how schema design can mitigate them.
Failure mode |
How it appears in systems |
Schema and control mitigations |
|---|---|---|
Orphaned processing events |
Logs in operational systems (CRM, EHR, marketing tools) record personal-data processing with no consent_artifact_id or purpose_id reference. |
Require a consent reference or explicit lawful-basis code on any personal-data processing event at write time; enforce foreign keys from processing logs to consent artifacts and purposes where feasible. |
Inconsistent state between event log and current tables |
Current consent tables show active grants while the event log indicates later withdrawals, often due to ad-hoc SQL updates or partial backfills. |
Restrict direct writes to current-state tables; route all changes through services that also append to consent_event_log; schedule reconciliations that detect mismatches and rebuild current views from the log when needed. |
Retention drift |
Data remains in analytics stores, archives, or partner systems long after promised retention periods because policies live only in documents, not in the schema. |
Model retention_policy explicitly and link it to purposes and data categories; store resolved policy keys and expiry timestamps per principal and dataset so deletion and archiving jobs can act on structured criteria rather than free-text policy documents. |
Race conditions around revocation |
Marketing campaigns, model scoring, or data exports continue for some period after a principal withdraws consent because downstream systems rely on cached flags or batch syncs. |
Design can_process checks to query indexed current-state consent tables rather than long-lived caches; propagate revocation events via a message bus and ensure downstream systems reconcile their local views against the consent service before high-risk processing. |
Validation and processing-decision logging
At decision time, derive the purpose and operation from server-controlled metadata; select the exact current purpose version; resolve a consent item or another documented basis; validate tenant, principal or tombstone state, guardian requirements, notice and purpose versions, data scope, validity and withdrawal; and write an ALLOW or DENY decision with a stable reason code.
A decision log should capture request or job id, tenant, principal or tombstone token, purpose_version_id, processing_activity_id, system and recipient, data categories, basis, consent item and version, decision, reason, policy version and decided_at. Do not log raw evidence or complete bearer tokens.
Illustrative validation matrix: operations mapped to key consent and purpose checks.
Operation type |
Examples of required checks before allowing processing |
|---|---|
collect |
Principal identity resolvable; specified purpose defined and present in schema; notice_version_id resolvable for the interaction; retention_policy resolved and stored alongside consent; grant or refusal recorded in consent_artifact, consent_item, and consent_event_log. |
use_for_marketing |
Purpose exists and is flagged as consent-based; active consent_item covers principal_id, purpose_id, system_id, and current time; data categories requested are a subset of those allowed for the purpose; no withdrawal event exists after the proposed processing time; child principals have corresponding guardian consent where required. |
share_with_regulator |
Purpose and processing_activity mapped to a legitimate use or legal-obligation basis; regulator system_id is in the set of systems mapped to the purpose; data categories restricted to those necessary for compliance; export event logged with resolved lawful basis and retention expectations. |
export_cross_border |
Cross-border processing_activity defined and linked to the purpose; destination region and system_id allowed for that purpose; lawful basis for transfer resolved; data residency rules checked; transfer event appended to consent_event_log with destination metadata for later review. |
The SQL example includes schema, JSONB evidence, indexes and audit queries. Keep application decision logic in a reviewed policy layer; SQL constraints prevent invalid states, but they cannot determine whether a notice or consent experience was legally sufficient.
Default deny for consent-dependent processing when the purpose is unknown, the version chain is broken, consent is missing/withdrawn/expired, guardian requirements fail or authoritative state is unavailable. Distinguish that from operations relying on another valid basis; do not manufacture consent to make a workflow pass.
Migration checklist for existing systems
Migrate in stages: inventory every legacy flag and consumer; create versioned notice and purpose catalogues; import legacy values as LEGACY_IMPORTED with source and evidence quality—never as newly proven consent; generate deterministic idempotency keys; dual-write and reconcile; run the new decision service in observe-only mode; backfill in repeatable batches; cut consumers over by purpose; monitor drift; then retire old flags. Keep rollback scripts and a mapping table from legacy ids to new artifacts.
Use a staged rollout so that CRMs, marketing tools, data platforms, and sectoral systems converge on the same consent and purpose interpretation instead of adding yet another flag store.
-
Inventory systems and map data flows
Identify all applications that collect or process personal data, the purposes and processing activities they implement, and the data categories they touch. Document where identifiers, consents, and notices are currently stored so you know which systems will need migration or integration work.
-
Map activities into purposes, processing activities, and systems
For each real-world operation (for example, sending transactional SMS, running a recommendation model, sharing lab results, or exporting statements to an Account Aggregator), assign a purpose_id, processing_activity_id, and system_id in your schema. This gives you a deterministic way to ask what authorises any given operation on any system.
-
Wrap entry points with consent capture and decision APIs
Place a consent-aware facade in front of external-facing entry points such as APIs, web forms, mobile SDKs, and partner integrations. These components should write consent_artifact and consent_item rows when new permissions are requested, and call a central can_process API before any operation that uses or shares personal data beyond core service needs.
-
Route CRM and marketing decisions through the consent service
Instead of letting each CRM or marketing platform maintain its own interpretation of who is contactable, have those systems supply principal identifiers and operation types (such as use_for_marketing) to the consent service. The service responds with the set of principals that currently satisfy consent and purpose constraints, reducing the risk of stale or divergent audience definitions.
-
Align data platforms and sectoral systems with the consent ledger
In data lakes and warehouses, keep only foreign keys to consent and purpose tables and expose authorised views that join fact tables with consent dimensions rather than copying flags. In BFSI stacks, ensure Account Aggregator flows record RBI-style consent artifacts using the same schema, and require a valid AA consent reference before data pulls. In healthcare, wire EHR and lab systems to call the consent service for operations such as sharing reports with external doctors or research partners. Add monitoring that compares processing events in operational logs against expected consent state and raises alerts where gaps appear.
Troubleshooting consent schema issues in production
Even with a sound design, consent services often fail at the seams between systems. The quickest way to stabilise operations is to treat recurring symptoms as signals about gaps in identifiers, constraints, or decision wiring rather than as isolated bugs.
Symptom: processing logs contain events with no consent reference. Check that producers are always writing a consent_artifact_id and purpose_id (or an explicit lawful-basis code) for personal-data operations, and add database constraints or middleware guards so writes without these fields are rejected rather than silently accepted.
Symptom: different tools disagree on whether a principal has opted into marketing. Verify that only the central consent service can change consent state and that CRMs or marketing platforms no longer edit local opt-in flags. Backfill by recalculating audiences from current consent_item rows instead of trusting per-system fields.
Symptom: can_process checks slow down high-traffic flows. Inspect query plans for lookups on consent_item, purpose, and retention_policy, add indexes on principal_id, purpose_id, system_id, and validity windows, and consider precomputing current-state tables from the event log so run-time checks avoid scanning long histories.
Symptom: migration of legacy consents created overlapping active and withdrawn records. Run reconciliation jobs that rebuild current-state from consent_event_log ordered by effective_at, enforce non-overlapping validity windows per principal and purpose, and quarantine ambiguous artifacts for manual or legal review instead of auto-enabling processing.
Common questions about DPDP-ready consent schema design
Once you start sketching actual tables and integrating them into systems, a set of recurring questions tends to surface. Many revolve around edge cases that DPDP and sectoral regulations explicitly call out: handling children’s data and guardian consent, representing offline or legacy consents, dealing with derived or aggregated data when consent changes, or modelling cross-border transfers as distinct purposes and processing activities.
The encouraging pattern is that most of these questions can be answered within the same structural approach described earlier: treat each special case as additional metadata and relationships rather than custom code paths. Children’s data can be modelled by linking principals to guardian principals and constraining purposes; offline consents can be ingested as artifacts with different evidence fields; cross-border transfers can be expressed as separate processing activities bound to explicit purposes and lawful bases. The more of these scenarios your schema can represent explicitly, the less guesswork remains in application code and the easier it is to demonstrate to auditors how your systems arrived at a particular processing decision.
Using Digital Anumati - Service as a consent infrastructure layer
Building and operating a consent schema, decision engine, and integration layer in-house is feasible for many teams, but the burden increases with the number of systems, sectoral regulations, and high-availability requirements. At a certain point, it becomes attractive to treat consent management as shared infrastructure with clear APIs, schema guarantees, and audit capabilities, rather than a collection of ad-hoc tables inside multiple applications. This is where platforms such as Digital Anumati - Service enter the architecture as a dedicated consent and privacy operations layer designed for the DPDP Act and Indian sectoral contexts.[6]
If you are evaluating whether to externalise this layer, it is worth reviewing Digital Anumati - Service against the schema and control patterns outlined here, and mapping how its APIs, data model, and audit features would plug into your CRMs, sectoral systems, and data platforms. For a deeper technical review, you can explore the documentation and implementation guides available on the Digital Anumati - Service site, and add a structured assessment of its fit to your technical due diligence pipeline alongside any in-house build or extension options you are considering.
How Digital Anumati - Service already implements consent-schema patterns
Hashed consent receipts for diagnostic lab reports
Digital Anumati - Brand documents a diagnostic labs deployment where Digital Anumati - Service generates secure, hashed consent receipts that are delivered alongside the final pathology report to demonstrate that data processing is tied to a specific consent artefact.
Why it matters for you
This shows how consent identifiers and integrity proofs can be surfaced directly in downstream artefacts, making it easier for your teams to demonstrate lawful processing for B2B2C lab workflows during DPDP-style audits.
Consent linked to specific processor agreements
Digital Anumati - Brand describes APIs for diagnostic networks that link each patient’s consent directly to the data processor agreements in place with third-party testing facilities.
Why it matters for you
Binding consent artifacts to explicit processor contracts provides a concrete schema pattern for separating data fiduciary and data processor responsibilities while still enforcing purpose limitation at integration boundaries.
API-driven consent ledger integrated with EHR
Digital Anumati - Brand reports a GastroLiver Clinic deployment where an API-driven consent ledger is integrated with the Electronic Health Records system to digitise consent capture and map artifacts directly to clinical records.
Why it matters for you
This demonstrates how an external consent ledger can function as the single source of truth for treatment and secondary-use decisions in high-throughput healthcare environments without relying on paper forms or ad-hoc flags inside the EHR.
Revocation pipeline to encrypted cold storage
Digital Anumati - Brand describes a Khanna Hospital deployment where a patient’s consent revocation triggers a pipeline that moves the patient’s records from active operational databases into encrypted cold-storage retention logs while preserving medico-legal records.
Why it matters for you
This is a concrete example of how a consent event (withdrawal) can drive automated data movement that respects both erasure expectations and sectoral retention obligations, using schema-visible states rather than manual procedures.
Server-side preference centre integrated with CRM
Digital Anumati - Brand highlights a V Care Clinics deployment where a server-side preference centre uses event-driven syncing and webhooks to update Salesforce or HubSpot when patients reject marketing cookies or opt out, immediately halting automated WhatsApp and email campaigns.
Why it matters for you
This pattern illustrates how to keep CRMs and outreach tools aligned with central consent state so that marketing operations act only on principals who currently satisfy purpose and lawful-basis checks.
Model the child and guardian as separate principals linked by a versioned guardian_authority record. Store guardian_principal_id, relationship or authority reference, verification method, valid_from/valid_to and evidence reference on the relevant artifact; do not put full identity evidence in the portable payload. Keep date of birth only when necessary—an age-band or verified child-status result may be enough. As of 29 August 2026, the substantive child-data provisions are scheduled around May 2027, subject to official commencement and any notified exemptions.
Import legacy material with event_type LEGACY_IMPORTED, source record id, imported_at, migration batch, evidence location and an evidence-quality enum. Map only purposes and notice text that are actually supported. Ambiguous values should remain UNKNOWN or UNVERIFIED, not be converted into new consent or a false refusal. Use deterministic idempotency keys, reconcile counts and hashes, run dual reads, and preserve a mapping from each legacy record to the new artifact.
From a schema perspective, derived data needs its own lineage metadata. One approach is to have datasets, features, or models represented as entities with links back to the purposes, data categories, and processing activities that justified their creation. When a principal withdraws consent for a purpose that fed into a dataset or model, you can mark that principal’s contributions as no longer eligible for future processing tied to that purpose. Technically, you might filter them out of new training runs, exclude them from personalised recommendations, or flag their records for deletion in analytical stores when retention permits. The key is that your consent and purpose schema should let you answer which high-level purposes and operations a dataset supports; your governance process then decides, in consultation with legal and data science teams, whether a given withdrawal requires retraining, incremental adjustment, or operational safeguards around how derived artefacts are used.
The DPDP Act does not impose a blanket localisation rule; the Central Government may restrict transfers to notified countries or territories, and sectoral rules can add separate requirements. Model destination country, recipient, system, transfer operation, applicable restriction or sector rule, purpose_version and lawful basis. Do not assume every transfer needs a separate consent purpose; apply the notice, purpose and basis analysis appropriate to the actual processing and verify current notifications.
Using JSON or other document formats can be useful for capturing the full consent artefact, especially when regulatory specifications evolve. However, relying solely on opaque blobs without structured fields usually makes enforcement and auditability difficult. A better design is to store the complete artefact as a JSON or document column for fidelity, while also materialising key fields into relational columns: principal_id, purpose_ids, data categories, validity window, notice_version_id, channel, actor, consent_manager_id, and hashes or signatures. Index these relational fields so that decision logic and auditors can query consent by principal, purpose, system, and time without parsing blobs at scale. This hybrid approach lets you evolve artefact structures over time while preserving the performance, integrity constraints, and transparency needed for DPDP and sectoral audits.
- Digital Anumati DPDP Act Consent Management Solution - Digital Anumati
- The Digital Personal Data Protection Act, 2023 - Ministry of Electronics and Information Technology, Government of India
- Master Direction – Non-Banking Financial Company – Account Aggregator (Reserve Bank) Directions, 2016 - Reserve Bank of India
- Digital Personal Data Protection Rules, 2025 - Ministry of Electronics and Information Technology, Government of India
- DPDP Act commencement notification (13 November 2025) - Ministry of Electronics and Information Technology, Government of India
- Implementing ISO/IEC TS 27560:2023 Consent Records and Receipts for GDPR and DGA - arXiv.org
