Executive overview

OpenDPDP should be funded as a privacy operations and evidence plane, not as a badge generator. Its job is to give each obligation a source, effective date, owner, operational workflow, system task and evidence trail while keeping raw personal data in customer systems wherever feasible.

DPDP — not yet effective

Most main DPDP obligations start on 13 May 2027. Readiness is nevertheless a multi-quarter data, contract, identity and integration programme.

The board decision

Approve a 90-day engineering MVP that can:

• establish the customer’s entities, roles, licences and applicability profile;
• approve versioned purposes and standalone notices;
• issue and withdraw consent receipts through an API;
• intake and route rights requests and grievances;
• operate retention rules, legal holds and manual deletion tasks;
• manage a breach case with separate DPDP, CERT-In and sector clocks;
• maintain processor/vendor obligations and an append-only evidence log;
• ship two connectors: one generic webhook/API adapter and one metadata-only database scanner;
• deploy securely through Docker Compose for evaluation and Kubernetes for controlled pilots; and
• apply one deep sector pack, initially banking/fintech/payments.

This is the smallest coherent control loop. A consent banner alone cannot handle downstream withdrawal, rights, retention, incidents or evidence; an inventory alone cannot operate a request.

Operating model

Accountable group	Owns	OpenDPDP provides	Does not replace
Board / executive risk	appetite, funding, designation response	readiness and risk dashboards	board judgement
Privacy / DPO	legal interpretation, notice, rights, grievance	source-linked workflow and evidence	counsel
CISO / incident command	safeguards and response	controls, clocks, packs, immutable timeline	security programme
Data and system owners	purpose, inventory, fulfilment, deletion	assignments, APIs, reconciliation	source systems
Procurement / vendor risk	contracts and outsourcing decisions	processor register and evidence rooms	negotiations
Internal audit	assurance plan and conclusions	control/evidence index and export	independent audit

Architecture stance

Build a modular monolith first. Separate a shared control plane from customer-side connector agents. Persist subject references and workflow evidence, not a shadow copy of customer PII. Support multi-tenant SaaS, a dedicated tenant, customer VPC and on-premises Kubernetes from the same versioned product, with air-gapped update bundles later.

What success looks like

By the end of a pilot, a customer should answer five questions using current evidence:

1. Why is this data processed, under which DPDP route, and where does it flow?
2. Which notice and consent proof applied at a specific time?
3. Can withdrawal, correction, erasure or grievance reach every relevant system?
4. When an incident occurs, which clocks apply and who approved each notification?
5. Which records were retained, held or deleted, under which source-linked rule?

The success metric is not “number of consents collected.” It is the percentage of high-risk processing with approved purpose, current notice, tested fulfilment path and verifiable evidence.