Vision, principles and non-goals

OpenDPDP turns a source-linked obligation into an owned workflow, controlled system action and verifiable evidence without creating a new central warehouse of customer personal data.

Product promise

For a configured legal entity and processing purpose, a reviewer can trace:

primary source and effective date
→ approved interpretation
→ control and owner
→ workflow, system tasks and clock
→ evidence, exception and test

The platform supports compliance; it does not certify the organisation, replace counsel or make a fact-dependent legal decision without accountable approval.

Principles

1. India-specific semantics. Consent and section 7 uses, exact rights, statutory Consent Manager and phased commencement are first-class—not translated GDPR fields.
2. Evidence before dashboard colour. A green state needs current evidence and a passed test.
3. Control plane, not PII lake. Use pseudonymous subject references and customer-side agents.
4. Human legal checkpoints. Automate routing and calculation; require maker-checker for judgement and high-impact actions.
5. Separate clocks and regimes. DPDP, CERT-In, sector and contract decisions coexist.
6. Reconciliation is a product feature. Distributed withdrawal/deletion will partially fail.
7. SaaS and sovereign parity. Same control model across managed, VPC and on-prem profiles.
8. Accessible, comparable choice. Withdrawal and rights are not hidden; assisted routes work.
9. No compliance tax on exercising rights. Never price per withdrawal, grievance or incident.
10. Version law and configuration. New law produces reviewed signed configuration, not silent workflow drift.

Three profiles

The Data Fiduciary profile owns purposes and Data Principal operations. The Processor plane owns customer instructions, boundaries, assistance and exit. The statutory Consent Manager is a separate legal/operational deployment with Board registration and no-readability requirements.

Shared primitives—tenant isolation, audit, connectors and notification—may be reusable. Roles, data, keys, operators, claims and public copy remain separated.

Product-wide state language

Every object supports draft, review_pending, approved, active, superseded and archived where meaningful. Operational cases add explicit partial, failure, escalation, cancellation and reopen states. Nothing disappears merely because it is inconvenient for a dashboard.

Non-goals

• legal opinion or certification;
• a master copy of raw customer PII;
• a data-broker identity graph;
• broad employee surveillance;
• a universal Aadhaar verification service;
• invented Board/ABDM/RBI/SEBI APIs;
• blockchain as a default evidence store;
• autonomous refusal of Data Principal requests;
• automatic SDF designation or exemption selection;
• forced cloud telemetry;
• “one-click compliance” or penalty prediction.

Success measures

• high-risk purposes with approved source, notice and owner;
• withdrawal/deletion destinations completing within configured SLO;
• rights cases with verified identity and evidence-complete closure;
• critical processors with current contracts and tested incident/exit paths;
• statutory clocks acknowledged before escalation threshold;
• stale legal/configuration evidence by severity;
• zero cross-tenant access and zero silent partial completion.