DPDP Rules 2025, Rule 6(1)(a): What “Data Security Measures” Actually Requires

Part of a series on DPDPA Section 8(5) and DPDP Rules 2025, Rule 6. Read the pillar post first if you haven’t.

The Clause, Verbatim

“(a) appropriate data security measures, such as securing of personal data through encryption, obfuscation, masking or the use of virtual tokens mapped to that personal data;”

DPDP Rules 2025, Rule 6(1)(a)

Notice the structure before anything else. The requirement is “appropriate data security measures.” Encryption, obfuscation, masking, and virtual tokens are given as examples of what that can look like, introduced by “such as,” not as an exhaustive list and not as four separately mandatory items. You don’t need all four. You need something appropriate, and the drafters offered these as the reference set of what “appropriate” tends to mean in practice.

What It Technically Requires

Read literally, Rule 6(1)(a) is satisfied by implementing at least one control from this family, applied to personal data, in a way that’s proportionate to the risk. In practice, for most Data Fiduciaries, that means some combination of:

Encryption at rest. Personal data stored in databases, object storage, backups, and data warehouses encrypted using a standard algorithm (AES-256 is the common baseline), with key management separated from the data store itself, not hardcoded credentials or keys sitting next to the data they protect.

Encryption in transit. TLS across every path personal data travels: client to application, application to database, service to service, and any batch export or third-party data feed.

Obfuscation and masking. Techniques that alter how data appears without necessarily making it cryptographically irreversible. Masking replaces part of a value with a placeholder (an email shown as j***@domain.com in a support dashboard, a card number shown as **** **** **** 1234). It’s usually irreversible in the sense that the masked view can’t be un-masked back to the original without going to the source system.

Virtual tokens. Tokenisation replaces a sensitive value with a non-sensitive token that has no exploitable mathematical relationship to the original, with the mapping between token and real value held separately in a token vault. Unlike masking, tokenisation is reversible, but only through a controlled, access-gated lookup, not through any property of the token itself.

The distinction between masking and tokenisation matters more than it looks. They solve different problems. Masking is for display and reduces what a human or a downstream system sees. Tokenisation is for storage and processing and lets you run analytics, route data through third-party systems, or populate a support tool without those systems ever touching the real value. Conflating the two, treating a masked field in a dashboard as equivalent to tokenising the field at the database layer, is one of the more common gaps we see when mapping this clause against real infrastructure.

Where This Gets Subjective

The clause says “appropriate,” and appropriate is doing a lot of work here. Three places where two security teams can both point to Rule 6(1)(a) and mean genuinely different things:

Scope of what gets covered. Does “appropriate data security measures” mean every field classified as personal data under DPDPA’s broad definition, or only fields your organisation independently judges as sensitive? DPDPA’s definition of personal data is wide (any data about an identifiable individual), so a strict reading would extend encryption or masking obligations to fields many teams don’t currently treat as sensitive: a first name in a marketing CRM, a device ID tied to a user account, an IP address in an access log. A narrower, risk-based reading limits the heavier controls to data that’s actually damaging if exposed. Both are defensible under “appropriate.” They produce very different backlogs.

Which environments count. Production databases getting encrypted is close to universal practice now. Staging environments seeded with copies of production data, analytics warehouses, data science notebooks, and third-party SaaS tools that personal data flows into are far less consistently covered. Nothing in the clause excludes non-production environments, and a breach originating from an unencrypted staging database is not a defense that “it wasn’t the real environment.”

Strength and currency of the control.“Encryption” isn’t a single fixed bar. An organisation running a deprecated cipher, or using weak, easily-reversible obfuscation and calling it masking, can point to the same clause text as an organisation running current, audited encryption standards. The clause doesn’t specify an algorithm or a key length, so “appropriate” ends up doing the enforcement, after the fact, against whatever the actual state of practice was at the time.

What the Breakdown Really Means

The honest way to use this clause internally isn’t “do we have encryption,” it’s “where does personal data live that we haven’t asked that question about yet.”

Vimalendukumar Dwivedi is Co-founder of Scrutora, a Code Compliance Platform.