SaaS Security & Compliance: India's DPDP Act + GDPR, What You Must Build In

Two reasons, and neither is "because a lawyer said so." The first is risk. The second — the one that actually moves revenue — is trust. They compound.

On risk: the numbers are now large enough that a single mistake can end a company. GDPR's top tier is up to €20 million or 4% of global annual turnover, whichever is higher; European regulators issued roughly €1.2 billion in fines in 2025 and added over €600 million in just the first half of 2026. India's DPDP Act sets a maximum penalty of ₹250 crore (about $30M) for failing to implement reasonable security safeguards, and up to ₹200 crore for failing to report a breach. Crucially, under DPDP that breach-reporting penalty bites even if your security was fine — silence is its own offence.

On trust: every serious B2B buyer now sends a security questionnaire before signing. "Do you encrypt data at rest? Can you delete a user's data on request? Where is it hosted? Show me your access logs." If the honest answer is "we'd have to build that," you don't lose the deal politely — you lose it after weeks of back-and-forth, and you rebuild your data layer under deadline pressure. Founders who treated these as day-one architecture pass the questionnaire in an afternoon. That speed is a sales advantage, not a cost centre.

The trap is timing. Encryption strategy, audit logging, consent capture, and your hosting region are all foundational schema-and-infrastructure decisions. Retrofitting them after you have real customer data means migrations, re-encryption, downtime, and gaps in your audit trail you can never backfill. Pre-launch is the cheapest this work will ever be.

Strip away the legal language and both laws ask for the same handful of capabilities. The vocabulary differs (GDPR says "controller/processor/data subject"; DPDP says "Data Fiduciary/Data Processor/Data Principal") but the engineering obligations rhyme almost exactly.

Think of it as a contract between you and the people whose data you hold. You must collect data only with a lawful basis (usually consent), tell them clearly why, keep it secure, let them see/correct/delete it, not keep it forever, and own up quickly if it leaks. Everything below is the technical expression of that contract.

This is the core checklist. Each maps directly to a clause in DPDP, GDPR, or both — but more importantly, each is a concrete engineering decision you make in the first weeks, not the last.

This is where founders get caught out, because India effectively has two clocks running at once, and one of them is the tightest in the world.

Under GDPR, you notify the relevant supervisory authority within 72 hours of becoming aware of a breach that risks people's rights, and notify affected individuals "without undue delay" if the risk is high. One regulator, one clock, well-understood.

India is stricter and more fragmented. Under the DPDP framework, you must notify the Data Protection Board "without delay" and affected Data Principals, with detail expected promptly. Separately — and this is the trap — CERT-In's 2022 directions require reporting a wide range of cyber incidents (not just personal-data breaches: ransomware, DDoS, unauthorised access, and more) within 6 hours of noticing them. A single ransomware event in India can therefore trigger a 6-hour CERT-In filing AND a DPDP Board notification. Many teams know the 72-hour number and miss the 6-hour one entirely.

The engineering takeaway is the same regardless of jurisdiction: detection speed is everything. A clock you can't start (because you didn't notice the breach) is a clock you've already lost. Invest in monitoring, alerting, and a pre-written incident runbook with named owners and templated notifications. The difference between a contained incident and a reportable catastrophe is usually how fast you saw it.

"Where is your data hosted?" is now a standard procurement question, and the two regimes answer it very differently — which directly shapes your cloud architecture.

GDPR uses a positive-list (whitelist) model: you may transfer personal data out of the EU/EEA only to countries deemed "adequate," or with safeguards in place such as Standard Contractual Clauses (SCCs). The burden is on you to justify every export.

India's DPDP Act inverts this with a negative-list (blacklist) model under Section 16: transfers are permitted to all countries except any the government specifically restricts — and as of mid-2026, no restricted-country list has been published. So DPDP is, by default, more permissive on general cross-border transfer than GDPR. Note one important consequence: legacy GDPR-style SCC clauses are not the mechanism DPDP cares about, so a DPA written purely for the EU does not automatically satisfy India.

Two caveats that override the defaults. First, sectoral localisation can be far stricter than the privacy law itself — most notably RBI's rule that payment data be stored in India. If you touch Indian payments, you may need in-country storage regardless of DPDP. Second, enterprise buyers increasingly demand regional hosting (EU data in the EU, India data in India) contractually, even when the law doesn't strictly require it. The practical design answer is to architect for region-pinned hosting early — choosing a cloud and data model that lets you place data in a specific region per tenant — so you can satisfy whichever residency demand lands on you without re-platforming.

None of this requires exotic technology. A modern, well-chosen stack gives you most of it nearly for free — the value is in the design discipline, not the tooling budget. Here is the pattern we build for SaaS clients, framed by capability so it's portable to any stack.

The point is that each of these is a decision made once, early, at the schema and infrastructure layer — and then it's just there. Bolting any of them on after launch costs an order of magnitude more and leaves gaps (especially in audit history) you can never fully close.

The framing that wins is this: every one of these controls is also a feature your enterprise buyers are willing to pay for. "We encrypt at rest, isolate every tenant with Row-Level Security, log every access immutably, and can delete or export your data on demand" is a sentence that closes deals. The same architecture that keeps a regulator satisfied is the architecture that survives a security questionnaire and an enterprise legal review.

Done right, the marginal cost of building this in on day one is small — it's mostly disciplined decisions about your schema, your hosting region, and your access model, made before you have data to migrate. Done late, it's a multi-week re-platforming project with irrecoverable gaps in your audit history and a deal stalled while you scramble. The merit case is unambiguous: build it in now.

This is exactly the kind of foundation we architect into the SaaS products we build — senior engineers, AI-accelerated delivery, a fixed written quote after a free scoping call, and you own 100% of the code. If you're scoping a new SaaS and want the data layer, tenancy model, and compliance posture designed correctly from the first migration, a short scoping call is the cheapest way to get it right the first time.

A final, honest caveat: this guide is accurate engineering and risk guidance, not legal advice, and privacy law is moving fast (India's DPDP Rules 2025 phase in substantive obligations through May 2027). Treat your lawyer and your architect as a pair — the lawyer tells you what the law requires for your specific business; the architect makes sure the software can actually prove it.