Masking
Hiding part of a data value so that it cannot be read in full.
Masking hides part of a piece of data, such as showing only the last four digits of a phone number, so people see just what they need to do their job.
Meaning of Masking
Masking shows only what a person needs to see, such as the last four digits of a phone number. Rule 6 lists masking as a safeguard. It is useful in customer-support screens and in test environments.
Masking replaces some or all characters of a value with symbols or substitute characters while keeping the format familiar. A card number shown as XXXX XXXX XXXX 4321, an Aadhaar number displayed with only its final four digits, or an e-mail shown as a***@example.com are typical examples. The original value remains stored elsewhere; masking controls only what a given person or screen displays.
Rule 6 of the DPDP Rules 2025 names masking along with encryption, obfuscation and virtual tokens as measures a Data Fiduciary may use to meet the reasonable security safeguards duty in Section 8(5). Because the Rule says "appropriate", there is no fixed pattern. You decide how much to reveal for each role, balancing usefulness against the chance of misuse.
There are two main forms. Dynamic masking changes what is shown at query time, so the same record appears masked to a support agent and complete to a fraud analyst with the right permission. Static masking creates a permanently altered copy, useful for training and test environments where realistic data is needed but real identities are not.
Masking is lighter than encryption, because the full value is still readable by systems and administrators with access. It also differs from anonymisation: a masked record can often be linked back to a person through other fields, so it remains personal data. Think of masking as applying data minimisation to what people see on screen, printouts and exports.
Examples of Masking
A support agent sees "XXXXXX4321" instead of a full phone number.
A telecom operator shows agents only the last three digits of a subscriber's Aadhaar-linked number. If a customer needs full verification, the agent raises a request that a supervisor approves, and the reveal is logged.
An insurer uses a masked copy of its claims database for staff training. Names, phone numbers and policy numbers are replaced with look-alike values, so trainees learn the workflow without seeing any real claimant.
A marketplace shows sellers a courier phone number partly hidden and a buyer's address in short form. Developers later notice that raw addresses were still being written to error logs and update the logging rules.
Why Masking matters
Many breaches are not external attacks but accidents and misuse from inside: an agent reading out a full account number, a spreadsheet sent to the wrong person, a screenshot shared on a messaging app. Masking reduces the personal data exposed in each of these moments, so the impact of any single slip is smaller.
It also supports compliance beyond security. Showing a clerk only the fields needed for a task is consistent with limiting processing to the stated purpose, and masked test data keeps real customer records out of less protected environments, where the penalty for failing safeguards could apply.
How it works in practice
- 1List the screens, reports, exports, logs and test databases that display personal identifiers, and decide for each role which parts of each field are really needed.
- 2Apply masking rules in the application or database layer, not just in the front-end design, so an API call or export cannot bypass them.
- 3Use dynamic masking for live systems with a controlled reveal function that asks for a reason and records who revealed what.
- 4Create masked copies of production data for development, analytics training and vendor demos, and confirm that the masking cannot be reversed by comparing fields.
- 5Mask identifiers in application logs and error messages so logs retained for a year do not hold full numbers, and review the rules when fields are added.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Masking only in the user interface. If the underlying API or export still returns the full value, the protection is cosmetic.
Using the same masking pattern for every role. Some roles need none and some need more, so tailor it to purpose.
Assuming masked data is anonymous. Combined fields such as city, birth date and masked number may still identify a person.
Ignoring logs and test data. These are common places where unmasked identifiers pile up unnoticed.
Compliance tips
Start with the highest-risk identifiers, such as financial account numbers, government IDs and health fields, and expand outward.
Pair masking with access control so the reveal function is limited and logged.
Check masked outputs by trying to reconstruct the original value from what is displayed.
Document the masking rules in your security policy so you can show them as part of Rule 6 compliance.
Common questions about Masking
What is data masking?
Masking hides some characters of a value, such as showing only the last four digits of a number. It limits what people see while the full value stays stored securely for systems that need it.
Is masked data still personal data under the DPDP Act?
Usually yes. A masked record can often be linked to a person through other fields or the original system, so the Act continues to apply unless the data is truly anonymised.
How is masking different from tokenisation?
Masking hides part of the value for display. [Tokenisation](term/tokenisation) replaces the whole value with a random token and keeps the original in a separate secure vault, so systems can work with tokens and not the real number.