by
Ruchin Kumar, VP South Asia, Futurex
Last updated: September 8, 2026
India's enterprise data environment has reached a point where protecting personal information cannot be treated simply as a matter of putting stronger security around databases.
As applications, digital services, analytics platforms, cloud environments, and third-party processors consume the same information for different purposes, a single customer record can move through considerably more infrastructure than the system in which it was originally collected.
The security environment makes that distribution increasingly important. CERT-In tracked 29,44,248 cybersecurity incidents in 2025, compared with 20,41,360 in 2024 and 15,92,917 in 2023. IBM's 2026 India findings provide a different measure of the risk: among the organizations it studied, the average cost of a data breach reached INR 25.5 crore, up 15.9% from INR 22 crore in 2025, while the average breach involved approximately 39,500 compromised records.
The Digital Personal Data Protection (DPDP) Act, 2023, introduces a useful question into this discussion. Before asking how an organization should protect every copy of personal data, it should ask whether each application, database, and business process needs access to the original data in the first place.
That is where data minimization and tokenization intersect.
Table of Contents
- What Data Minimization Actually Means Under the DPDP Act
- Common Misunderstandings About Data Minimization and Tokenization
- What a Stronger Data Minimization Architecture Looks Like
- How Futurex Supports Tokenization and Data Protection
- Conclusion
- Frequently Asked Questions
What Data Minimization Actually Means Under the DPDP Act
While the DPDP Act does not explicitly create a section titled "data minimization," the principle appears directly in how the Act limits processing.
Section 6 states that the Data Principal’s consent must be specific to a stated purpose and limited to the personal data necessary for that purpose. The illustration in the Act is deliberately simple: a telemedicine application may need personal data to provide a consultation, but access to the user's contact list is not necessary merely because the application can request it.
Section 8 addresses the other end of the lifecycle. Unless another law requires retention, a Data Fiduciary must erase personal data when the Data Principal withdraws consent or when it is reasonable to assume that the specified purpose is no longer being served, whichever occurs earlier.
The final DPDP Rules issued in November 2025 add operational detail. Rule 8 specifies erasure periods for certain large e-commerce, online gaming, and social media entities, while also requiring specified personal data, traffic data, and processing logs to be retained for the security purposes defined in the Rules, unless another applicable law requires otherwise. Most of the substantive Data Fiduciary obligations relevant here, including Sections 6 to 10 and Rules 5 to 16, are scheduled to come into force in May 2027.
For data security teams, this creates a wider definition of data minimization than simply deleting old records. It requires an organization to understand what data is necessary, where the original value needs to be available, and where a substitute value may allow the same business process to operate with less exposure.
Common Misunderstandings About Data Minimization and Tokenization
Misunderstanding 1: Encrypting personal data means it has been minimized
Encryption and minimization answer different questions. Encryption asks how information should be protected while it exists in a system. Data minimization asks whether that system needs the information in its original form at all.
An encrypted customer identifier remains the original customer identifier once an authorized application decrypts it. If twelve systems each store an encrypted copy and each has legitimate access to decrypt that copy, the organization still has twelve systems handling the original information during normal processing.
This does not reduce the value of encryption. Rule 6 specifically identifies encryption, along with obfuscation, masking, and virtual tokens, as measures that can protect personal data. The architectural mistake is treating those measures as interchangeable, even though they address different requirements.
For a system that genuinely needs the original value, encryption may be appropriate. For a downstream application that only needs a consistent reference value, tokenization may reduce unnecessary exposure more effectively.
Misunderstanding 2: Once data is tokenized, it is no longer personal data
Tokenization should not automatically be equated with anonymization.
The DPDP Act defines personal data as data about an individual who is identifiable by or in relation to that data. A token may appear meaningless to a downstream user, but if the organization can map or cryptographically transform it back into information about an identifiable individual, security teams should not assume that tokenization alone removes that information from the DPDP framework.
This has an important practical consequence. Organizations still need governance around token generation, authorized recovery or detokenization, access policies, cryptographic keys where applicable, audit logs, and the systems that retain the original values.
Misunderstanding 3: Tokenization allows the organization to retain personal data indefinitely
Reducing exposure does not remove the need to address retention.
Section 8 requires erasure when the applicable statutory conditions are met, subject to retention required by other laws. The final Rules also establish specific retention and erasure requirements for certain types of processing. A tokenization architecture must account for the lifecycle of the original data, the token, and any mechanism that allows the organization to associate the two.
This can become complicated in large environments. The original value may reside in one protected system while tokens have propagated through analytics, transaction histories, backups, and third-party applications. If a lifecycle event requires erasure or another change in how the personal data may be processed, the organization needs to know how those downstream representations relate to the original record.
Misunderstanding 4: The safest strategy is to tokenize every sensitive field
Tokenization should begin with business purpose and system behavior, not with a list of fields classified as sensitive.
Some applications require access to original data. A banking workflow may need to retrieve a regulated customer identifier, a healthcare application may need the actual patient information required for treatment, while another system may only require a reference value.
The DPDP Rules themselves point to this layered approach by identifying encryption, obfuscation, masking, and virtual tokens rather than prescribing a single mechanism for all types of personal data.
What a Stronger Data Minimization Architecture Looks Like
For data protection leaders, the practical challenge is to turn the DPDP principle of necessity into decisions that application, security, and infrastructure teams can implement.
A useful review must begin with four areas.
1. Map the purpose to the data field
Most data inventories identify which systems contain personal data. A minimization review needs to go one level deeper and ask why each system contains each important data element.
For each personal data field, identify the business purpose, the applications that consume it, the processors that receive it, and whether those systems need the original value or simply a consistent reference.
This prevents a common legacy pattern in which applications continue to receive sensitive data because the integration was designed that way years ago.
2. Reduce distribution of original values
Once the organization identifies systems that do not need the original data, redesign the workflow so those systems receive a substitute value where appropriate.
The point is not simply to transform data after it reaches every application. The stronger model limits the number of places where the original value is available.
This can be particularly useful for analytics, customer service workflows, reporting systems, internal applications, and processor integrations that need to correlate records but do not require unrestricted access to the underlying identifier.
3. Govern the path back to the original data
A token is useful because most systems cannot treat it as the original value. That advantage disappears if every application and administrator can freely reverse the tokenization process.
Organizations should define which applications may recover original values, which identities may administer tokenization policies, how those permissions are approved, and how recovery activity is logged.
Where cryptographic tokenization is used, key governance becomes part of the same control model. Security teams should understand who controls the relevant keys, how lifecycle operations are managed, and whether compromise of a downstream application gives an attacker access to both tokens and the mechanism needed to recover the underlying information.
4. Match the protection method to the workload
An enterprise data-protection architecture will usually need more than one control.
Tokenization reduces exposure in applications that require reference values; database TDE protects stored data at the database layer; application encryption protects selected fields based on application logic; and data masking prevents the unnecessary display of full values.
The objective is not to maximize deployment of any single technology. It is to use the least amount of original personal data necessary for the business process while applying appropriate safeguards to the data that must remain accessible.
How Futurex Supports Tokenization and Data Protection
Futurex approaches tokenization as part of a broader data-protection architecture rather than as a standalone substitute for other security controls.
CryptoHub, Futurex's unified cryptographic management and orchestration platform, supports tokenization, key management, transparent file encryption, database TDE, and application-layer cryptographic services. Across supported services, CryptoHub provides centralized key control, a common policy and access-control model, and unified auditability. These capabilities are defined as distinct but integrated parts of the data-protection environment, rather than assuming that every workload should use the same protection method.
Futurex also supports vaultless tokenization for appropriate use cases. In a vaultless model, tokens are generated and validated cryptographically without maintaining a centralized mapping table between tokens and their original values. This is useful where downstream systems require consistent reference values, while the organization wants to reduce operational dependence on a central token vault. Where an architecture requires hardware-backed cryptographic key protection, Futurex’s Excrypt HSMs provide the hardware-backed cryptographic foundation.
For DPDP planning, the value of this architecture is not that tokenization or an HSM automatically establishes compliance. Neither the Act nor the Rules makes that claim. The value lies in providing organizations with additional ways to reduce exposure to original data, govern cryptographic controls, and apply different protection methods based on workload.
Conclusion
The DPDP discussion on data minimization can easily turn into a debate over how much data organizations should collect. For enterprise IT teams, the harder problem starts after collection, when the same information begins moving through applications, databases, analytics environments, processor systems, and backups.
The final DPDP Act and Rules create two related responsibilities. Organizations must limit consent-based processing to personal data necessary for the specified purpose, and they need to govern how that data is protected and eventually erased when the applicable purpose or legal basis for retention ends.
Tokenization is valuable within that model because it allows some systems to work with a substitute value rather than routinely handling the original information. Its value, however, depends on where tokenization occurs, who can recover the original value, how keys and access are governed, and whether the enterprise maintains control over the complete data lifecycle.
For security teams, the pertinent question is not simply, "Which personal data should we tokenize?" It is, "Which of our systems actually need the original personal data at all?"
Answering that question first provides a much stronger foundation for both DPDP readiness and long-term data protection.
Frequently Asked Questions
Is tokenized data automatically outside the DPDP Act?
No. The Act defines personal data as data about an individual who is identifiable by or in relation to that data. If a token can still be associated with an identifiable individual through the organization's systems or an authorized recovery process, tokenization should not automatically be treated as anonymization.
Does the DPDP Act mandate tokenization?
No. Rule 6 identifies encryption, obfuscation, masking, and the use of virtual tokens mapped to personal data as examples of measures that may be used to protect personal data. It does not mandate tokenization or prescribe one universal data-protection architecture.
What is the difference between tokenization and encryption?
Encryption transforms original data into an unreadable form that can be recovered using its corresponding decryption key. Tokenization replaces the original value with a substitute that applications can use in its place. Which approach is appropriate depends on whether the application needs access to the original data, how the data is processed, and the security architecture surrounding the workload.
When should organizations consider tokenization?
Tokenization is worth evaluating when an application or processor needs a stable reference to a person or record but does not require routine access to the underlying personal data. The architecture should still address access control, authorized recovery, key governance where applicable, logging, retention, and erasure.