Your app holds names, phone numbers, PAN numbers and addresses. That data rarely stays in one place. It flows into analytics, the support desk, a CRM vendor and, more and more, an AI assistant. PII tokenization is one way to keep the real values in one locked place and pass harmless stand-ins everywhere else. India’s DPDP Rules mention it by name, which is why it keeps coming up in DPDP conversations.
Below, we’ll cover what tokenization is, how it compares with encryption, masking and hashing, where each one fits, and what it does and doesn’t do for DPDP. If you want the full build plan, see our DPDP implementation roadmap. For the evidence side, see DPDP proof packs. This post looks at one control in detail.
Written as of 24 October 2026. This is our plain-language reading of the DPDP Act and Rules, not legal advice. Check how they apply to your business with qualified counsel.
What PII tokenization is
Tokenization swaps a sensitive value for a stand-in, called a token, that means nothing on its own. The link between the token and the real value is kept somewhere you control.
Think of a cloakroom ticket. The ticket is useless to a thief unless they can also get into the cloakroom.
In practice, a customer’s phone number might be stored in your analytics tool as a random string. The analytics team can still count customers and follow journeys. Only one protected service can turn that string back into the real number, and only for people and systems allowed to ask.
Vault and vaultless tokens
There are two main ways to do it.
Vault tokenization
The token is random, and a protected database, the vault, keeps the table that maps each token to its real value. A stolen token reveals nothing, because there’s no maths to reverse. You need the vault.
The trade-off is that the vault becomes one of your most important systems. It needs strict access control, logs of who looked up what, backups and high uptime. If the vault is down, anything that needs the real value stops working.
Vaultless and format-preserving tokens
Here the token is calculated from the real value with a secret key, so there’s no lookup table. A common method is format-preserving encryption, which keeps the shape of the data: a 10-digit number stays a 10-digit number, so older systems keep working without changes.
NIST describes this in SP 800-38G. Its 2025 draft revision keeps the method called FF1 and drops FF3, so if a vendor offers format-preserving tokens, ask which one they use.
The trade-off: whoever holds the key can reverse every token. So looking after that key matters more than anything else here. Our post on key and secret hygiene covers the basics.
One more choice applies to both. Tokens can be deterministic, where the same input always gives the same token, or random each time. Deterministic tokens let analytics join and count records, but they also show patterns, such as how often one customer appears.
How tokenization compares with encryption, masking and hashing
All of these hide data. The real difference is whether you can get the original value back, and who can.
| Technique | Can you get the real value back? | Still personal data under DPDP? (our reading) | Good for |
|---|---|---|---|
| Vault tokenization | Yes, through the vault only | Yes, if the vault can map it back | High-risk fields, sharing with vendors |
| Vaultless or format-preserving tokens | Yes, with the key | Yes, while the key exists | Older systems that need the same format |
| Encryption | Yes, with the key | Yes | Stored data, backups, data in transit |
| Masking | Static: no. Dynamic: the data is unchanged, only the view is hidden | Often yes, depending on what is left visible | Test data, support screens |
| Hashing | Not directly, but short values can be guessed | Usually yes for phone numbers and emails | Matching and removing duplicates |
A few notes in plain words:
- Encryption scrambles data with a key. It’s the base layer for stored data and data in transit, but apps usually decrypt data to use it, so it’s exposed while in use.
- Masking shows part of a value, like the last four digits, or replaces it with fake data. Static masking for test data is one-way. Dynamic masking only hides what appears on screen.
- Hashing is one-way, but a phone number has a small set of possible values. Someone can hash every possible number and compare. A hashed phone number should be treated as personal data.
- Pseudonymisation is the umbrella idea of replacing identifiers. It comes from Europe’s GDPR. The DPDP Act and Rules don’t use the word.
What the DPDP Act and Rules say
The Act asks every business that decides how personal data is used (a “Data Fiduciary”) to take “reasonable security safeguards to prevent personal data breach” (Act, s.8(5)). That includes processing done by vendors on its behalf. The Act itself names no technique.
The DPDP Rules 2025 give more detail. Rule 6(1)(a) lists “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”.
Two things stand out. Tokens appear as one example, after “such as”, alongside three others, so the Rules don’t require tokenization. And Rule 6 lists six more minimum measures: access control, logs and monitoring, backups, keeping logs for one year, security terms in vendor contracts, and other technical and organisational measures. A token vault needs all of those too.
The words tokenization, pseudonymisation and anonymisation don’t appear anywhere in the Act or the Rules.
These duties start in May 2027, 18 months after the Rules were notified on 13 November 2025, unless MeitY notifies a change.
What tokenization does for you
Used well, tokenization cuts down the number of systems that hold real personal data. Your analytics, support and vendor tools work with tokens, and only a few services ever see the real values.
That helps in practical ways:
- A breach of a tokenized system exposes less.
- Access reviews and vendor contracts get simpler, because fewer people and tools can see real data.
- Your evidence gets cleaner. As our proof packs post suggests, an evidence pack should hold tokens and counts rather than names.
- If something does go wrong, the Board weighs factors such as the type of data affected and any steps taken to reduce harm (Act, s.33(2)). In our reading, tokenization can be part of that story. It doesn’t promise a lower penalty.
India has done this before for one kind of data. RBI’s 2021 card tokenisation circular moved stored card details to tokens, with the deadline later set at 30 September 2022. Those rules cover card data only.
What tokenization doesn’t do
- Tokenized data can still be personal data. The Act defines personal data as data about an individual “identifiable by or in relation to such data” (s.2(t)). If anyone can map a token back to a person, we read it as personal data. There is no anonymisation exemption in the Act or Rules.
- Your other duties stay the same. Consent, notices, purpose limits, people’s rights and erasure all still apply. Erasure has to reach the vault and every copy of the token.
- Breach reporting still applies. Rule 7 asks you to tell affected people and the Data Protection Board without delay, with a detailed report to the Board within 72 hours. It has no exemption for tokenized or encrypted data. If only tokens leak, plan to treat it as a breach and ask your counsel.
- The vault and keys become the main target. Protect them first.
- Penalties are ceilings. Failing to take reasonable security safeguards can draw a penalty of up to ₹250 crore, set only after a Board inquiry finds a significant breach.
Where we’d start
- List the riskiest fields. The handful of values that would hurt most if leaked, such as PAN or bank details, and every system that holds them.
- Choose per system. Tokenize, encrypt, mask, or stop collecting the field. Not collecting it is often the best answer.
- Decide vault or vaultless, and who holds the keys. By default, that should be your company rather than a vendor.
- Log every lookup of a real value and review those logs regularly.
- Add vault and key logs to your proof pack.
- Ask counsel how you would handle a leak of tokens only under Rule 7.
In closing
Tokens are good at one job: keeping real values out of places that don’t need them. They sit inside a wider DPDP programme of consent, rights, security and breach response, and work best when planned that way. Details are as of 24 October 2026, and this isn’t legal advice.
Bluelupin builds web and mobile platforms with data protection designed in. If you’d like help working out which fields to tokenize and where, talk to us.