Skip to content

Product boundaries

OpenDPDP supports compliance operations. It does not certify legal compliance, decide contested law without a reviewer, become the system of record for customer PII, or turn an ordinary enterprise consent tool into a statutory Consent Manager.

Profile 1 — Data Fiduciary Privacy Operations

Section titled “Profile 1 — Data Fiduciary Privacy Operations”

This is the default product:

  • entity, role, instrument and obligation registry;
  • metadata inventory and processing activities;
  • purpose, notice, consent and preference operations;
  • rights, grievance and nomination cases;
  • retention, legal holds, deletion and backup re-deletion;
  • breach assessment and notification orchestration;
  • child/guardian, processor, SDF, DPIA, algorithmic and transfer controls;
  • source-linked evidence, dashboards and change tracking.

It stores subject references and workflow evidence. A connector reads or changes raw PII at the customer boundary under a scoped instruction.

Profile 2 — Data Processor Compliance Plane

Section titled “Profile 2 — Data Processor Compliance Plane”

This profile changes the centre of gravity from purposes to customer instructions:

  • one instruction register and policy boundary per customer tenant;
  • contract, subprocessor, location and prohibited-reuse constraints;
  • incident propagation to the relevant Data Fiduciary;
  • return, export and deletion tasks with certificates;
  • tenant-specific retention and hold decisions;
  • customer evidence rooms with controlled audit access.

The processor plane must prevent one customer’s instructions or evidence from being exposed to another. It must not silently reuse data or metadata for its own product purpose.

DPDP — not yet effective

Act section 6(9), Rule 4 and the First Schedule are scheduled for 13 November 2026.

This optional profile requires an independently governed operating entity, registration readiness, conflict controls, prescribed financial standing, interoperability, record export and audit. It must be unable to read personal-data content shared between a Data Principal and onboarded Data Fiduciaries.

Until the Board registers the operating entity:

  • the UI says “Consent and preference management”, never “registered Consent Manager”;
  • statutory onboarding is disabled outside a readiness sandbox;
  • no Board badge, registration number or government interoperability claim is displayed;
  • unidentified government APIs remain adapter interfaces marked unverified.
Permitted with defined scopeProhibited
“Supports controls mapped to Act section 8 and Rule 6”“Makes you DPDP compliant”
“Readiness workflow as of 29 July 2026”“Government approved”
“Evidence pack generated from configured systems”“Certifies safeguards are reasonable”
“Customer-hosted connector can minimise PII movement”“No personal data ever enters the platform” unless technically proven for that deployment
“Statutory Consent Manager readiness module”“Consent Manager” as operating status before Board registration
  • no general GDPR lawful-basis model or invented portability right;
  • no blockchain default for evidence;
  • no central biometric, Aadhaar, PAN or health-document vault;
  • no automatic acceptance or refusal of rights requests;
  • no autonomous legal advice;
  • no covert employee monitoring, identity graph or advertising profile;
  • no per-request pricing that discourages withdrawal, grievance, incident or deletion;
  • no telemetry from self-hosted deployments unless an administrator explicitly opts in.

OpenDPDP may calculate, remind and propose. A named human must approve applicability, legal grounds, retention exceptions, breach notification content, child-processing exceptions, SDF status, transfer restrictions and rights refusals. Maker-checker approval is mandatory for mass export, evidence deletion, legal-hold release, incident closure and production connector credentials.