Data AnalyticsAI careers in practice

DPDP Act 2023 basics for data analysts: what changes in your work

PK
Pankit Kumar
Sr. Data Scientist at Parexel (a Goldman Sachs–backed company) · 27 September 2026 · 5 min read
In this article (7 sections)

Related programme: the Data Analytics with Generative AI course (3–4 months; ₹90,000 (inclusive of GST) · EMI from ₹4,000/month).

The short answer

The Digital Personal Data Protection Act, 2023 changes a data analyst's work mainly at five points: when you request or share an extract, when you join datasets for a new purpose, when you paste data into an AI or third-party tool, when someone asks for their data to be deleted, and when you decide how long to keep working files. The Act places obligations on the organisation, and your company's policy will set the exact rules, but knowing the reasoning helps you ask the right questions before your work creates a problem.

This article reads the official Act text (Act No. 22 of 2023, dated 11 August 2023). The DPDP Rules, 2025 were notified with an 18-month phased compliance timeline, per the PIB release of 14 November 2025. This is general information, checked on 27 September 2026, not legal advice.

Five words you'll hear in meetings

  • Data Principal: the person the data is about — a customer, employee, patient.
  • Data Fiduciary: the organisation that decides why and how the data is processed.
  • Data Processor: an entity processing data on the Fiduciary's behalf under contract, such as a vendor.
  • Specified purpose: the purpose stated in the notice given to the person.
  • Processing: almost anything you do with data — the Act's definition includes collection, storage, retrieval, use, combination, indexing, sharing and erasure.

That last definition is why analysts should care: querying, joining and exporting all count.

Situation 1: "Can you send me the full customer table?"

A colleague in another team asks for a full export. Before sending, ask what they need it for. Section 6(1) says consent must be limited to the personal data necessary for the specified purpose, and the Act's approach follows that principle throughout. In practice:

  • Send only the columns needed. A churn analysis rarely needs phone numbers.
  • Aggregate where possible. Counts by city may answer the question without any rows about individuals.
  • Use your company's approved sharing method, not personal email or chat.

Situation 2: joining datasets for a new purpose

You are asked to join support-ticket data with purchase history to target a marketing campaign. The tickets were collected to resolve complaints. Using them for marketing may fall outside the purpose customers were told about. Sections 4 to 7 tie processing to consent for a specified purpose or to listed legitimate uses. This is not your call to make alone — but it is your job to raise it: "These tickets were collected for complaint handling; can privacy confirm this use is covered?"

Situation 3: pasting data into an AI tool

Pasting customer rows into an AI assistant is processing, and if the tool is run by a third party, it may involve sharing with a processor. Use only tools your organisation has approved for that data class. For analysis you want to try in a general tool, remove or replace identifiers first.

A simple pseudonymisation step you can run before exploratory work. The data is synthetic:

python
import hashlib
import hmac
import csv
import io

SECRET = b"store-this-in-a-vault-not-in-code"   # illustration only

raw = io.StringIO(
    "customer_id,name,phone,city,orders\n"
    "C001,Asha Verma,9800000001,Noida,4\n"
    "C002,Ravi Singh,9800000002,Ghaziabad,1\n"
    "C003,Meena Rao,9800000003,Noida,7\n"
)

def pseudonym(value: str) -> str:
    return hmac.new(SECRET, value.encode(), hashlib.sha256).hexdigest()[:12]

out_rows = []
for row in csv.DictReader(raw):
    out_rows.append({
        "customer_key": pseudonym(row["customer_id"]),
        "city": row["city"],
        "orders": int(row["orders"]),
    })   # name and phone dropped entirely

for r in out_rows:
    print(r)

assert all("name" not in r and "phone" not in r for r in out_rows)
assert len({r["customer_key"] for r in out_rows}) == 3

Two points. Direct identifiers are dropped, not hashed, because the analysis doesn't need them. And the customer key is a keyed hash: the organisation holding the secret can still link rows back, so the output is still personal data for the organisation. It reduces exposure; it does not take the data out of scope.

Situation 4: a deletion request arrives

Section 8(7) requires the Fiduciary to erase personal data when consent is withdrawn or the purpose is no longer served, unless the law requires retention, and to make its processors erase it too. The PIB release states that rights requests must be answered within a maximum of 90 days. For analysts, the hard part is finding every copy:

Where your data may liveQuestion to ask
Source tablesHandled by the system owner?
Your working extracts and CSVsDo you know every file that contains this person?
Dashboards with row-level dataWill the refresh remove them?
Derived tables and featuresAre they rebuilt from source, or stored separately?
AI indexes or embeddingsCan a record be removed from the index?

If you cannot answer the second row, that is a sign your working files are unmanaged.

Situation 5: keeping files "just in case"

Analysts often keep old extracts for months. The Act's erasure duty applies when the purpose is no longer served. Set a habit: delete ad-hoc extracts when the analysis is delivered, keep only aggregated outputs, and follow your organisation's retention rules for anything else.

Why this matters for your career

Organisations need analysts who can deliver insight without creating privacy risk. In interviews, a sentence like "I dropped direct identifiers before analysis and checked with the privacy team before joining complaint and purchase data" signals maturity. The Schedule to the Act sets penalties that may extend to hundreds of crores of rupees for some breaches, so employers take this seriously.

For which analysis tasks should stay out of AI tools altogether, see analyst tasks you should not hand to an LLM, and for the wider policy picture, India's AI policy context. The Data Analyst programme, which runs 3–4 months, teaches working with confidential business data safely alongside SQL, Power BI and GenAI.

Frequently asked questions

Does the DPDP Act apply to data analysts personally?

The Act's obligations fall mainly on the Data Fiduciary — the organisation that decides the purpose and means of processing, usually your employer. Analysts are the people who carry out much of that processing, so your employer's policies will translate the Act into rules for your daily work.

Is pseudonymised data outside the DPDP Act?

Not automatically. The Act defines personal data as data about an individual who is identifiable by or in relation to that data. If the organisation can re-identify people from a pseudonymised table, for example with a key it holds, treat it as personal data and ask your privacy team.

PK
Pankit Kumar
Lead Instructor, NeuraPath Academy

Pankit Kumar has 10 years in Data Science & AI, building and shipping production systems in regulated pharma and clinical environments. He is a freelance trainer at Boston Institute of Analytics, AnalytixLabs and Scaler, and has taught this material to thousands of working professionals.

This article is part of our Data Analytics with Generative AI programme — 3–4 months. The full analyst stack — Excel, SQL, Power BI and Python pipelines — then a generative-AI layer you can prove is right.

Explore Data Analytics with Generative AI
Counselling is free · no obligation

Not sure which programme fits?

Tell us your background and we will map it to the right entry point — including saying so when a cheaper programme is the better fit. A counsellor replies within one working day.