India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Privacy Engineering for Analytics: Masking, Tokenisation and DPDP
Data security and privacy for analytics means protecting personal and sensitive data inside lakes, warehouses and BI: tokenising or masking identifiers, enforcing row- and column-level access, and limiting use to consented purposes with erasure when purposes end. NTSPL engineers these controls for Indian organisations processing customer data under the DPDP Act 2023 and sector regulators.
Delivered on
In scope
How Personal Data Multiplies Inside Analytics
Analytics platforms are where personal data spreads quietly. A customer's phone number collected for a site visit ends up in the lake, three marts, a churn feature table, an agency's Excel and a partner dashboard. Under the DPDP Act 2023 each of those copies is processing that needs a lawful purpose, safeguards and deletion when the purpose ends, yet most analytics teams cannot list where a single phone number lives.
NTSPL designs privacy into the data flow rather than bolting it onto reports. Identifiers are tokenised at ingestion so most users never see raw values, sensitive columns carry policy tags that drive masking everywhere, and each dataset records its permitted purposes. Erasure requests propagate to every copy, including snapshots and feature tables, and leave evidence behind. Access is recertified every quarter.
When Analytics Privacy Controls Are Overdue
Signals you need Data Security & Privacy
- More than 50 analysts, agencies or partners can query tables containing phone numbers, emails, PAN or addresses
- You cannot locate every copy of a customer's data within 72 hours when asked to erase it
- Marketing or partner analytics uses customer data collected for a different purpose, without a consent check
- Auditors, IRDAI or RBI inspections have flagged unmasked personal data in reporting or test environments
When to choose something else
- You need platform-wide encryption, key management and DLP across all cloud resources: that is Data Security & Encryption in our Cloud Security family.
- Your concern is application secrets and key rotation: see Secrets & Key Management.
Tokenisation, Fine-Grained Access and Purpose Controls
Personal data discovery
Automated scans of lakes, warehouses and BI datasets to find personal and sensitive columns, verified by data owners.
Tokenisation and pseudonymisation
Deterministic tokens for identifiers so joins still work, with a separately secured vault or key for re-identification.
Fine-grained access
Column policy tags, dynamic masking and row-level filters driven by role, region and purpose, consistent across engines and BI.
Purpose and consent binding
Each dataset carries permitted purposes; consent flags from source systems filter records out of marketing and partner uses.
Erasure and retention
Automated erasure across lake, warehouse, snapshots, features and extracts, with retention clocks per purpose and evidence logs.
How Data Security & Privacy Works, Step by Step
Tokenise-at-Ingest Privacy Architecture
Personal identifiers are detected and tokenised as data lands, so downstream zones carry tokens. Policy tags, purpose filters and masking govern access, while erasure jobs propagate deletions to every copy and log evidence.
Select any component
Tokenise-at-Ingest Privacy Architecture: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Privacy Controls on AWS, Azure and Google Cloud
Macie discovers personal data in S3; Lake Formation cell filters and Redshift masking enforce column and row rules; Clean Rooms supports partner analysis without sharing raw records.
Purview classifications and labels flow into Fabric and Power BI, so a labelled column stays protected when exported to Excel.
Sensitive Data Protection de-identifies with deterministic or format-preserving encryption; policy tags drive both column access and masking rules in BigQuery.
Tokenisation, Masking and Consent Design Choices
Tokenise, mask or encrypt
Tokenise identifiers used for joins, such as phone, customer ID or PAN, with deterministic tokens so analytics works without raw values. Use dynamic masking for attributes some roles need partially, such as the last four digits for call-centre verification. Field-level encryption suits small, highly sensitive sets like health conditions. Most analysts should never need re-identification.
Where to apply controls
Apply tokenisation at the landing zone, before data fans out; masking applied only in BI tools leaks through SQL access, exports and notebooks. Define column policies once in the catalogue (Lake Formation, Purview, policy tags) so every engine enforces them. Test by querying from each engine and BI tool with a restricted role.
Binding purpose and consent
Record permitted purposes per dataset in the catalogue and bring consent flags from CRM or consent managers into analytics as a consent table keyed by token. Marketing, partner and model-training views join to it and exclude records without the right consent. Refresh at least daily so withdrawals take effect quickly, as the DPDP Act requires withdrawal to be as easy as consent.
Designing for erasure
Index every table containing a personal token so an erasure request can find all rows quickly. Delete or overwrite rows, expire lakehouse snapshots, purge feature stores and regenerate scheduled extracts. Target completion within a defined internal SLA, for example 15 days, and keep logs showing what was erased and when, without retaining the erased values.
Privacy Controls Rollout Across the Data Estate
Discovery and purpose mapping
Scan the estate for personal data, verify with owners and map each dataset to purposes.
Tokenisation at ingestion
Deploy the tokenisation service and vault, and re-tokenise historical data in priority zones.
Policy tags, masking and row filters
Tag columns, implement masking and consent filters, and test each engine with restricted roles.
Erasure orchestration
Build fan-out erasure across tables, snapshots, features and extracts with logs.
Access recertification and handover
Recertify all access, revoke excess grants and set the quarterly review.
What you receive
Exposure, Erasure and Access Measures
| KPI | Typical target |
|---|---|
| Users with access to raw personal identifiers | Under 5% of analytics users |
| Personal columns tagged and policy-controlled | 100% of discovered columns |
| Erasure completion across all copies | Within internal SLA, typically 15 days |
| Analytics views honouring consent filters | All marketing, partner and training views |
Privacy Gaps We Commonly Find and Close
| Risk | How NTSPL prevents it |
|---|---|
| Personal data reappears through exports and notebooks | Tokenisation at landing means exports carry tokens; bulk exports of tagged columns raise alerts. |
| Erasure misses snapshots, backups or feature stores | Erasure orchestrator covers every registered store; snapshots are expired and backup retention is documented. |
| Masking differs between engines and BI tools | Policies defined once in the catalogue and tested from each engine with restricted roles. |
Tokenisation vs dynamic data masking: which protects analytics data better?
Tokenisation protects better because raw values never enter downstream zones; even an admin or a leaked export sees only tokens, while deterministic tokens keep joins and counts working. Dynamic masking is a presentation control: raw data is stored, and the engine hides it from roles without permission. It is useful for partial display and for columns that some roles genuinely need. The strongest pattern combines both: tokenise identifiers at ingestion, then use masking for the few attributes that must stay readable to selected roles.
Key facts: Data Security & Privacy
Data Security & Privacy in Practice
2 Data Security & Privacy scenarios, from Real estate (residential developer) and Logistics (express parcel and courier), plus related platform case studies.
Real-estate developer stops sharing raw buyer leads with 140 channel partners
Express logistics firm tokenises 9 crore consignee records across lake and franchise BI
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
Three directories become one: identity consolidation after two acquisitions
Data Security & Privacy: Frequently Asked Questions
What does the DPDP Act 2023 require of our analytics platform?
As a Data Fiduciary you must process personal data only for lawful purposes, apply reasonable security safeguards, honour withdrawal of consent and erase data when the purpose is served. For analytics this means purpose mapping, minimisation, access controls, erasure across copies and breach readiness.
Can analysts still work with tokenised data?
Yes. Deterministic tokens let analysts join, count and segment customers without seeing phone numbers or emails. Only a few processes, such as a dialler or a fulfilment system, can re-identify through the vault, and every such call is logged. Most teams notice no difference in their work.
How much does a privacy engineering engagement cost?
For a typical lake and warehouse with 100-400 personal columns, a 10-12 week engagement costs INR 30-60 lakh. Running costs for discovery scans and tokenisation are usually modest, a few lakh a month at most. Fees vary with source count and engines.
Do CERT-In rules affect analytics platforms?
Yes. CERT-In's 2022 directions require reporting of specified cyber incidents within 6 hours and retention of ICT logs for 180 days in India. We retain query and access logs for analytics platforms accordingly and alert on bulk exports of personal data.
How do we share data with partners without exposing customers?
Share aggregates or tokenised records with consent filters applied, or use clean-room services such as AWS Clean Rooms or BigQuery data clean rooms, where both sides analyse overlapping audiences without seeing each other's raw records. Partners get only what their purpose needs.
What about children's data on our platform?
The DPDP Act requires verifiable parental consent for processing children's data and bars tracking, behavioural monitoring and targeted advertising directed at children. We tag such records at ingestion and exclude them from marketing analytics and model training by default. Controls are tested before go-live.