DPDPA × GDPR for the Indian SaaS exporting to Europe: the synthesis that actually worksPremium

Practitioner reference for Indian SaaS founders, heads of compliance, privacy counsel, DPOs, and CISOs whose customer list crossed the EU border · 2026-05-25 · Written from twelve years of advising privacy programmes across India, the EU, and the US, and from sitting in too many board rooms where somebody confidently said "we're GDPR compliant so DPDPA is easy" and was wrong

Why this guide exists

The single most common privacy conversation I have had in the last eighteen months is some version of the following. An Indian SaaS company, mid-stage, fifty to three hundred people, started winning EU customers. Somebody in legal got worried about GDPR. They went to a Bangalore consultant who said GDPR compliance was “essentially the same” as DPDPA preparation. Six months later the company has a privacy notice that satisfies neither regime, a consent flow built for the wrong audience, and a Data Processing Addendum template their EU customers keep redlining.

Or the inverse. A European SaaS started selling into India because the buyer was big and the deal was real. Somebody in privacy assumed DPDPA would be a thin overlay on GDPR. The DPDPA Rules 2025 came out and they discovered the Indian framework is structurally different in ways their EU-trained DPO had not anticipated.

The two regimes look similar enough that the assumption is forgivable. They are also different enough that the assumption is expensive. This guide is the synthesis I would have wanted in 2023 — what is actually the same, what is actually different, what you can build once for both, and what you have to build twice.

The two regimes in one paragraph each

GDPR (Regulation (EU) 2016/679) is the European general data protection regulation, in force since 25 May 2018. It applies to processing of personal data of individuals in the EU by anyone established in the EU, and extraterritorially to processing by entities outside the EU where the processing relates to offering goods or services to EU data subjects or monitoring their behaviour. It uses a controller/processor architecture, allows six lawful bases for processing, mandates a Data Protection Officer in specified circumstances, has tiered fines up to €20 million or 4% of global turnover (whichever is higher), and creates broad data subject rights including portability and objection. The enforcement community is mature: the European Data Protection Board, twenty-seven national supervisory authorities, a substantial body of court decisions, and the one-stop-shop mechanism for cross-border cases.

DPDPA (the Digital Personal Data Protection Act, 2023, with the DPDP Rules 2025 notified 13 November 2025) is the Indian general privacy law, in three-phase commencement. Rules 1, 2, and 17–21 are in force since 13 November 2025, with the Data Protection Board of India operational. Consent Manager registration activates 13 November 2026. Full enforcement of Rules 3 and 5–16 and Sections 3–17 begins 13 May 2027, alongside penalties up to ₹250 crore. It applies to processing of digital personal data within India and extraterritorially to processing outside India “in connection with any activity related to offering of goods or services” to Data Principals in India. It uses a Data Fiduciary / Data Processor / Data Principal architecture, but Data Processors have no direct statutory obligations under DPDPA. The enforcement community is brand new.

The first regime is mature, twenty-seven-jurisdictional, and structured around legitimate-interest balancing. The second is fresh, single-jurisdictional, and structured around consent. That is the wedge.

Why this matters now

Three things are happening at the same time, and they affect every Indian SaaS company with EU customers and every EU company with India operations.

One. DPDPA’s full enforcement clock runs out on 13 May 2027. That is now twelve months away. The penalties under the DPDPA Schedule are real — ₹250 crore for failure to safeguard personal data, ₹200 crore for failure to notify breach, ₹150 crore for SDF obligation failures. The Data Protection Board of India has been operational since November 2025 and the early complaint pattern is consistent with what India’s other regulators do: a quiet first year, then visible enforcement in the second.

Two. GDPR enforcement has shifted to a steady-state rhythm with material fines on Indian-origin processors who treated GDPR as an EU problem rather than a global one. Several Indian SaaS companies I know have received warning letters from EU supervisory authorities in the last eighteen months. The “we’re not really in scope” defence does not survive contact with the EDPB’s extraterritoriality guidance.

Three. Customer-side procurement has converged. EU enterprise buyers now ask Indian SaaS vendors for both GDPR and DPDPA posture in the same security questionnaire, and Indian enterprise buyers ask their EU SaaS vendors the inverse. Treating them as separate compliance programmes is operationally expensive and increasingly impossible to sustain in a sales conversation.

The four-actor model: where the regimes do and don’t line up

Both regimes use a similar architecture but the names and obligations differ in ways that matter.

The structural difference that matters most: GDPR puts direct statutory obligations on Processors (Articles 28, 32, etc.). DPDPA does not. Under DPDPA, Data Processor obligations flow through the contract with the Data Fiduciary (Section 8(5) and Rule 6(f)). If you are an Indian SaaS company acting as a processor for an EU customer, you carry direct GDPR obligations and contractual DPDPA ones simultaneously. If you are a Data Fiduciary using Indian processors, your contracts are the only thing protecting you under DPDPA, so they need to be written like load-bearing walls.

The other structural difference: GDPR is consent-optional; DPDPA is consent-anchored. GDPR offers six lawful bases (Article 6) — consent, contract necessity, legal obligation, vital interests, public task, legitimate interests. Legitimate interest is the workhorse for B2B SaaS, marketing analytics, fraud prevention, and most operational processing. DPDPA offers consent (Section 6) plus a narrower list of “legitimate uses” (Section 7) — voluntarily provided data for the purpose for which provided, employment, medical emergency, public-interest situations, certain mergers and credit-information cases. There is no legitimate-interest catch-all. The processing you justify under GDPR Article 6(1)(f) (legitimate interest) often requires explicit consent under DPDPA. This is the single biggest operational difference, and it surprises people.

Where the two converge: build once, satisfy both

Eight areas where the operational requirements are close enough that a single well-designed mechanism satisfies both regimes. In each case the move is to design to the stricter of the two and use the same evidence for both.

Notice / fair information practices

GDPR Articles 13 and 14 specify what a privacy notice must contain — identity of the controller, purposes, lawful basis, recipients, retention period, data subject rights, complaint mechanism, automated decision-making logic, transfer mechanism, source of data (for indirect collection). DPDPA Section 5 plus Rule 3 specify four elements: data and purpose, manner to exercise rights, manner to complain to the DPBI, and language preference from the constitutional schedule.

The strictest synthesis: write to GDPR Articles 13/14 content depth, in the data principal’s preferred constitutional-schedule language where the data principal is in India, with the DPBI complaint mechanism included alongside the EU supervisory authority complaint pathway. One notice template, one structure, two complaint pathways listed. Auditors on either side accept it.

Consent capture and withdrawal

GDPR Article 7 defines consent: freely given, specific, informed, unambiguous, demonstrable, withdrawable as easily as given. DPDPA Section 6 plus Rule 5 define consent in similar terms — free, specific, informed, unconditional, unambiguous, with affirmative action and withdrawal-as-simple-as-providing.

Build one consent UX. Granular per purpose. Affirmative action (no pre-ticked boxes). Withdrawal reachable from a single click without authentication friction. Consent records timestamped with the version of the notice the data principal saw. The DPDPA Rule 5 “as simple as providing the consent originally” test is operationally identical to the GDPR Article 7(3) test; if you pass one you pass the other.

Data subject / Data Principal rights mechanisms

GDPR rights (Articles 15–22): access, rectification, erasure, restriction of processing, portability, objection, automated decision-making opt-out. DPDPA rights (Sections 11–14): information about processing, correction, erasure, grievance redressal, nomination on death/incapacity.

Three rights overlap squarely: access, correction, erasure. Build one rights-request portal handling all three, with identity verification proportionate to risk, response SLAs (the GDPR baseline of one month is the operational target), and propagation to processors and backups. The DPDPA-unique rights (nomination) and the GDPR-unique rights (portability, objection, automated decision-making) are bolt-ons to the same portal. Grievance redressal under DPDPA Section 13 — the requirement to exhaust the Data Fiduciary’s internal mechanism before escalating to DPBI — is operationally just a documented support workflow.

Breach notification

GDPR Article 33: notify the supervisory authority of a personal data breach within 72 hours of becoming aware, except where unlikely to result in risk to rights and freedoms. Article 34: notify affected data subjects without undue delay if high risk.

DPDPA Section 8(6) plus Rule 7: notify the DPBI without undue delay on becoming aware, with a detailed notification within 72 hours (extendable on written request). Notify affected Data Principals.

The 72-hour clock from “awareness” is the same in both regimes. Build one breach-response procedure, one timestamp-of-awareness mechanism, parallel notification templates for the EU supervisory authority and the DPBI. If you operate cross-border you may end up filing four notifications in parallel — EU supervisory authority, affected data subjects, DPBI, affected Data Principals — plus CERT-In (six-hour clock, parallel) and any sectoral regulator (RBI six-hour, SEBI, IRDAI). Pre-stage the notification grid before you need it.

Processor / Data Processor contracts

GDPR Article 28 specifies what a controller–processor contract must contain — eight or so mandatory elements. DPDPA Section 8(5) and Rule 6(f) require a written contract with security safeguards.

The Data Processing Addendum template that satisfies GDPR Article 28 is the same artefact that satisfies DPDPA Section 8(5). Add a clause noting DPDPA-specific security safeguards under Rule 6(f) and the cross-border notification obligation in case of breach. The European Commission’s Standard Contractual Clauses (the 2021 SCCs) can sit inside the same DPA where the processor is outside the EEA.

DPIA / impact assessment

GDPR Article 35: DPIA required for high-risk processing. The Article 29 Working Party guidance lists nine criteria; two or more typically triggers DPIA. DPDPA Section 10 plus Rule 12: periodic DPIA for Significant Data Fiduciaries.

Build one DPIA template. The GDPR-specific elements (necessity and proportionality assessment, consultation requirement where residual risk is high) and the DPDPA-specific elements (the Rule 12 contents when those are finalised) are structured fields in the same template. The trigger logic differs — GDPR is risk-based across all controllers, DPDPA is currently SDF-only — but if you do DPIAs voluntarily on high-risk processing as a Data Fiduciary before designation, you get both readiness and operational hygiene.

Records of processing

GDPR Article 30 requires a Record of Processing Activities — controller-side and processor-side variants. DPDPA does not explicitly mandate a ROPA, but every other obligation depends on knowing what personal data you process, why, where, for how long, and with whom.

Build the GDPR ROPA. Use it as your DPDPA processing-activity inventory. Mark each entry with the legal basis under GDPR (consent, contract, legitimate interest, etc.) and the legal basis under DPDPA (consent, Section 7 specific clause, sectoral exemption). The same artefact powers both regimes’ compliance evidence and your breach-impact analysis when you need it.

Children’s data

GDPR Article 8 sets digital service consent age at sixteen, with Member State derogation down to thirteen. Parental consent verifiable below the age. DPDPA Section 9 plus Rule 10 set the age at eighteen, require verifiable parental consent, and prohibit tracking, behavioural monitoring, and targeted advertising to children except in narrow exemptions.

The DPDPA child standard is stricter both on age and on advertising suppression. Build to DPDPA Section 9 globally — age-gate at eighteen, verifiable parental consent, behavioural-tracking and targeted-advertising disabled for users self-identifying as under eighteen. The GDPR side becomes a downward-tightening exercise rather than two separate workstreams.

Where they substantively differ — what you can’t synthesise away

Six areas where the regimes diverge in ways that you cannot solve with a single mechanism. Each requires a separate workstream or a deliberate design choice that picks a side.

Lawful basis

GDPR Article 6 offers six bases. Most B2B SaaS processing leans on legitimate interest (Article 6(1)(f)) — analytics, fraud prevention, account management, internal reporting, security monitoring, lead enrichment, intra-group transfers for HR. The Article 29 / EDPB balancing test is well understood and litigated; the operational pattern is documented.

DPDPA does not have a legitimate-interest basis. Section 7 lists specific “legitimate uses” — voluntarily provided data, employment-related processing (subject to specific conditions), medical emergencies, public-health emergencies, breakdown of public order, mergers/amalgamations under court orders, ascertaining creditworthiness through specified channels. The list is exhaustive. Everything else requires consent.

This means: every processing activity that you justify under GDPR legitimate interest needs a separate Indian-Data-Principal pathway. Either obtain consent, fit the activity into a Section 7 ground, or stop the activity for Indian Data Principals. For most Indian SaaS exporting to the EU and using EU SaaS analytics platforms, this surfaces as: do you have consent from your Indian users for marketing analytics that you justify under GDPR legitimate interest for your EU users? Usually the answer is no, and the consent flow needs to be added.

This is the single hardest synthesis problem. There is no design pattern that makes it go away.

Sensitive / special category data

GDPR Article 9 prohibits processing of special category data (race, ethnicity, political opinions, religious beliefs, trade union membership, genetic, biometric, health, sex life, sexual orientation) except under ten specific conditions. The “explicit consent” condition is the most commonly used.

DPDPA has no statutory category of sensitive personal data. The 2011 IT Rules under Section 43A of the IT Act, 2000 do define “sensitive personal data or information” — passwords, financial information, health information, sexual orientation, medical records, biometric information — and these rules remain in force until 13 May 2027 (when Section 43A is repealed by DPDPA). After that date, DPDPA treats all personal data uniformly except for children’s data.

This creates a transition trap. Between now and May 2027, sensitive personal data in India is governed by the older 2011 rules’ “explicit consent” and “reasonable security practices” requirements. After May 2027, the same data is governed by general DPDPA consent and security obligations. EU sensitive personal data continues to be governed by GDPR Article 9. The synthesis: treat GDPR’s Article 9 categories as a globally elevated handling regime for the foreseeable future, regardless of DPDPA’s eventual silence. Lower handling discipline for sensitive data than your EU baseline is operationally unsafe even where DPDPA doesn’t require it.

Cross-border data transfer

GDPR Articles 44–50 use a positive-list model: transfers outside the EEA permitted only where an adequacy decision exists, or appropriate safeguards (SCCs, BCRs, codes of conduct, certification schemes) are in place, or specific derogations apply. The Schrems II decision and the EU–US Data Privacy Framework (in force since July 2023, subject to ongoing litigation) shape the EU–US pathway.

DPDPA Section 16 plus Rule 14 use a negative-list model: transfers outside India are permitted unless the Central Government notifies restrictions on specific countries or territories. No notifications have been issued as of May 2026. The model is the inverse of GDPR’s.

Sectoral overlays complicate the DPDPA picture. RBI requires payment-system data to be stored only in India (the April 2018 Storage of Payment System Data circular, still in force). SEBI has data localisation requirements for capital-markets data. IRDAI has insurance-data localisation rules. These sectoral rules are stricter than DPDPA and override it under the Section 38 conflict-of-laws rule.

Operational synthesis: maintain a cross-border flow register by destination country, data category, volume, purpose. For EU-origin data, document the GDPR Chapter V transfer mechanism (adequacy, SCCs, derogation). For India-origin data, document the DPDPA Section 16 default permissibility, the sectoral overlays applicable, and a monitoring procedure for future Central Government notifications. The register is one artefact serving both regimes; the legal-basis annotation is doubled.

Significant Data Fiduciary designation

DPDPA Section 10 plus Rules 11, 12, 13 create a designation regime — the Central Government identifies entities as Significant Data Fiduciaries based on volume and sensitivity of personal data processed, risk to Data Principals, risk to sovereignty and integrity of India, risk to electoral democracy, security of state, public order. SDFs carry additional obligations: an India-resident DPO reporting directly to the Board, an independent Data Auditor, periodic DPIAs and data audits.

GDPR has no equivalent designation. Article 37 triggers DPO appointment based on activity criteria (public authority, large-scale regular and systematic monitoring, or large-scale processing of special category or criminal data). The DPO independence and reporting-line requirements (Articles 38–39) are functional rather than structural.

If you are likely to be designated an SDF, the DPO appointment cannot wait for designation. The India-resident requirement, the Board reporting line, and the independence test all take six to twelve months to set up properly. Companies I have advised who treated SDF readiness as a post-designation problem ended up either appointing the wrong person or operating below the standard for the first year after designation. Build SDF readiness pre-designation as a hedge.

Sectoral and constitutional overlays

GDPR sits alongside the ePrivacy Directive (cookies, electronic marketing), national workplace privacy laws, sectoral laws (PSD2, MiFID, etc.), and emerging EU regulations (DSA, DMA, Data Act, AI Act). The overlay structure is well-mapped.

DPDPA sits alongside the IT Act and IT Rules (intermediary obligations under Section 79 and the 2021 IT Rules with 2023 amendments), CERT-In Direction 70B (six-hour incident reporting, KYC, log retention), sectoral regulators (RBI for banks and NBFCs, SEBI for capital markets, IRDAI for insurance, TRAI for telecom), the future Digital India Act, and the Bharatiya Nyaya Sanhita 2023 provisions on offences involving personal data. The overlay structure is still settling.

You cannot synthesise away the sectoral overlays. They require separate compliance work tracks. A bank’s privacy programme has to satisfy DPDPA and RBI ITGRCA 2024 and RBI Cyber Resilience and the IT Outsourcing Directions, all in addition to GDPR if it has EU exposure. The synthesis applies at the personal-data-protection layer; the sectoral overlays are layered on top.

Penalties and enforcement maturity

GDPR fines are tiered: up to €20 million or 4% of global annual turnover for the most serious infringements (Article 83(5)); up to €10 million or 2% for lesser (Article 83(4)). Aggregate fines across the EU since 2018 are now in the multi-billion-euro range. The enforcement community is mature.

DPDPA penalties are absolute amounts in the Schedule: up to ₹250 crore for failure to safeguard, ₹200 crore for failure to notify breach, ₹150 crore for SDF obligation failure, ₹200 crore for children’s data failure, ₹50 crore for other breaches. No turnover-based scaling. The Data Protection Board of India is operational but its inquiry-and-determination procedures are still being tested.

Practical effect: large global companies face larger absolute exposure under GDPR for the same breach if they have high EU revenue. Mid-market Indian SaaS companies face larger absolute exposure under DPDPA than under GDPR for the same breach because the Indian penalty is amount-based, not turnover-based. This changes which regime to over-engineer for, and it is not always GDPR.

The synthesis playbook: one privacy programme, two regimes

Build the following stack. Each item is one operational artefact that serves both DPDPA and GDPR with clear bolt-ons where required.

One privacy policy. Public-facing. Covers both regimes. Written in plain English plus the relevant constitutional-schedule language where you have Indian Data Principals. Articles 13/14 content depth with the DPDPA Rule 3 fields included. Updated on material change with version history.

One ROPA / processing-activity inventory. GDPR Article 30 structure. Each entry tagged with the GDPR lawful basis and the DPDPA lawful basis (consent or Section 7 ground or sectoral exemption). Updated on material change, not just annually.

One consent UX. Granular per purpose. Withdrawal as simple as capture. Consent records timestamped with notice version. Affirmative action only. Designed to the strictest of the two regimes (which is usually DPDPA Rule 5 on withdrawal accessibility).

One Data Processing Addendum template. Article 28 + 32 plus DPDPA Section 8(5) plus Rule 6(f) plus 2021 SCCs as an annex for cross-border processor relationships. Reviewed annually.

One DPIA template. GDPR Article 35 structure with DPDPA Rule 12 structured fields surfaced when the processing is SDF-relevant. Triggered by either regime’s high-risk indicators.

One rights-request portal. Handles GDPR Articles 15/16/17/18/20/21 and DPDPA Sections 11/12/13/14. Identity verification proportionate to request type. SLA dashboard. Propagation logging to backups and processors.

One breach response procedure. Awareness-timestamp mechanism. Notification grid covering: EU supervisory authority (one-stop-shop logic where applicable), affected EU data subjects, DPBI, affected Indian Data Principals, CERT-In, sectoral regulators. Pre-staged templates and contact lists.

One DPO appointment. India-resident (DPDPA requirement if SDF designated). Reports to the Board (DPDPA requirement) and operates independently (GDPR Article 38). One person can wear both hats if their seniority and access are at the level the role requires. Below SDF designation you don’t strictly need an India-resident DPO under DPDPA, but appointing one early lets you build the structural independence before it becomes a designation problem.

One cross-border flow register. Destination country, data category, volume, purpose, GDPR transfer mechanism, DPDPA Section 16 status, sectoral overlays. Monitored for Central Government notifications restricting transfer.

One training programme. Annual mandatory privacy training covering both regimes for all staff handling personal data. Role-specific training for engineering, customer success, sales, HR. Refresher on any material regime change (e.g., the DPDP Rules 2025 notification, the GDPR Schrems II ruling).

One vendor / processor inventory. Classified by criticality. Pre-engagement due diligence for critical processors. Annual reviews. Contract conformity check (the DPA template, refreshed).

That’s the entire programme. Eleven artefacts plus the role assignments. Built once, evidences twice.

What it costs

A first-time Indian SaaS company building this stack from scratch should budget twelve to eighteen months of elapsed time and somewhere between ₹40 lakh and ₹2 crore depending on size. The big-firm-consulting version is at the high end and is usually not worth it; the practitioner-led version with one external advisor for sixty to ninety days at the start is usually the right shape. Year-two run-rate (a DPO half-time, a privacy ops analyst, annual DPIA refreshes, training programme, vendor reviews) lands at ₹35-80 lakh annually for a hundred-to-five-hundred-person company.

EU companies expanding into India typically have lower marginal cost because the GDPR programme provides eighty percent of the artefacts. The marginal lift is the lawful-basis re-mapping, the constitutional-schedule language for notice, and the SDF-readiness work if they cross designation thresholds.

The companies that spend the most are the ones that built both regimes in parallel rather than as a synthesis. Two privacy notices, two DPAs, two ROPAs, two rights portals — twice the maintenance, twice the drift, twice the audit findings. I have seen mid-sized companies operate this way for three years before consolidating, and the consolidation is itself a six-month project. Build the synthesis early.

Common failure patterns

Five things I see go wrong, in rough order of frequency.

One. Treating legitimate interest as the same thing as Section 7 “legitimate uses.” They are not the same. GDPR legitimate interest is open-ended subject to a balancing test; DPDPA Section 7 is exhaustive. Marketing analytics is a Section 7 problem the day DPDPA takes full effect.

Two. Notice and processing inventory decoupled. The privacy notice promises one set of purposes; the ROPA documents another. The fix is mechanical — both come from the same source — but the discipline to enforce it requires somebody specifically owning the cross-check.

Three. Consent withdrawal works in the primary UX but doesn’t propagate. The user clicks “withdraw consent” in the app; the marketing platform, the analytics platform, the ad-network sync, the data-warehouse-driven downstream all keep processing. GDPR Article 17 and DPDPA Section 12 both bite this; the engineering work to propagate withdrawal across downstream systems is non-trivial and usually under-scoped.

Four. Breach awareness is mis-defined. Companies set the 72-hour clock from “incident confirmed” or “public disclosure” rather than from “any responsible person became aware that personal data may have been compromised.” The EDPB guidance and the DPBI’s emerging practice both interpret awareness early. Build the awareness timestamp into the IR runbook explicitly.

Five. SDF readiness is deferred until designation is imminent. Then it’s too late. The India-resident DPO, the Board reporting line, the independent Data Auditor, the DPIA programme — all of these take six to twelve months to set up properly. The companies that get SDF designation right are the ones that built the structure pre-designation.

Migration playbooks

Indian SaaS expanding into EU

Sequence that works:

Quarter one. GDPR scope determination. Where exactly are your EU data subjects? Are you a controller, a processor, or both for which processing? Establish the legal entity question — most Indian SaaS companies start with the parent entity as the controller and an Article 27 EU representative for the representative-on-the-ground requirement. The EU representative is a real person at a real address; nominate-and-forget services exist but the regulator scrutiny on them is increasing.

Quarter two. ROPA extension and notice update. Add the GDPR-specific fields (lawful basis, transfer mechanism, EU representative contact) to your existing DPDPA-aligned ROPA and notice. Map every Indian processing activity to a GDPR Article 6 lawful basis. The activities that were running on DPDPA consent largely stay on GDPR consent; the operational and B2B activities can usually move to GDPR legitimate interest with documented balancing tests.

Quarter three. DPA template refresh and SCCs roll-out. Re-paper customer contracts where you are the processor; re-paper sub-processor contracts where you engage EU-resident sub-processors. Issue 2021 SCCs for all cross-border processor relationships involving EU data.

Quarter four. Breach response procedure dual-pathway test. EU representative contactability tested. EU supervisory authority pathway identified per Member State for your customer footprint (or one-stop-shop lead authority identified). DPO appointment if Article 37 triggers apply.

EU SaaS expanding into India

Sequence that works:

Quarter one. DPDPA scope determination. Your EU GDPR programme already gives you most of the artefacts. The gap analysis is on lawful basis re-mapping, constitutional-schedule language for notice, and sectoral overlays (does the customer industry trigger RBI / SEBI / IRDAI rules?).

Quarter two. Privacy notice translation and lawful basis re-mapping. Add the constitutional-schedule language. Replace legitimate-interest invocations with consent flows or Section 7 grounds for Indian Data Principals. Update consent UX to the DPDPA Rule 5 standard (withdrawal-as-simple-as-providing, which is usually stricter than the GDPR Article 7 implementation).

Quarter three. DPA template update and DPBI registration readiness. Add Rule 6(f) security clauses to existing DPA. Establish the DPBI complaint pathway in your privacy notice. If you are likely to be designated an SDF, begin DPO India-residency planning and Board reporting line establishment.

Quarter four. Breach response dual-pathway extension. Add DPBI notification template to your existing breach playbook. Identify CERT-In Direction 70B applicability and the six-hour parallel clock. If sectoral, add the relevant regulator (RBI, SEBI, IRDAI) notification template.

What this guide does not cover

Three areas I left out deliberately:

1. The UK GDPR / DPA 2018 stack. Post-Brexit, the UK runs its own derived regime that is currently substantially aligned with EU GDPR but is diverging on points like adequacy with international transfer mechanisms and the post-2024 Data (Use and Access) Act amendments. The synthesis pattern works the same way; the third regime adds a column to your matrix rather than a fundamentally different mechanism. Worth a separate treatment if your UK exposure is material.

2. The ePrivacy / cookies / electronic marketing layer. The ePrivacy Directive (and the long-pending ePrivacy Regulation) governs cookies, electronic marketing, and traffic data in ways that are partly separate from GDPR. India has no direct equivalent yet, though the Digital India Act may close that gap. If your product is consumer-facing or uses ad-tech at scale, this is its own workstream.

3. The forthcoming Digital India Act and the DPDPA Rule 14 cross-border specifics. Both are pending. The DIA is expected to replace the IT Act and may layer additional intermediary obligations on top of DPDPA. Rule 14 cross-border specifics are still subject to government clarification. Compliance teams should monitor both; this guide reflects the regime as notified through May 2026.

This is a practitioner reference, not legal advice. It reflects the DPDPA and the DPDP Rules 2025 as notified 13 November 2025, the GDPR as currently in force, the EU AI Act Omnibus political agreement of 7 May 2026, and publicly available DPBI and EDPB guidance as of 25 May 2026. Compliance teams should validate specific obligations against current MeitY and DPBI notifications, EU Commission and EDPB guidance, and counsel review.

ControlForge synthesises DPDPA + Rules 2025, GDPR, UK GDPR, and adjacent sectoral frameworks (RBI ITGRCA, SEBI CSCRF, IRDAI 2026, CERT-In Direction 70B) through cross-framework synthesis clusters covering notice, consent, rights, breach, cross-border, processor obligations, and DPO mechanics.