DPDP Act Compliance Checklist for Indian SaaS Companies

The Digital Personal Data Protection Act (DPDP) is now in force, and most Indian SaaS teams are scrambling to figure out what they actually need to ship. This is the practical engineering checklist, written for CTOs and tech leads who need to know what to build, not what to read.

Key takeaways

• DPDP applies to any company processing the personal data of people in India, including SaaS companies serving Indian customers.
• The non-negotiables are: explicit consent capture, the ability to honor data subject requests (access, correction, erasure), breach notification within 72 hours, and a Data Protection Officer (DPO) if you're a Significant Data Fiduciary.
• Most of the work is engineering work: consent storage, deletion APIs, audit logs, and documentation that proves controls exist.
• Penalties go up to ₹250 crore per incident, material enough that "we'll deal with it later" is no longer a strategy.

Why this matters now

The DPDP Act passed in 2023 and the rules came into operation through 2025. Enforcement is real. Beyond fines, your enterprise customers are increasingly asking for DPDP compliance certifications in their procurement processes, meaning your sales motion stalls until you can answer the data-protection questionnaire credibly. The fastest-moving SaaS teams are treating DPDP as a sales enabler, not just a legal box-tick.

The engineering checklist

1. Consent capture

Every time you collect personal data, signup, contact form, newsletter, cookies, capture explicit, granular, freely-given consent. Store the consent record itself with timestamp, IP, user agent, and the exact text the user agreed to. Don't reuse blanket terms-of-service consent to cover everything.

Build a consents table. Every consent event is a row. Versioned per consent text.

2. Data Subject Rights APIs

Users can request access, correction, and erasure of their data. You need APIs that:

• Export all data held about a user (machine-readable, ideally JSON)
• Update specific fields on request
• Hard-delete the user and all references, with documented cascade behavior

These can be admin-only endpoints, but they must work end-to-end. Most teams discover at audit time that "delete user" doesn't actually purge analytics, backups, or third-party processors.

3. Purpose limitation and minimization

Document, per data field, why it's collected and what it's used for. Don't collect fields you don't actively use. If your signup form asks for phone number "just in case," remove it.

4. Data Protection Officer (DPO)

Required if you're classified as a Significant Data Fiduciary (volume-based, likely you, if you process data of more than ~50,000 Indian individuals). Designate one. Document their role. Publish contact details on your privacy page.

5. Breach notification

You have 72 hours to report a breach to the Data Protection Board and notify affected users. Build the runbook now, not during the incident. Define detection, classification, escalation, communication templates.

6. Data processor agreements

Every third party that touches your customer data, Stripe, AWS, Sentry, Mixpanel, needs a Data Processing Agreement (DPA) on file. Maintain a register of processors and their DPAs.

7. Cross-border transfers

DPDP allows transfers to countries on the government's allowed list. If you're using US-based services (which is most SaaS), check the current list and document the basis for transfer in your privacy policy.

8. Logging and audit trails

Maintain audit logs of who accessed what personal data, when, and why. Engineering teams hate this until they're asked for it during an audit and discover it doesn't exist.

9. Consent withdrawal

Users can withdraw consent at any time, and your system must honor it within a reasonable window (interpreted as days, not months). Build the UI and the backend job that propagates withdrawal.

10. Privacy policy + DPDP-compliant notices

Your privacy policy needs to spell out: what data, why, how long, who else gets it, user rights, contact for grievances, DPO contact. Translate into the languages your users actually use.

Common pitfalls

The most common failure mode is "we have a privacy policy, so we're compliant." DPDP is operational, not documentary. You need the actual deletion API working, the consent records actually stored, the breach runbook actually rehearsed. The second most common failure is forgetting that backups count, when you delete a user, you need a plan for what happens to records in your 30-day Postgres backups.

What we'd recommend

Treat DPDP as a 6-8 week engineering project. Week 1: audit what you collect, where it lives, who it goes to. Weeks 2-4: build consent, audit log, and data subject request APIs. Weeks 5-6: rewrite privacy policy, draft breach runbook, register DPAs. Weeks 7-8: external pentest of the controls. By the end, you're DPDP-aligned and can credibly answer customer compliance questionnaires.

FAQs

Does DPDP apply to a B2B SaaS that only stores employee data of corporate customers? Yes. Employee personal data is still personal data.

Do we need a DPO if we're a 10-person startup? Only if you cross the Significant Data Fiduciary threshold. Designate someone anyway, it's good hygiene.

How does DPDP interact with GDPR? They overlap heavily. If you're already GDPR-compliant, the marginal lift to DPDP is small, mostly notification timing and cross-border specifics.

What's the penalty? Up to ₹250 crore per violation, depending on severity and category.

If DPDP readiness is on your roadmap, Techpuvi's Cybersecurity & Compliance practice delivers the engineering controls and documentation auditors actually want. Smaller engagements welcome.