Access Control, Anonymisation & Sensitive Fields: Interview-Ready Analyst Framework
A product analyst opens a payments dataset to study failed checkouts and sees phone numbers, card metadata, device IDs and email addresses sitting beside revenue columns. The business wants speed; the privacy team wants control; one careless export can turn useful analysis into a regulatory, reputational and customer-trust problem.
- Start with classification: identify direct identifiers, quasi-identifiers, sensitive attributes and business-only fields before touching the data.
- Access control answers: who can access which field, for what purpose, at what privilege level, for how long.
- Use least privilege: analysts usually need aggregates, masked fields or pseudonymous IDs - not raw phone numbers, PAN, card numbers or health data.
- Anonymisation is not masking: true anonymisation should make re-identification reasonably impossible; masking only hides part of a value.
- Hashing is not automatically safe: hashed phone numbers or emails can often be guessed unless salted, keyed and access-controlled.
- Separate data from keys: token maps, encryption keys and re-identification keys must sit in restricted systems with audit trails.
- Track controls like operations: measure privileged access, stale access, policy violations, unresolved sensitive fields and audit-log coverage.
The clean mental model is a ladder: the lower you are, the closer you are to raw personal data and the tighter the access must be. Good analysts climb the ladder by transforming data until it is still useful for decisions but much safer to handle.
Core Explanation: The Analyst's Privacy Control Stack
Access control, anonymisation and sensitive-field handling are not three separate topics. They are one operating system for safe analytics: classify the field, restrict who can see it, transform it where possible, and prove through logs that the rule was followed.
Think of every dataset through four questions:
1. Classify Fields Before You Analyse
Most privacy mistakes begin because all columns are treated equally. A clean data dictionary should tag fields by risk and business need.
India's Digital Personal Data Protection Act, 2023 uses the term personal data broadly. Even if a field looks harmless alone, it can become personal data when combined with another dataset that identifies an individual.
2. Apply Access Control: Who Can Do What, For How Long
Access control decides who can perform which action on which data, under which conditions. In analytics, it should operate at four levels:
The most common models are:
- RBAC - Role-Based Access Control: access depends on role, such as analyst, manager or admin. It is simple and scalable.
- ABAC - Attribute-Based Access Control: access depends on attributes such as location, project, device, data sensitivity, time or purpose. It is more precise.
- JIT access - Just-in-Time access: elevated access is granted temporarily after approval and expires automatically.
- Break-glass access: emergency access for rare incidents, always heavily logged and reviewed.
3. Choose the Right Transformation
Transformation is where many candidates blur concepts. The interviewer is checking whether you know the difference between hiding, replacing, encrypting and truly anonymising.
Definitions You Should Be Able to Say Cleanly
- Personal data - DPDP Act, 2023: "any data about an individual who is identifiable by or in relation to such data."
- Personal data - GDPR Article 4(1): "any information relating to an identified or identifiable natural person."
- Confidentiality - ISO/IEC 27000: "property that information is not made available or disclosed to unauthorized individuals, entities, or processes."
- Access control: the rules and mechanisms that allow, deny and log actions on data assets.
- Anonymisation: irreversible transformation that makes a person not reasonably re-identifiable from the dataset.
- Pseudonymisation: replacing identifiers with alternate values while keeping re-identification possible through separate information.
Metrics: How to Know the Control Is Working
Privacy control should not be a vague assurance. A strong analytics team measures whether access is justified, current, logged and reduced over time.
Case Study - Razorpay: Tokenising Card Data for Safer Payments
Razorpay's card tokenisation solution shows how sensitive payment fields can be made safer without breaking checkout convenience.
Situation: Indian digital payments businesses had to respond to the Reserve Bank of India's card-on-file tokenisation framework. The core issue was simple: merchants and payment intermediaries needed recurring and returning-customer payments to stay smooth, but raw card details should not sit broadly across merchant systems.
The move: Razorpay built and offered tokenisation capabilities, including its TokenHQ solution, to help businesses replace actual card details with tokens issued through the card network ecosystem. The primary driver was regulatory and security compliance - reducing exposure of raw card data. Supporting drivers were equally important: preserving checkout experience for returning users, centralising sensitive mapping in a more controlled layer, and reducing the number of systems that touched raw payment credentials.
Outcome and lesson: The strategic lesson is not "tokenisation solves everything." It works because tokenisation is combined with access segregation, regulatory alignment, secure vaulting, masking and operational monitoring. For an analyst, the correct takeaway is: use the token to join and analyse behaviour; do not ask for the raw credential unless there is a narrow, approved purpose.
How AI Changes Access Control, Anonymisation & Handling Sensitive Fields
AI raises the stakes because sensitive data can now leak through prompts, embeddings, training datasets, model outputs and auto-generated reports. The analyst's job is not only to protect tables, but also to protect the data supply chain feeding AI tools.
- AI-assisted data discovery: modern data catalogues and DLP tools can scan schemas, sample values and metadata to flag likely phone numbers, emails, Aadhaar-like patterns, card fields, health terms or location trails. Human review still matters because context decides sensitivity.
- LLM redaction and safe summarisation: teams increasingly use AI to redact names, account numbers and free-text PII from support tickets, call transcripts and research notes before analysis. The risk is false negatives - one missed identifier can contaminate the downstream dataset.
- Access-log anomaly detection: machine learning can flag unusual exports, rare table access, access outside normal hours or an analyst querying far more records than usual. This strengthens monitoring but should not replace approval and least privilege.
Use a mock schema, not real customer data. Paste a data dictionary into NotebookLM or ChatGPT and ask: "Tag each field as direct identifier, quasi-identifier, sensitive attribute or business field; suggest the safest analyst-ready transformation; list access roles and audit controls." Then compare the output with DPDP purpose and retention requirements.
Interview Relevance
"You are given a customer transactions table with phone number, email, location, payment status, order value and complaint notes. How would you make it safe for analysts while keeping it useful?"
Use the phrase "safest useful form". It signals maturity: you are not blocking analysis, you are reducing identity exposure while preserving decision value.
Common Mistake
Calling masked, hashed or pseudonymised data "anonymous"! This costs candidates because it shows they do not understand re-identification risk. One-line fix: say, "I will treat it as personal data unless re-identification is not reasonably possible, considering other available datasets and keys."
What to Revise Next
Next, connect this control stack to the legal and lifecycle side of privacy. Revise India's Data Protection Law: What Analysts Must Design For to understand DPDP obligations, then move to Consent, Purpose Limitation & Data Retention in Practice to learn when data can be collected, used and deleted.