DPDP Rule 6: Understanding Security Safeguards for Modern Applications

Personal data is no longer stored in a single database. In modern applications, it moves across APIs, cloud services, analytics platforms, AI models, agent tools, logs, and third-party integrations. Each additional system that processes personal data creates another place where that data must be protected.

For organisations operating in India, the Digital Personal Data Protection (DPDP) framework introduces obligations around protecting digital personal data. Rule 6 of the DPDP Rules, 2025, focuses on reasonable security safeguards designed to prevent personal data breaches.

But what does this mean for developers building applications, APIs, and AI-powered workflows?

Security cannot depend only on protecting the primary database or securing the application perimeter. Organisations also need to consider how personal data is accessed, processed, logged, transmitted, and stored across the systems involved in a workflow.

This is particularly important for AI applications, where a single user request may pass through an application server, an AI model, external tools, observability systems, and data stores.

In this article, we break down Rule 6, explain its key security requirements, and explore how engineering teams can approach personal data protection in modern application and AI architectures.

What Is Rule 6 of the DPDP Rules, 2025?

Rule 6, titled Reasonable Security Safeguards, requires a Data Fiduciary to protect personal data in its possession or under its control, including processing carried out on its behalf by a Data Processor.

The rule specifies minimum security measures covering data protection, access control, monitoring, business continuity, retention of relevant logs and personal data, processor contracts, and technical and organisational safeguards.

The important point for engineering teams is that security safeguards apply to the broader processing environment, not just to one database or application component.

For example, consider an AI-powered customer support application that processes a user's name, phone number, and account information. Personal data may be processed by the application, sent to an AI service, accessed by support tools, and recorded in operational logs.

Protecting the database alone does not necessarily address the risks associated with the other processing points. Security controls need to be considered across the relevant data flow.

Rule 6 provides a framework for thinking about these protections, while the specific safeguards an organisation implements should reflect its processing activities, risks, and applicable legal requirements.

The Seven Security Safeguards Under DPDP Rule 6

Rule 6 outlines seven minimum categories of security safeguards that organisations must consider when protecting personal data. These safeguards address different parts of the security lifecycle, from protecting data and controlling access to monitoring activity and maintaining business continuity.

Let's explore each safeguard from a practical engineering perspective.

1. Protect Personal Data Through Encryption, Masking, and Tokenization

The first safeguard focuses on appropriate data security measures, including encryption, obfuscation, masking, and virtual tokens mapped to personal data.

For developers, this means considering how personal data is protected when it is stored, transmitted, or processed by different services.

For example, an application may collect a user's email address and send it to multiple downstream systems. If every system receives the original value, the number of locations where personal data is exposed increases.

Depending on the use case, developers can implement different protection methods.

Encryption converts readable data into an encoded form that requires an appropriate key for decryption. It is commonly used to protect data at rest and in transit.

Masking limits the information displayed or exposed. A customer support dashboard, for example, might display a partially masked phone number instead of the full value.

Tokenization replaces an original value with a token while maintaining a protected mapping to the original data.

Consider a customer support application that uses an AI model to help answer user queries. The application may tokenize personal data before passing it to a downstream service that does not need access to the original value.

This can reduce unnecessary exposure of personal data across AI prompts, APIs, logs, and external integrations.

However, tokenization is not a complete security solution on its own. The token mapping, vault, access permissions, and restoration process must also be protected.

For engineering teams, the objective is to ensure that personal data is accessible only where it is required and appropriately protected throughout the workflow.

2. Control Access to Computer Resources

The second safeguard focuses on controlling access to computer resources used to process personal data. This includes the systems, applications, and infrastructure managed by the organisation or its Data Processors.

In modern applications, personal data may be accessed by application servers, databases, internal APIs, cloud services, and AI-powered tools. Not every service needs access to the same information.

For example, an AI customer support agent may need to retrieve a customer's order status but should not automatically have access to their complete payment details or identity documents.

Developers can address these risks through role-based access control, least-privilege permissions, service authentication, and operation-specific authorisation.

For AI workflows, access control should also consider which tools an agent can call, what data those tools can retrieve, and which operations require additional approval.

The objective is simple: give every user, service, and agent only the access it needs to perform its authorised task.

3. Monitor and Review Access to Personal Data

The third safeguard focuses on maintaining logs, monitoring access, and reviewing relevant activities to detect unauthorised access and support investigations.

For engineering teams, this means being able to understand who or what accessed personal data, when the activity occurred, and which operation was performed.

In an AI application, a single request may involve an agent, multiple tools, APIs, and external services. Appropriate audit logs can help teams trace these activities without unnecessarily storing complete personal data in every log entry.

For example, an application could record a request identifier, the service involved, the authorisation result, and the operation performed. The exact information captured should reflect the system's security and investigation requirements.

Monitoring is useful only when logs are appropriately protected, reviewed, and connected to an incident response process.

4. Maintain Business Continuity Through Backups

The fourth safeguard addresses measures for continued processing when personal data is compromised, including through destruction or loss of access. The rule identifies backups as an example of a relevant measure.

Applications that rely on personal data need a recovery approach for situations such as data corruption, system failures, or security incidents.

Engineering teams should consider backup frequency, recovery procedures, protection of backup copies, and restoration access.

Backups themselves may contain personal data, so they require appropriate protection and lifecycle management.

5. Retain Relevant Logs and Personal Data

Rule 6 specifies retention of relevant logs and personal data for one year for the purposes described in the rule, subject to applicable legal requirements.

Organisations should evaluate which records fall within this requirement and how retention interacts with other legal and operational obligations.

From an engineering perspective, retention policies should identify relevant security records, control access to retained data, protect records from unauthorised alteration, and support appropriate lifecycle management.

The objective is to maintain information needed for security investigations and continued processing without creating unnecessary exposure of personal data.

6. Include Security Provisions in Data Processor Contracts

Organisations frequently rely on third-party service providers to process personal data. These may include cloud infrastructure providers, analytics platforms, and AI service providers.

Rule 6 requires appropriate security provisions in contracts between Data Fiduciaries and Data Processors, wherever applicable.

Engineering and security teams should work with relevant stakeholders to understand how third-party services handle personal data, what security responsibilities apply, and how contractual arrangements support the organisation's security requirements.

7. Implement Technical and Organisational Measures

The final safeguard focuses on technical and organisational measures that support effective observance of security safeguards.

Technical controls such as encryption, access management, tokenization, monitoring, and backup systems need to work alongside organisational processes.

These may include security policies, employee access management, incident response procedures, and regular security reviews.

A secure architecture is not only about the tools an organisation deploys. It also depends on how those tools are configured, maintained, and governed.

How Securelytix Supports Data Protection in AI Workflows

As personal data moves across applications, APIs, AI models, and third-party tools, organisations can consider approaches that reduce unnecessary exposure of original values.

Securelytix VaultKey provides capabilities such as tokenization, secure data vaults, dynamic masking, and controlled data restoration for AI and non-AI applications.

For example, an application may tokenize a user's email address before passing relevant information to an AI service that does not require the original value. The token can be used within the workflow while the original data is managed separately.

This approach can help organisations reduce unnecessary exposure across connected systems. However, Securelytix does not by itself make an application DPDP compliant. Organisations remain responsible for evaluating their obligations and implementing appropriate technical and organisational safeguards.

Conclusion

Rule 6 highlights the importance of protecting personal data throughout its processing lifecycle. For developers, this means looking beyond database security and considering access control, monitoring, backups, retention, third-party processing, and appropriate data security measures.

By integrating security controls into application architecture, organisations can work toward reducing unnecessary exposure of personal data across modern AI and software workflows.