Data Privacy Architecture: Engineering for India's DPDP Act

Building custom software for the Indian market means designing systems that satisfy the Digital Personal Data Protection Act, 2023 (No. 22 of 2023) from the ground up, not bolting it on after launch.

Compliance is a software architecture problem, not just a legal one. Treat it as an afterthought - or bolt on a consent banner right before launch - and you end up with fragile systems, expensive retrofits, and real liability.

This post covers how to architect your data models, APIs, and infrastructure to be compliant by design.

The DPDP compliance landscape

India's DPDP Act emphasizes data minimization, explicit consent, and the right to erasure, and introduces specific nuances around the concept of a "Data Fiduciary" and interoperable "Consent Managers." For teams that have worked with GDPR-style regimes elsewhere, much of the underlying DNA will feel familiar - but the DPDP Act has its own compliance mechanics that need to be engineered for directly rather than assumed.

The engineering goal should not be to bolt consent logic onto an existing application. Instead, the goal is to design a unified architecture that treats data minimization, consent, and erasure as first-class concerns from day one.

1. Architecting for data minimization and segregation

The core tenet of the law is that you should only collect data you absolutely need, and delete it the moment you don't.

Data modeling

Instead of storing all user data in a single massive users table, adopt a segmented data model:

1. Identity data - core authentication details like email and hashed password.
2. Profile data - non-sensitive demographic information.
3. PII (personally identifiable information) - addresses, government IDs, financial details - kept in a separate table, or even a separate database, with stricter access controls and field-level encryption.

This segregation means that when a marketing service needs to pull a list of active users, it only interacts with the Identity and Profile tables, completely bypassing the PII layer.

2. Implementing dynamic consent mechanisms

Under the DPDP Act, users can manage their consent through interoperable Consent Managers. Your system needs to be able to accept, record, and revoke consent dynamically.

Consent as a microservice

Don't hardcode consent logic into your application flow. Build a centralized Consent Management Service.

When a user interacts with your system:

• Your application requests authorization from the Consent Service before executing a data-processing action.
• The Consent Service checks the user's current consent state (which includes timestamps, exact scopes granted, and the legal basis).
• If consent is revoked mid-session, the architecture should immediately drop the associated processing tasks.

This approach makes it trivial to audit consent logs, a mandatory requirement under the DPDP Act.

3. The "right to be forgotten" in distributed systems

The DPDP Act grants users the right to erasure. In a monolithic app with a single database, this is a DELETE query. In a modern distributed system with message queues, event sourcing, and data lakes, it's an architectural nightmare if not planned for.

Soft deletes vs. hard deletes

Soft deletes (marking a record as is_deleted = true) are fine for accidental deletions, but they don't satisfy regulatory erasure requirements. Here's the pattern that actually works:

1. Tombstone it. When a deletion request comes in, replace the PII in the database with a cryptographic hash or a generic identifier like DELETED_USER_1234.
2. Propagate the event. Emit a UserDeleted event to your message broker. Every downstream service - analytics, email marketing, CRM - has to listen for it and run its own hard delete.
3. Handle backups separately. You don't need to rewrite immutable backups immediately, but your restoration process needs to know about tombstones, or a restored backup will quietly resurrect PII you already deleted.

4. Data localization and cross-border transfers

The DPDP Act allows cross-border transfers unless explicitly restricted by the government via a notified list of jurisdictions. Still, handle this dynamically and keep the default posture conservative, especially if you integrate with global vendors or analytics providers.

Infrastructure strategy

For platforms handling sensitive health or financial data, a clear localization strategy matters even for an India-only product.

• Default to storing user data in an ap-south-1 (Mumbai) region, so data residency is satisfied without extra configuration.
• Treat any service that isn't India-hosted - an overseas email provider, an analytics tool, an LLM API - as a cross-border transfer, and gate it behind the same consent and restriction checks as everything else.
• If data goes to a global analytics or monitoring vendor, build an ETL pipeline that strips PII and aggregates it before it ever leaves your primary region.

The cost of getting it wrong

The engineering effort required to build a compliant-by-design architecture is non-trivial. However, the cost of retrofitting these features into a legacy system is exponential.

When you build a custom software system, you have the opportunity to make compliance an automated byproduct of your architecture rather than an operational burden. Start with a segregated data model, centralize your consent logic, and design for distributed erasure from day one.