The DPDP Act for engineers: what changes in your code, databases and logs

Most guides to India's Digital Personal Data Protection Act are written by lawyers, so they focus on notices, consent forms and policies. Those matter. But the duties that are hardest to meet sit in your systems: where personal data is stored, who can read it, how long it stays, whether deleting a user actually removes them, and whether you could detect and report a breach within hours.

This guide maps the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 to the engineering work they create. It quotes the official text and says where that text leaves room for interpretation. It is written for CTOs, engineering leads and the engineers who will build the fixes.

Does it apply to you?#

Almost certainly, if people in India use your product. The Act applies to digital personal data processed in India. It also applies outside India when the processing is "in connection with any activity related to offering of goods or services to Data Principals within the territory of India" (section 3). There is no size threshold. A 20-person company and a listed one have the same core duties. The main extra duties apply to companies the government names as Significant Data Fiduciaries, covered below.

The definition of personal data is broad: "any data about an individual who is identifiable by or in relation to such data" (section 2(t)). In engineering terms, that is much more than names and phone numbers. A user ID in an event stream, a device ID, an IP address tied to an account, a support ticket, a free-text notes field and a phone number written into a log line all count. Each one relates to a person you can identify.

Two things the Act does not do may surprise anyone who knows GDPR:

• It has no separate "sensitive" category. Health and financial data get the same legal treatment as any other personal data. Children's data is the exception, with its own rules.
• It covers digital personal data only. This includes data collected on paper and digitised later. It does not cover data a person has made public about themselves (section 3(c)).

Four terms you need#

• Data Fiduciary: you. The Act defines it as anyone who "determines the purpose and means of processing of personal data", alone or with others.
• Data Principal: the person the data is about. For a child, this includes the parent.
• Data Processor: anyone who processes personal data on your behalf. Your cloud provider, email and SMS providers, analytics tools, CRM, support desk and error tracker are typical examples.
• Processing: almost anything you do with data. Section 2(x) lists collection, storage, use, sharing and even "erasure or destruction".

The sentence that matters most for engineering is in section 8(1):

How your vendors handle your users' data is your responsibility. Every SaaS tool and SDK that receives user data is in scope.

The duties, mapped to your systems#

1. Notice and consent you can prove

Where consent is the basis for processing, it must be "free, specific, informed, unconditional and unambiguous with a clear affirmative action". It must also be "limited to such personal data as is necessary for such specified purpose" (section 6(1)). The notice has to include "an itemised description of such personal data" and the purpose of each use (Rule 3).

The Act's own example is a telemedicine app that also asks for the phone's contact list. The contact list isn't needed for telemedicine, so the consent covers only the telemedicine data. Review your app permissions and form fields the same way: if the service doesn't need it, don't ask for it.

The engineering duty is in section 6(10). If consent is questioned in a proceeding, "the Data Fiduciary shall be obliged to prove that a notice was given by her to the Data Principal and consent was given". A checkbox in a banner script proves very little. You need:

• A consent record for each user. Store the notice version shown, the purposes accepted, the timestamp, the channel (web, Android, iOS) and any later withdrawal. Keep it server-side and append-only.
• Versioned notices, so you can show exactly what a user saw on a given date.
• Purpose checks where data is used, not only where it is collected.

// Illustrative: check current consent before sending data to a marketing tool.
export async function trackMarketingEvent(userId: string, event: MarketingEvent) {
  // Read the server-side consent record, not a cookie.
  const consent = await consentStore.latest(userId);
  if (!consent?.purposes.includes("marketing_analytics")) return;
 
  await marketingTool.track({ userId, ...event });
}

Not all processing needs consent. Section 7 lists "certain legitimate uses", such as data a person gave you for a purpose without objecting, or medical emergencies. Which basis applies to which data flow is a legal question. The engineering need is to tag each data flow with its purpose, so your lawyer's answer can be applied in code.

2. Withdrawal that reaches every system

People can withdraw consent "at any time, with the ease of doing so being comparable to the ease with which such consent was given" (section 6(4)). After a withdrawal, you must "within a reasonable time, cease and cause its Data Processors to cease processing" (section 6(6)).

If sign-up takes one tap, withdrawal shouldn't need an email to support. And the withdrawal has to reach every system that acts on it: marketing automation, product analytics, ad audiences, push notification tools and CRM.

The test is simple. Withdraw consent on a test account, then check a day later whether its events still reach those tools.

3. Security safeguards (Rule 6)

Section 8(5) requires "reasonable security safeguards to prevent personal data breach". Rule 6 sets the minimum:

Here is what each clause means in practice:

• (a) Encryption, masking, tokens. Encryption at rest and in transit is the baseline. For high-risk fields such as ID numbers and health records, consider field-level encryption or tokenisation, so that a database dump or an analyst's query doesn't expose them. Mask values in admin panels and support tools.
• (b) Access control. Least privilege, MFA, no shared database credentials, and a regular review of who can query production and export data.
• (c) Visibility on access. This means logs of who accessed personal data, not just application logs. Think database audit logs, cloud audit logs for storage reads, and an audit trail in internal tools that records who viewed which user's record.
• (d) Backups, so you can keep operating if data is destroyed or encrypted.
• (e) One year of retention for those logs, unless another law requires something different.
• (f) Contracts that require your processors to keep safeguards too.

Long log retention creates a problem most teams don't see coming. Clause (e) covers the access logs in clause (c). But Rule 8(3) also asks you to keep "associated traffic data and other logs of the processing" for at least a year (see section 5 below), and CERT-In asks for logs of all your systems (see below). Application logs are full of personal data that nobody meant to put there: phone numbers in OTP messages, email addresses in error traces, full request bodies in debug logs. Keep those for a year and you multiply what you have to protect and later delete.

The fix is to log internal IDs instead of values, redact at the logger, and keep access and audit logs separate from short-lived debug logs. To see how big the problem is, search your codebase for log statements that mention personal fields:

# Illustrative: log calls that mention common personal-data fields.
rg -n -i '(log(ger|ging)?|console)\.\w+\(.*(phone|mobile|email|otp|aadhaar|address|dob|\bpan\b)' src/

The CERT-In rule is broader still. Its directions of April 2022 require companies to "enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days", and those logs "shall be maintained within the Indian jurisdiction". If your log or error-tracking vendor stores data outside India, check this with your lawyer.

4. Breach reporting

A "personal data breach" includes "any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data" that "compromises the confidentiality, integrity or availability of personal data" (section 2(u)). That covers more than a hacker stealing a database. A public storage bucket can count. So can ransomware, or an accidental deletion you can't restore. The text has no size or harm threshold.

Two clocks start when you find out. CERT-In expects a report within 6 hours. The Data Protection Board must be told "without delay", and given a detailed report within 72 hours (Rule 7). Affected users must also be told without delay. The full runbook is in Breach response in India: the 6-hour CERT-In and 72-hour DPDP deadlines.

5. Erasure and retention

You must erase personal data when a person withdraws consent, or "as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier". You must also "cause its Data Processor to erase" data you gave it (section 8(7)). The exception is retention that a law requires. The Act's illustration is a bank that must keep identity records for ten years after an account closes. When a person asks for erasure, you must erase "unless retention of the same is necessary for the specified purpose or for compliance with any law" (section 12(3)).

The Rules add a minimum retention period that pulls the other way:

The Rule's own illustration is an e-book platform. It must keep order details, personal data and processing logs for at least a year after a purchase, "even if X deletes her account". Lawyers are still debating how broadly this applies, so get advice on what exactly you must keep.

For engineering, the lesson is that deletion is not a single DELETE statement. Plan it in two stages:

1. Remove the person from operational systems and from your vendors.
2. Move whatever you must keep into a restricted store with an expiry date, and purge it automatically when that date passes.

Very large platforms have one more rule. E-commerce entities with at least two crore (20 million) registered users in India, online gaming intermediaries with at least fifty lakh (5 million), and social media intermediaries with at least two crore must erase data after three years of inactivity. They must also warn the user at least 48 hours before (Rule 8 and the Third Schedule).

Most deletion pipelines fail quietly in warehouses, search indexes, logs and vendor tools. To find out whether yours works, see How to test that deleting a user actually deletes them.

6. Rights requests

People have the right to access, correct, complete, update and erase their data. They can also nominate someone to exercise these rights if they die or become incapacitated (sections 11 to 14). The access right has a clause that is mostly an engineering problem:

Can you list, for one user, every vendor that received their data and what it received? Only if your data map covers SDKs and SaaS tools as well as your own databases.

Rule 14 requires you to publish how people can make a request and which identifier you need from them. It also caps the response time of your grievance system at 90 days, and the government's explainer says access, correction and erasure requests must also be answered within 90 days. People must use your grievance channel before they can go to the Board (section 13(3)), so that channel is your first line of defence.

In practice, you need a request pipeline. It should:

• verify the requester using the identifier you published
• pull the person's data from every store to build the summary
• send corrections and deletions to every system that holds a copy
• record each step and track the due date

7. Children's data

A child is anyone under 18 (section 2(f)). Before processing any child's personal data, you need "verifiable consent of the parent" (section 9(1)). Processing that is "likely to cause any detrimental effect on the well-being of a child" is not allowed (section 9(2)). And you "shall not undertake tracking or behavioural monitoring of children or targeted advertising directed at children" (section 9(3)).

Rule 10 explains how to verify that the person consenting is an identifiable adult. You can use reliable identity and age details you already hold. Or you can use details, or a virtual token, issued by an authorised entity, which includes a Digital Locker provider such as DigiLocker.

The Fourth Schedule lifts the parental-consent and no-tracking rules (sections 9(1) and 9(3)) in some narrow cases. Each exemption is limited to its purpose:

• Healthcare providers, to the extent needed to protect the child's health.
• Educational institutions, for tracking and behavioural monitoring for their educational activities or for children's safety.
• A few listed purposes, such as creating an email-only account, tracking real-time location for safety, and checking that a user is not a child.

The ban on processing that harms a child's well-being (section 9(2)) has no such exemption.

In your systems:

• Know which accounts belong to children. Capture age at sign-up and link child accounts to the parent who consented.
• Gate SDK initialisation. Ad, attribution and behavioural analytics SDKs should not run for child accounts. In mobile apps, many SDKs start when the app launches, before you know who the user is. Check yours.
• Look hard at recommendation and engagement-scoring pipelines. They may count as behavioural monitoring. Whether the education exemption covers you depends on whether you are an "educational institution", defined as "an institution of learning that imparts education, including vocational education". Consumer learning apps should get legal advice on this.

8. Significant Data Fiduciaries

The government can name a company, or a class of companies, as a Significant Data Fiduciary. It decides based on factors such as "the volume and sensitivity of personal data processed" and "risk to the rights of Data Principal" (section 10(1)).

Significant Data Fiduciaries must:

• appoint a Data Protection Officer based in India
• appoint an independent data auditor
• carry out a Data Protection Impact Assessment and an audit every year, and send the Board a report (Rule 13)
• check that their algorithmic software doesn't put users' rights at risk
• keep certain personal data in India if the government specifies it

As of October 2026, no Significant Data Fiduciary has been named. If you process large volumes of health or children's data, plan as if you could be.

9. Data outside India

Transfers outside India are allowed, except to countries the government restricts by notification (section 16(1)). Rule 15 lets the government set requirements for making data available to foreign states. Sector rules can be stricter (section 16(2)), so check your regulator's rules too. For engineering, this means keeping a current list of the regions each data store and vendor uses.

Where to start#

You don't need to fix everything at once, but you need to know what is true about your systems. A practical order:

1. Build the data map from your systems, not from interviews. Scan database schemas, code, storage buckets and mobile app builds. List every third-party SDK and SaaS tool that receives user data. Open-source tools help here. Privado's scanner traces personal data through source code, and Microsoft Presidio can detect Indian identifiers such as Aadhaar and PAN numbers. A schema query is a good first pass:

   -- Illustrative (PostgreSQL): columns whose names suggest personal data.
   SELECT table_schema, table_name, column_name, data_type
   FROM information_schema.columns
   WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
     AND (column_name ~* '(name|phone|mobile|email|birth|address|pincode|aadhaar|device_id|ip_addr|latitude|longitude)'
       OR column_name ~* '(^|_)(dob|pan|lat|lng)(_|$)')
   ORDER BY table_schema, table_name, column_name;

   Column names miss a lot, such as JSON blobs, free-text fields and event properties, so treat this as a starting list.

2. Search logs and error trackers for personal data. Look at what is actually stored, not just what the code intends to log.

3. Test deletion with a test user, across every copy of the data.

4. Check the Rule 6 safeguards against your real configuration. Are the right fields encrypted? Who has production access? Do access logs exist, and are they kept for a year?

5. Run a breach drill. Can the team find out who was affected and draft the reports within 6 and 72 hours?

6. Fix what you find, and keep it fixed. Add retention jobs, log redaction, consent checks in APIs and breach alerts. Add a personal-data check to CI, so new code doesn't bring the problems back.

What engineers shouldn't decide alone#

Some of this is legal work, and it belongs with a lawyer:

• the wording of notices
• whether a data flow relies on consent or a legitimate use
• how long other laws require you to keep records
• contracts with processors

Your part is to give the lawyer accurate facts about what your systems actually do. Most companies don't have those facts yet, and they are hard to fake.

Sources#

• The Digital Personal Data Protection Act, 2023 (MeitY)
• The Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13 November 2025 (MeitY)
• DPDP Rules, 2025 Notified, explainer, 17 November 2025 (PIB)
• CERT-In Directions under section 70B(6) of the IT Act, 28 April 2022 (CERT-In)