DPDP Act for engineers: what you actually have to change in your code

The DPDP Act's enforcement machinery has been running since 2025. CERT-In has issued guidance. The Data Protection Board is operational. If your team has been waiting for 'the rules to finalise' before doing anything, that window closed months ago.

This is an engineering guide, not a legal one. What the Act requires you to build, what it doesn't, and which exemptions to check before writing compliance code.

What the Act covers — and what it doesn't

The Digital Personal Data Protection Act governs the processing of digital personal data: any data about an identifiable natural person, either collected in digital form or digitised after collection. Anonymised aggregate data with no re-identification risk sits outside scope.

Data Principal: the person the data is about. Data Fiduciary: any entity that determines the purpose and means of processing (you, for data you collect directly). Data Processor: any entity processing personal data on behalf of a Fiduciary (also you, for your customers' data on your platform).

Most B2B SaaS companies are both. Fiduciary for your own customers' billing and contact data. Processor for whatever personal data your customers' users generate inside your product. The obligations differ by role. Conflating the two leads to building the wrong thing.

The consent requirement

Valid consent under the Act must be free, specific, informed, unconditional, and unambiguous. Pre-ticked checkboxes fail. Blanket 'by using this service you consent to all processing' T&C clauses fail. Implied consent from continued use fails.

What you need is a consent record store, not a consent banner.

Each record should capture: data principal identifier, the specific purpose consented to, the exact version of the consent text shown, timestamp, session or IP identifier, and whether consent was later withdrawn. The withdrawal flow is the part most teams build last. Build it first. Withdrawal must be as easy as giving consent: self-serve, visible, and immediate.

Data deletion under Section 12

Data principals have the right to erasure. The engineering challenge: deletion isn't a single database operation. Data propagates.

A deletion request touches the primary application database, read replicas, downstream analytics pipelines, email marketing and CRM integrations, event streams with unconsumed events, and backups.

For backups: the Act doesn't require you to restore-and-delete from every tape. It requires that you don't restore deleted data. Document your backup rotation schedule and the deletion request date. A record that reappears from a backup restoration is a violation; a record sitting on a tape you'll overwrite in 30 days is not.

One step most teams miss: write a tombstone record before deleting. Hash the user identifier and store the hash alongside the deletion timestamp and request ID. You need to be able to prove the deletion happened. You cannot prove a deletion if you've erased all evidence that the person existed.

Breach notification

A personal data breach — any unauthorised processing, disclosure, access, alteration, or destruction of personal data — requires notifying both the Data Protection Board and the affected data principals. Unlike GDPR, the DPDP Act has no risk-based exception that allows skipping individual notification for low-risk incidents.

A notification must contain: description of what happened, categories and approximate number of affected data principals, categories of data involved, likely consequences, steps taken to address the breach, and contact details for your DPO or designated contact.

Build three things now, not during an incident: an alerting pipeline for unusual data access, a triage playbook that defines who decides within six hours whether personal data was actually accessed, and a pre-drafted notification template reviewed by legal. All three take a day to build. None of them can be assembled inside a 72-hour breach window.

The exemptions worth checking first

Schedule II and Section 17 carry the exemptions. Before building anything, check whether your processing qualifies.

• Contractual necessity (Section 7(b)): Processing necessary to perform a contract with the data principal doesn't require consent. If a user gave you their email address to receive account notifications, processing that email for those notifications doesn't need a separate consent flow.
• Employment data (Section 7(e)): HR, payroll, and employment management processing doesn't need consent.
• Pure B2B data: The Act governs data about natural persons. If your product processes data only at the company level with no individual-level identifiers, that data is outside scope. Know where the line sits in your schema.
• Small Data Fiduciary threshold: The government will notify thresholds. Companies below the threshold carry lighter obligations. Watch for the notification.
• Processor role: As a Data Processor, your direct obligations under the Act are limited. Your customer (the Fiduciary) bears the primary compliance burden for their end-users' data. You need a Data Processing Agreement with each customer; you don't independently owe their users a deletion endpoint.

The common mistake: building a full consent and deletion flow for data you hold as a Processor, when your obligation is to support your customer's compliance program through your DPA obligations. The Fiduciary cannot contractually transfer their obligations to you. They stay with them. You can't be blamed for non-compliance if you've fulfilled your DPA terms.

Build order

Given the role distinctions and exemptions above, a practical sequence:

1. Data map first. Before writing any code: list every category of personal data you hold, where it lives, and which role you're in for each. Fiduciary or Processor. This takes one day and changes the scope of everything that follows.
2. DPA template. Draft a Data Processing Agreement and send it to all customers who process personal data on your platform. This is a contract operation, not a technical one, but it locks in the Processor/Fiduciary boundary before you build to it.
3. Consent store. Build the database table, not the banner. Withdrawal flow before collection UI.
4. Deletion pipeline. Customer-facing API first. Downstream propagation second. Tombstone records before hard-deletion.
5. Incident response playbook. One page. Test it once. Know the Board's reporting URL before you need it.
6. DPO appointment. Once the Significant Data Fiduciary threshold is notified, assess whether it applies to you. If it does, the appointment has a statutory deadline.

What you're probably overthinking

Application logs containing PII: a defined retention policy — 30-day rolling window for detailed logs, 12 months for access logs — with no manual review without justification is generally sufficient. Hashing user IDs in structured logs at ingestion is cleaner, and worth doing for new services, but retrofitting existing log infrastructure ranks below building the consent store.

Analytics pipelines: aggregate metrics without user-level identifiers are outside the Act's scope. If your pipeline uses raw user IDs, hash them at ingestion with a one-way function. That removes the analytics data from DPDP scope entirely.

Backups: document the rotation schedule, add a deletion log that the DBA checks before any restore, done. You don't need to rebuild backup infrastructure.

Re-consenting existing users: the Act's transitional provisions allow for a grace period on existing processing bases. Fix forward. Build the consent store for new sign-ups before back-filling existing accounts.

The Act is specific enough to build against now. The teams that will struggle with enforcement are the ones that kept waiting for 'full clarity' before starting, not the ones that mapped their data and built incrementally.