Building a DPDP-Compliant Consent Record Store

What DPDP Section 6 Requires

DPDP Section 6(1) requires consent to be 'free, specific, informed, unconditional and unambiguous'. Translated to technical requirements: free — no pre-ticked boxes or dark patterns; specific — separate consent per purpose; informed — consent notice must describe what data, for what purpose, for how long; unconditional — conditional access based on non-essential consent is prohibited; unambiguous — a positive act (tick box, button click), not inaction.

Section 6(4) requires consent to be withdrawable as easily as it was given. Your consent record store must support revocation, propagate revocation to all downstream processors, and give the data principal evidence that revocation was processed.

Consent Record Schema

Minimum fields: consent_id (UUID), user_id, purpose_id, data_categories (array), consent_given_at (UTC timestamp), consent_method (registration_form / in-app-prompt / api-sdk), notice_version, ip_address, expiry_at (if time-limited), revoked_at (null if active), revocation_reason.

Extended fields for AI use cases: model_id (which AI model is being authorised), feature_id (which app feature the consent covers), session_id (for session-scoped consent), derived_purposes (list of secondary purposes that inherit from this consent). The session_id linkage lets you prove that a specific AI session was covered by a valid consent record.

API Patterns for Consent

POST /consent — create a new consent record. Must be called synchronously before any personal data processing begins. Returns consent_id that must be attached to all subsequent data processing events. GET /consent/{user_id} — return all consent records for a user (for DSR access requests). DELETE /consent/{consent_id} — revoke consent; must propagate a revocation event to all processors registered for this purpose. GET /consent/valid/{user_id}/{purpose_id} — check if valid, non-revoked consent exists for this user and purpose. Called by your AI gateway before processing each request.

The gateway integration: CrewCheck can call your consent validation API as a pre-processing step. If no valid consent is found for the session's purpose, the request is blocked before reaching the LLM.

Compliance operational checklist

Building a DPDP-Compliant Consent Record Store should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.

For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.

A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.

This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.