DPDP Act for Developers: The Engineering Controls You Actually Need

The earlier DPDP compliance checklist covered the policies and processes. This one is the code-level companion. What APIs, tables, jobs, and infrastructure must exist for your DPDP claims to hold up under audit.

Key takeaways

• A consents table that records every consent event with full context.
• A user data export API that returns everything you hold.
• A user data deletion API with documented cascade behavior.
• An immutable audit log of personal-data access.
• A breach detection system that's tested.
• A scheduled job to expire data past retention.

The schema

consents

create table consents (
 id uuid primary key,
 user_id uuid references users(id),
 purpose text not null,
 consent_version text not null,
 text_shown text not null,
 granted boolean not null,
 granted_at timestamptz,
 ip text,
 user_agent text,
 withdrawn_at timestamptz,
 withdrawal_method text
);

Every consent decision is one row. You can prove what the user agreed to, when, and via what UI.

data_access_log

create table data_access_log (
 id uuid primary key,
 actor_id uuid,
 actor_type text, -- 'user' / 'admin' / 'system'
 subject_user_id uuid, -- whose data
 data_categories text[], -- ['profile', 'payments', 'health']
 action text, -- 'read' / 'export' / 'delete'
 purpose text,
 occurred_at timestamptz not null default now(),
 ip text,
 request_id text
);

Immutable. Append-only.

retention_rules

create table retention_rules (
 table_name text primary key,
 retention_days integer not null,
 delete_method text not null -- 'hard_delete' / 'anonymize' / 'archive'
);

A scheduled job reads this and applies retention.

The APIs

GET /api/me/export

Returns all data you hold about the requesting user, in machine-readable JSON.

DELETE /api/me

Triggers deletion. Returns a request ID. Async, completion within agreed window. Cascade to all dependent records. Notify third parties.

POST /api/me/correction

Requests correction. Goes into a queue if requires manual review.

POST /api/admin/breach

Internal admin endpoint to trigger the breach workflow. Logs incident, notifies DPO, starts the 72-hour notification clock.

The jobs

• Retention enforcement: daily, applies retention rules
• Backup purge: monthly, ensures deleted users are removed from backups
• Consent expiration: as needed, triggers re-consent flows
• Audit log archival: monthly, archives old logs to cold storage

The observability

• Dashboard of pending deletion requests
• Alert if any deletion request is older than the SLA
• Alert on unusual data access patterns (volume, off-hours)
• Quarterly access review report

Common pitfalls

Backups. Users get deleted from primary DB but live in backups for 30+ days. Document policy; plan for it.

Third-party processors. Stripe still has the user. Your deletion API must trigger downstream deletion.

Logs. Personal data in application logs that aren't subject to deletion. Don't log PII; if you must, mask or tokenize.

Soft deletes. "Deleted" rows still hanging around. DPDP cares about whether you can still produce the data, soft delete isn't deletion.

What we recommend

Build these controls as core platform features, not compliance afterthoughts. They're useful beyond DPDP, they're useful for product (analytics, debugging) and good engineering hygiene.

FAQs

How long for deletion? Within "reasonable time", interpret as days, not months.

Do we delete from backups? Document policy; show due diligence; many backups are reasonable to wait out.

Pseudonymization? Useful intermediate state; still personal data in DPDP terms.

Talk to Techpuvi about cybersecurity and compliance engineering.