Engineering for the India DPDP Act (2026): Architecture, PostgreSQL Schemas & Consent Lifecycles

1. Overview of India’s Digital Personal Data Protection Act (DPDPA 2026)

The Digital Personal Data Protection Act (DPDPA) represents a monumental shift in how organizations manage personal data in India. While it shares conceptual similarities with the EU GDPR, the DPDPA introduces distinct engineering mandates for Data Fiduciaries (controllers) and Data Processors. The rules enacted in 2026 demand robust architecture capable of granular consent logging, localized breach escalation, and automated data purging lifecycles.

For developers, complying with the DPDPA translates to implementing itemized and verifiable consent tracking, rigorous verifiable parental consent (VPC) mechanisms, and immutable audit trails that can facilitate Data Protection Board (DPB) investigations within strict SLAs. This guide provides actionable technical patterns to satisfy the six critical DPDP mandates mapped in our interactive matrix.

2. Implementing Itemized, Multilingual Consent Tracking (dpdp-1)

Section 6 of the DPDP Act mandates that consent must be free, specific, informed, unconditional, and unambiguous with a clear affirmative action. Additionally, Data Fiduciaries must provide the consent notice in English and all 22 languages specified in the Eighth Schedule of the Indian Constitution.

To satisfy itemized consent logging, developers must transition from boolean has_consented columns to structured JSON/JSONB logging or relational models that track the specific purpose, timestamp, and language served.

PostgreSQL Schema for Multilingual Itemized Consent

View the Multilingual Consent Reference Implementation on our GitHub

CREATE TABLE user_consents (
    consent_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID REFERENCES users(id),
    purpose_id VARCHAR(50) NOT NULL, -- e.g., 'marketing_email', 'telemetry_data'
    consent_status BOOLEAN NOT NULL,
    granted_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    revoked_at TIMESTAMPTZ,
    ip_address INET NOT NULL,
    user_agent TEXT,
    notice_version VARCHAR(20) NOT NULL, -- Ties to the specific legal text revision
    notice_language VARCHAR(5) NOT NULL, -- ISO 639-1/2 code (e.g., 'hi', 'ta', 'en')
    CONSTRAINT unique_active_consent UNIQUE (user_id, purpose_id)
);

CREATE INDEX idx_user_consents_lookup ON user_consents(user_id, purpose_id);

Multilingual Payload Tracking

When presenting the notice to the user, your backend must verify that the user was served the policy in their preferred language and track that metadata in the immutable ledger.

async function logConsent(userId: string, purpose: string, isGranted: boolean, language: string, req: Request) {
    await db.query(`
        INSERT INTO user_consents (user_id, purpose_id, consent_status, notice_version, notice_language, ip_address, user_agent)
        VALUES ($1, $2, $3, $4, $5, $6, $7)
        ON CONFLICT (user_id, purpose_id) DO UPDATE 
        SET consent_status = EXCLUDED.consent_status,
            revoked_at = CASE WHEN EXCLUDED.consent_status = false THEN NOW() ELSE NULL END,
            granted_at = CASE WHEN EXCLUDED.consent_status = true THEN NOW() ELSE user_consents.granted_at END
    `, [userId, purpose, isGranted, 'v2026.1', language, req.ip, req.headers['user-agent']]);
}

3. Building 90-Day Grievance and Soft-Delete/Hard-Purge Cascade Routines (dpdp-2)

Under Section 12, Data Principals have the right to grievance redressal and the right to erasure. Grievances must be resolved within specific timelines (often evaluated around a 90-day maximum SLA or sooner based on DPB rules), and data deletion requests must propagate through all interconnected systems.

A robust erasure architecture uses a soft-delete queue that transitions to a hard-purge after an isolation period, safeguarding against accidental deletions while ensuring regulatory compliance.

The Erasure Cascade Architecture

CREATE TABLE erasure_requests (
    request_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL,
    requested_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    scheduled_purge_date TIMESTAMPTZ NOT NULL, -- Usually NOW() + INTERVAL '30 days'
    status VARCHAR(20) DEFAULT 'pending', -- 'pending', 'processing', 'completed', 'failed'
    completed_at TIMESTAMPTZ
);

A daily cron job processes the erasure_requests table. When the scheduled_purge_date is met, the system hard-deletes the records. It’s critical to ensure foreign keys are configured with ON DELETE CASCADE or that an application-level saga orchestrates the deletion across external microservices.

// Cron Job: Executes daily at 00:00 UTC
async function executeHardPurge() {
    const readyToPurge = await db.query(`
        SELECT user_id FROM erasure_requests 
        WHERE status = 'pending' AND scheduled_purge_date <= NOW()
    `);
    
    for (const row of readyToPurge.rows) {
        try {
            await db.query('BEGIN');
            // Hard delete user data. PII is scrubbed.
            await db.query('DELETE FROM users WHERE id = $1', [row.user_id]);
            await db.query(`UPDATE erasure_requests SET status = 'completed', completed_at = NOW() WHERE user_id = $1`, [row.user_id]);
            await db.query('COMMIT');
        } catch (error) {
            await db.query('ROLLBACK');
            await triggerDevSecOpsAlert(`Erasure failed for user ${row.user_id}: ${error.message}`);
        }
    }
}

4. Row-Level Security (RLS) & Field-Level Encryption Safeguards (dpdp-3)

Section 8(5) mandates Data Fiduciaries implement reasonable security safeguards to prevent data breaches. Relying solely on application-level logic is risky; safeguards must be embedded at the database tier using PostgreSQL Row-Level Security (RLS) and field-level encryption (e.g., pgcrypto).

Implementing PostgreSQL RLS

RLS ensures that even if an application vulnerability (like an IDOR flaw) occurs, the database will reject unauthorized read/write attempts.

-- Enable RLS on sensitive tables
ALTER TABLE health_records ENABLE ROW LEVEL SECURITY;

-- Policy: Users can only select their own records
CREATE POLICY select_own_records ON health_records
    FOR SELECT
    USING (user_id = current_setting('app.current_user_id')::uuid);

-- Policy: Only internal service roles can insert
CREATE POLICY insert_service_role ON health_records
    FOR INSERT
    WITH CHECK (current_role = 'dpdp_service_role');

Before executing queries, the application must inject the user context into the transaction session:

await db.query("SET LOCAL app.current_user_id = $1", [req.user.id]);
const records = await db.query("SELECT * FROM health_records"); // Only returns authorized rows

Field-Level Encryption for PII

For highly sensitive identifiers (e.g., Aadhaar hashes, PAN numbers, medical conditions), use symmetric encryption (AES-256-GCM) so data remains protected at rest within the database blocks.

-- Insert encrypted data using pgcrypto
INSERT INTO users (id, encrypted_pan) 
VALUES (
    $1, 
    pgp_sym_encrypt($2, current_setting('app.encryption_key'), 'cipher-algo=aes256')
);

5. 72-Hour Automated Data Protection Board Breach Escalation Pipeline (dpdp-4)

Section 8(6) requires immediate notification of personal data breaches to the Data Protection Board (DPB) and the affected Data Principals. While the exact SLA is tightly regulated (often benchmarked at 72 hours matching GDPR standards), manual incident response is too slow.

Engineering teams must build automated breach escalation pipelines integrating SIEM (Security Information and Event Management) alerts into the compliance dashboard.

Incident Escalation Webhook

When anomalous exfiltration patterns are detected (e.g., large volume SELECTs from an unusual IP), the system automatically freezes the tenant and alerts the Privacy Officer.

import { DPBGateway } from '@india/dpdp-api-sdk';

async function escalateBreachToDPB(incidentContext: SecurityIncident) {
    // 1. Generate cryptographic hash of the audit logs to prevent tampering
    const logHash = generateSHA256(incidentContext.auditLogs);
    
    // 2. Draft the automated preliminary report
    const preliminaryReport = {
        fiduciary_id: process.env.DPDP_FIDUCIARY_ID,
        nature_of_breach: incidentContext.vectorType,
        approximate_records_affected: incidentContext.affectedRows,
        mitigation_taken: "System automated tenant isolation initiated.",
        audit_checksum: logHash
    };

    // 3. Dispatch to DPB Gateway (Mocked API)
    const dpbResponse = await DPBGateway.submitBreachNotification(preliminaryReport);
    
    // 4. Queue notifications for Data Principals
    await enqueuePrincipalNotifications(incidentContext.affectedUsers);
    
    return dpbResponse.acknowledgementId;
}

6. Verifiable Parental Consent Architecture for Minors (dpdp-5)

Section 9 is one of the most technologically demanding clauses of the DPDPA. It prohibits tracking or behavioral monitoring of children (under 18 years) and requires verifiable consent from a parent or lawful guardian before processing any personal data of a child.

Token-Based Guardian Linking

You cannot simply ask “Are you over 18?”. You must implement a verifiable linkage. A common architectural pattern involves generating a secure Consent Challenge Token that the guardian must resolve through an authenticated portal (often leveraging DigiLocker or e-Pramaan in the Indian context).

sequenceDiagram
    participant Child as Child App
    participant API as DPDP Backend
    participant Guardian as Guardian Device
    participant ID as Identity Provider (e-Pramaan)

    Child->>API: Request account creation (DOB < 18)
    API-->>Child: Return GuardianChallengeToken
    Child->>Guardian: Child shares Token (QR/SMS)
    Guardian->>API: Submit Token & Authenticate
    API->>ID: Verify Guardian Age & Identity
    ID-->>API: KYC Success (Adult verified)
    API->>API: Create Guardian-Child Link
    API->>API: Log VPC (Verifiable Parental Consent)
    API-->>Child: Account Unlocked

The Schema

CREATE TABLE minor_accounts (
    child_user_id UUID PRIMARY KEY REFERENCES users(id),
    guardian_user_id UUID REFERENCES users(id),
    consent_token VARCHAR(128) UNIQUE,
    vpc_status VARCHAR(20) DEFAULT 'pending', -- 'pending', 'verified', 'revoked'
    verified_at TIMESTAMPTZ,
    kyc_reference_id VARCHAR(255)
);

7. Data Minimization and Cron-Based Auto-Purging Routines (dpdp-6)

The DPDPA strictly enforces purpose limitation and storage limitation. Data must be erased as soon as the specified purpose is served, or if the Data Principal withdraws consent (whichever is earlier). Relying on manual database cleanups guarantees compliance violations.

Tagging Data with TTL (Time-To-Live)

Every column containing Personal Data must logically map to a purpose, and that purpose must have a defined TTL.

CREATE TABLE access_logs (
    id BIGSERIAL PRIMARY KEY,
    user_id UUID NOT NULL,
    ip_address INET,
    action VARCHAR(255),
    created_at TIMESTAMPTZ DEFAULT NOW(),
    -- Purpose: Security auditing (TTL: 180 days)
    purge_after TIMESTAMPTZ DEFAULT NOW() + INTERVAL '180 days'
);

CREATE INDEX idx_access_logs_purge ON access_logs(purge_after);

The Sweeper Worker

A background worker (e.g., using BullMQ or heavily optimized PostgreSQL pg_cron extensions) runs continuously, identifying and physically deleting expired records.

-- Using pg_cron extension for internal DB maintenance
SELECT cron.schedule('hourly_purge', '0 * * * *', $$
    DELETE FROM access_logs WHERE purge_after <= NOW();
$$);

By embedding these architectural primitives into your core framework, your engineering team fundamentally aligns with the India DPDP Act. Security and compliance become a mathematical certainty enforced by database constraints rather than an operational afterthought.