The gap

Every DPDP article you’ve read was written by a lawyer. It tells you what the Act says. It doesn’t tell you what to build.

Your legal team updates the privacy policy. Your product team adds a cookie banner. Everyone moves on. But the Act doesn’t care about documents — it cares about systems. Can you prove consent? Can you erase data when asked? Can you detect a breach and notify within the required window?

These are engineering problems. Here’s what you actually need to ship.

The Act requires consent to be free, specific, informed, and unambiguous. That means you need a record of exactly what each user consented to, when, and through which interface.

What to build: a consent_records table.

user_id
purpose         — "marketing_emails", "analytics", "third_party_sharing"
granted         — boolean
granted_at      — timestamp
withdrawn_at    — timestamp (nullable)
source          — "signup_form", "settings_page", "api"
ip_address      — for audit
consent_version — ties to which version of your privacy policy was shown

Every consent grant and withdrawal is an immutable append. Don’t update rows — insert new ones. When the Data Protection Board asks “did this user consent to analytics on March 15?”, you need the answer in one query.

Most companies store a single accepted_terms: true boolean on the user record. That proves nothing.

2. Erasure pipeline

Users can request complete deletion of their personal data. The Act doesn’t say “mark as inactive.” It says erase.

What to build: an erasure API and a background job.

The API receives the request, validates the user’s identity, and queues the job. The job walks every table, every file store, every cache, every backup reference, and every third-party integration where that user’s data exists — and deletes it.

The hard parts:

Referential integrity. You can’t just delete a user row if 15 other tables have foreign keys to it. You need a dependency map of every table that holds personal data and the deletion order.

Third-party propagation. If you sent user data to an analytics provider, a payment gateway, or an email service, the erasure request needs to propagate there too. Build a registry of every third-party that holds user data and an API call or manual process for each.

Backups. You can’t edit backups. Standard practice: document that backups expire on a defined retention cycle (e.g., 90 days), and ensure the erasure is reflected when backups rotate. The Board understands that backup deletion isn’t instant — but you need a documented retention policy.

Audit trail. After erasure, you need proof it happened. Store: erasure_request_id, requested_at, completed_at, tables_cleared, third_parties_notified. The user’s personal data is gone, but the record that you erased it stays.

3. Data flow inventory

The Act requires you to know where personal data goes. Not approximately. Exactly.

What to build: a data flow map. Every system, every integration, every database that touches personal data gets an entry.

system: "PostgreSQL — production"
data_types: ["email", "name", "phone", "address"]
purpose: "user accounts"
retention: "until erasure request"
third_party: false

system: "SendGrid"
data_types: ["email", "name"]
purpose: "transactional emails"
retention: "30 days on SendGrid"
third_party: true
dpa_signed: true

system: "Google Analytics"
data_types: ["IP address", "device info", "page views"]
purpose: "analytics"
retention: "26 months (GA default)"
third_party: true
consent_required: true

This isn’t a one-time exercise. Every new integration, every new database, every new feature that collects personal data needs to update this map. Make it part of your code review checklist.

4. Breach notification pipeline

The Act mandates breach notification to the Data Protection Board and affected individuals. No discretion on whether to report.

What to build: detection and a notification workflow.

Detection. You need to know a breach happened. At minimum: alerts on unusual data access patterns, failed auth spikes, unauthorized API access, and data export anomalies. If you’re running a SIEM (even a basic one), pipe these signals into an alert channel.

Notification workflow. When a breach is confirmed:

Step 1: Internal incident record — what happened, when, what data, how many users affected.

Step 2: Board notification — the format and channel will be specified by the Board. Build the template now so you’re not drafting it during an incident.

Step 3: User notification — email to affected users with what happened, what data was involved, and what they should do.

Step 4: Remediation log — what you did to contain it, what you changed to prevent recurrence.

Build the templates and the workflow before you need them. During a breach is the worst time to figure out your notification process.

5. Audit logging

Every DPDP obligation — consent, erasure, data access, breach response — requires proof. Proof means logs.

What to log:

  • Every consent grant and withdrawal
  • Every data access by internal staff (who accessed which user’s data, when, why)
  • Every erasure request and completion
  • Every data export or third-party data share
  • Every breach detection and notification step

These logs are immutable. Append-only. Separate from application logs. Retained for the period the Board specifies (or a reasonable default — 3 years is standard practice).

If you’re already shipping structured logs to a centralized system (ELK, Datadog, CloudWatch), add a dpdp_audit log stream with these events. If you’re not, a simple append-only table in your database is a starting point.

The minimum viable compliance stack

If you’re a startup and need to ship something this quarter:

  • Consent records table with per-purpose granularity
  • An erasure API endpoint that queues a deletion job
  • A data flow spreadsheet (not even a system — just a documented list)
  • Breach notification email templates (pre-written, ready to send)
  • Audit log for consent and erasure events

That’s not full compliance. But it’s the difference between “we have nothing” and “we have the systems, we’re improving them.” The Board will treat those very differently.

The cost of not building this

Up to ₹250 crore per instance. That’s not a typo. The Act has teeth, and the Data Protection Board is operational.

But beyond penalties — your customers will start asking. Enterprise buyers are already adding DPDP compliance to vendor questionnaires. “Show me your erasure workflow” is becoming as common as “show me your SOC 2 report.”

Build the systems now. The policy is already on your website.

Links: Rta Labs DPDP Overview · Rta Labs