Data Privacy Architecture: Navigating UK GDPR and India's DPDP Act

Building custom software that operates across borders means navigating overlapping, and sometimes conflicting, data privacy regulations. For businesses operating between the United Kingdom and India, this means designing systems that satisfy both the UK GDPR and India's Digital Personal Data Protection (DPDP) Act.

Compliance isn't just a legal exercise; it is fundamentally a software architecture problem. Treating privacy as an afterthought or bolting on a consent banner just before launch leads to fragile systems, expensive retrofits, and significant liability.

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

The Dual-Compliance Landscape

The UK GDPR is famously stringent, emphasizing data minimization, explicit consent, and the right to erasure. India's DPDP Act, while newer, shares much of this DNA but introduces specific nuances around the concept of a "Data Fiduciary" and "Consent Managers."

When building systems for users in both regions, the engineering goal should not be to maintain two separate codebases. Instead, the goal is to design a unified architecture that handles the strictest requirements of both regimes gracefully.

1. Architecting for Data Minimization and Segregation

The core tenet of both laws is that you should only collect data you absolutely need and delete it when you no longer need it.

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 (email, hashed password).
2. Profile Data: Non-sensitive demographic information.
3. Personally Identifiable Information (PII): Highly sensitive data (addresses, government IDs, financial details) stored 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

Do not 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 both UK GDPR and DPDP.

3. The "Right to be Forgotten" in Distributed Systems

Both regulations grant 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

While soft deletes (marking a record as is_deleted = true) are great for accidental deletions, they do not satisfy regulatory erasure requirements.

The pattern to implement:

1. Tombstoning: When a deletion request is received, replace the PII in the database with a cryptographic hash or a generic tombstone identifier (e.g., DELETED_USER_1234).
2. Event Propagation: Emit a UserDeleted event to your message broker. Every downstream service (analytics, email marketing, CRM) must listen for this event and execute its own hard delete logic.
3. Backup Expiration: You aren't required to immediately rewrite immutable backups. However, your restoration process must be aware of tombstones so that a restored backup does not accidentally resurrect deleted PII.

4. Data Localization and Cross-Border Transfers

The UK GDPR requires adequacy decisions or Standard Contractual Clauses (SCCs) for transferring data outside the UK. The DPDP Act allows cross-border transfers unless explicitly restricted by the government, but handling this dynamically is crucial.

Infrastructure Strategy

For platforms handling sensitive health or financial data, multi-region deployments are often necessary.

• Primary Storage: Store UK user data in a eu-west-2 (London) region and Indian user data in an ap-south-1 (Mumbai) region.
• Routing: Use edge computing or API gateways to route traffic and data storage operations to the correct geographic bucket based on user origin.
• Anonymized Analytics: If you need global analytics, build an ETL pipeline that strips PII and aggregates data before it crosses a border into your global data warehouse.

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.