The Digital Personal Data Protection Act is no longer something Indian companies can leave for the legal or compliance team to figure out later.

The DPDP Act, 2023, and the DPDP Rules, 2025, bring a practical question into the engineering room:

Where does your customer's personal data actually go after you collect it?

Most companies can answer where customer data is stored.

Far fewer can answer where it travels.

A customer gives you an email address. Your application stores it in a database. Then that same value may appear in an API request, a support system, an analytics platform, a log, a CRM, an AI prompt or a third-party service.

The database may be well protected.

But the data doesn't stay there.

That is the part of DPDP that engineering teams need to start thinking about.

DPDP is bigger than protecting the database

A common approach to data security is straightforward:

Store sensitive data in an encrypted database and control who can access it.

That's necessary. But modern applications have changed the data flow.

Consider a typical application:

Customer

↓

Application

↓

Database

↓

API / Analytics / AI / Third-party tools

The application has to read the data before it can use it.

At that point, the original value exists in plaintext inside the application and can potentially move to other systems.

For an AI-enabled application, the flow can become even larger:

Customer

↓

Application

↓

LLM

↓

Agent

↓

Tool / MCP

↓

Third-party API

↓

Logs / Traces / Analytics

This is why DPDP implementation is increasingly an architecture problem.

The question isn't only:

"Is our database secure?"

It is:

"How much personal data are we exposing, to which systems, and for how long?"

What the DPDP Rules ask organizations to put in place

The final DPDP Rules, notified by MeitY in November 2025, provide more operational detail around the Act.

For security, Rule 6 is particularly relevant to engineering teams.

It calls for reasonable security safeguards, including measures such as encryption, obfuscation or masking, access controls, appropriate visibility into access through logs and monitoring, backups, and security provisions relating to Data Processors. The Rule also specifically refers to the use of virtual tokens mapped to personal data.

That matters because it moves the conversation beyond a single security technology.

There is no one product that makes an organization "DPDP compliant."

Instead, organizations need controls across the personal-data lifecycle.

Think about it in four questions:

Can we identify the data?

Can we control who gets it?

Can we reduce unnecessary exposure?

Can we demonstrate what happened when something goes wrong?

Those questions have direct consequences for engineering architecture.

1. Know where personal data is going

The first challenge is visibility.

A company may know that it stores customer names, phone numbers or email addresses. But that doesn't necessarily tell it where those values are being copied.

For example:

Customer PII

↓

Production Database

↓

Application

├── Logs

├── Analytics

├── Customer Support

├── AI Model

├── Agent Tools

└── Third-party APIs

Every arrow is another place to examine.

Engineering teams should be able to answer:

• Which systems process personal data?
• Which services receive it?
• Which third parties have access?
• Is PII appearing in logs?
• Are AI prompts carrying customer information?
• How long do downstream systems retain it?
• Can access be traced?

Without that visibility, it becomes difficult to know the real exposure surface.

2. Minimize what you send

This is where data minimization becomes an engineering decision.

Suppose an AI application needs to understand:

"What is the status of customer 45821's order?"

Does the model really need:

"Rahul Sharma, +91-98XXXXXX12, rahul@email.com, card ending 1234..."

Probably not.

The application may only need to provide the model with a safe representation of the customer.

That distinction becomes increasingly important as companies add LLMs and AI agents to production systems.

Instead of allowing every downstream service to receive the original value, organizations can introduce another boundary:

Application

↓

Data Protection Layer

↓

Token

↓

AI / API / Tool

The original value stays in a controlled system while the downstream application works with a token or another protected representation.

This is one reason tokenization is relevant to the DPDP discussion.

It is not a replacement for encryption, access control or governance.

It is another way of reducing the amount of raw personal data moving through the application ecosystem.

3. Access control needs to follow the data

Most organizations already have IAM systems.

But infrastructure access and data access are not always the same thing.

A developer may have access to a production service without needing access to every customer's personal information.

An analytics service may need customer identifiers but not the original phone number.

An AI model may need contextual information without needing raw PII.

A support application may need access to one field while another service needs something completely different.

That leads to a more useful question:

What is the minimum data this system needs to perform its job?

The DPDP Rules' security requirements around access control make this an important architectural consideration.

The goal isn't simply to create more permissions.

It is to reduce unnecessary access to the original data.

4. Don't forget the systems nobody thinks about

One of the easiest ways for sensitive data to spread is through systems that weren't designed to be data stores.

Logs are a good example.

A developer might temporarily log:

customer_email=user@example.com

to troubleshoot an issue.

That value can then end up in a logging platform, retained for months, replicated across environments and accessible to a much larger group than the original application.

The same problem can happen with:

• Error tracking
• API traces
• Agent traces
• Analytics
• Debugging tools
• Vector databases
• Data exports
• Backups

The final Rules specifically address logging, monitoring and retention as part of security safeguards.

For engineering teams, this means observability itself needs a privacy strategy.

You need logs to investigate incidents.

But you don't necessarily need to log the customer's original personal data.

5. Third-party processors change the risk boundary

Modern companies rarely operate entirely within their own infrastructure.

A single application might use:

• A cloud provider
• A payment provider
• A CRM
• An analytics platform
• An email provider
• An AI provider
• Several SaaS tools

The DPDP framework places obligations around processing performed by Data Processors on behalf of a Data Fiduciary. The Rules also require appropriate security provisions in relevant Data Processor arrangements.

This doesn't mean organizations should stop using third-party services.

It means they should become more deliberate about what data those services receive.

There is an important difference between:

"This vendor has access to our customer data."

and:

"This vendor receives only the minimum protected representation it needs."

The second approach can reduce the number of places where raw personal data exists.

6. AI introduces a new data boundary

This is arguably the most important change for engineering teams.

AI applications don't just process data in one application and one database.

An agent might receive information from a customer, call an internal API, query a database, invoke an MCP tool, send context to an LLM and then call an external service.

The data flow can look like:

User

↓

Application

↓

Agent

├── LLM

├── Database

├── MCP Server

├── Internal API

└── External Tool

Every connection creates another potential data boundary.

The security question therefore changes from:

"Can our model provider protect the data?"

to:

"Does the model need the original data at all?"

That is a much more useful architectural question.

If an AI system can perform its task using a tokenized or minimized representation, there may be less reason to expose the original value.

7. Breach response depends on visibility

Another practical issue is what happens when something goes wrong.

The final Rules include requirements around personal data breach notifications, including information to affected Data Principals and notification to the Data Protection Board. The Rules provide for detailed information to the Board within 72 hours, unless a longer period is allowed.

For engineering teams, incident response therefore cannot begin with:

"Let's find out what data we had."

You should already know:

• What personal data exists
• Where it is stored
• Which systems process it
• Which vendors receive it
• Who accessed it
• What was exposed
• When it happened

That requires good data mapping, logging and monitoring before an incident happens.

8. Retention needs to be designed, not assumed

Keeping data forever is easy.

Deleting it properly is harder.

Personal data may exist in the primary database, backups, analytics systems, logs, exports and third-party platforms.

Deleting a record from one database does not necessarily mean the organization's data lifecycle is finished.

The Rules introduce specific requirements around erasure and retention for certain Data Fiduciaries and purposes, alongside other applicable legal requirements.

Engineering teams should therefore treat retention as a system capability.

For every important data store, ask:

Why are we keeping this?

How long do we need it?

Who controls deletion?

What happens to copies?

These questions become particularly important as applications accumulate more data pipelines.

What should companies do now?

The most useful way to approach DPDP is not to start with a compliance checklist.

Start with your architecture.

Map

Identify the personal data your applications process and follow it through every system.

Minimize

Question whether every downstream service really needs the original value.

Protect

Use appropriate controls such as encryption, masking, obfuscation and tokenization based on the use case.

Control

Apply least-privilege access to applications, services and personal data.

Monitor

Maintain sufficient logging and monitoring to understand access and investigate incidents without unnecessarily duplicating sensitive information.

Retain deliberately

Define how long data and its copies should exist.

Prepare

Make sure your organization can identify affected data quickly when an incident occurs.

The bigger shift

The DPDP Rules don't tell companies to buy one particular security product.

They create a broader expectation around how organizations protect personal data throughout its lifecycle.

For technology teams, that means privacy needs to move closer to the application architecture.

It needs to be considered when designing APIs.

When connecting an AI model.

When adding an analytics platform.

When introducing an AI agent.

When creating logs.

When choosing a third-party processor.

And when deciding whether a downstream system really needs the original customer information.

The companies that handle this well will not simply have better compliance documentation.

They will have less unnecessary personal data moving through their systems in the first place.

That is the real architectural opportunity behind DPDP.

Protecting personal data starts before it reaches the next system.