Der indische DPDP Act 2023 und die DPDP Rules 2025: Rollen, Data Protection Board und was in welcher der drei Inkraftsetzungsstufen gilt

Problem in der Praxis

In deutschen Konzernen kursieren zwei gegensätzliche Fehlannahmen. Die erste: Der DPDP Act sei seit November 2025 vollständig in Kraft, man sei also bereits im Verzug. Sie stammt aus Sekundärquellen, die das Erscheinen der Rules am 13.11.2025 mit dem Inkrafttreten aller Abschnitte gleichsetzen. Der Wortlaut von G.S.R. 843(E) widerlegt das: Er setzt am Veröffentlichungstag ausdrücklich nur eine benannte Gruppe von Vorschriften in Kraft und verschiebt den Rest um ein Jahr bzw. achtzehn Monate.

Die zweite Fehlannahme ist das Spiegelbild: Weil die Kernpflichten noch nicht gelten, könne Indien warten. Das unterschätzt den Vorlauf. Mit der dritten Stufe gelten Notice- und Einwilligungsanforderungen, Sicherheitsmaßnahmen, Meldung von Datenpannen, Löschpflichten und Betroffenenrechte auf einen Schlag, und die Rules verlangen dafür Systemeigenschaften (Protokollierung, einen Weg zur Benachrichtigung Betroffener über ihr Nutzerkonto oder einen von ihnen registrierten Kommunikationsweg, veröffentlichte Kontaktdaten, Beschwerdewege), die sich nicht in Wochen nachrüsten lassen. Für Einwilligungen, die vor dem Inkrafttreten eingeholt wurden, verlangt s. 5(2) zudem eine nachträgliche Notice, sobald es vernünftigerweise praktikabel ist.

Dazu kommt ein Begriffsproblem. Der Act arbeitet mit eigenen Rollenbegriffen (Data Fiduciary, Data Principal, Consent Manager, Significant Data Fiduciary), die nach DSGVO-Begriffen klingen. Wer sie ungeprüft in die DSGVO-Terminologie übersetzt, übersieht Eigenheiten des indischen Gesetzes, etwa dass es nur digitale Daten erfasst oder dass ein Consent Manager eine in Indien gegründete Gesellschaft sein muss. Wie die Rollen aus EU-Sicht einzuordnen sind, beurteilt sich nach der DSGVO, siehe dsgvo-005.

CISO-Einordnung

Gegenstand und Regelungsarchitektur. Der DPDP Act regelt die Verarbeitung digitaler personenbezogener Daten in einer Weise, die das Recht des Einzelnen auf Schutz seiner Daten und das Bedürfnis, Daten für rechtmäßige Zwecke zu verarbeiten, gleichermaßen anerkennen soll. Er ist in neun Kapitel gegliedert: Einleitung mit Definitionen und Anwendungsbereich, Pflichten des Data Fiduciary, Rechte und Pflichten der Data Principals, Sondervorschriften (Übermittlung ins Ausland, Ausnahmen), das Data Protection Board, dessen Befugnisse und Verfahren, Rechtsmittel und alternative Streitbeilegung, Sanktionen sowie Schlussvorschriften, dazu ein Schedule mit den Höchstbeträgen der Geldstrafen. Vieles regelt der Act nur im Grundsatz und überlässt die Ausgestaltung Rules der Zentralregierung (s. 40). Die DPDP Rules, 2025 sind diese Ausgestaltung; ihr Entwurf wurde als G.S.R. 02(E) am 03.01.2025 zur Stellungnahme veröffentlicht. Nach s. 38 gilt der Act zusätzlich zu anderem Recht und nicht an dessen Stelle; im Konfliktfall setzt er sich durch.

Die Rollen im Überblick.

• Data Fiduciary ist, wer allein oder gemeinsam mit anderen Zweck und Mittel der Verarbeitung bestimmt (s. 2(i)). Er trägt nach s. 8(1) die Verantwortung für die Einhaltung des Act und der Rules auch für Verarbeitungen, die ein Data Processor in seinem Auftrag vornimmt, und zwar ungeachtet abweichender Vereinbarungen.
• Data Processor ist, wer im Auftrag eines Data Fiduciary verarbeitet (s. 2(k)). Der Act richtet seine Pflichten an den Data Fiduciary; den Processor erreicht er vor allem über den gültigen Vertrag, den s. 8(2) für seinen Einsatz bei Tätigkeiten im Zusammenhang mit dem Angebot von Waren oder Dienstleistungen an Data Principals verlangt, und über die Pflicht des Fiduciary, ihn zur Einstellung der Verarbeitung oder zur Löschung zu veranlassen.
• Data Principal ist die Person, auf die sich die Daten beziehen; bei einem Kind (Person unter achtzehn Jahren, s. 2(f)) gehören die Eltern oder der gesetzliche Vormund dazu, bei einer Person mit Behinderung der für sie handelnde gesetzliche Vormund (s. 2(j)).
• Consent Manager ist eine beim Board registrierte Person, die als zentrale Anlaufstelle eine zugängliche, transparente und interoperable Plattform betreibt, über die Data Principals Einwilligungen erteilen, verwalten, überprüfen und widerrufen (s. 2(g), s. 6(7) bis (9)). Die Registrierungsbedingungen in der First Schedule der Rules verlangen unter anderem eine in Indien gegründete Gesellschaft und ein Reinvermögen von mindestens zwei crore Rupien.
• Significant Data Fiduciary ist ein Data Fiduciary oder eine Klasse von Data Fiduciaries, die die Zentralregierung nach einer Bewertung von Faktoren wie Umfang und Sensibilität der Daten, Risiko für die Rechte der Data Principals oder Auswirkungen auf Sicherheit und öffentliche Ordnung per Notifikation benennt (s. 2(z), s. 10(1)). Die Einstufung entsteht also nicht aus einer Schwelle, sondern aus einem Rechtsakt. Benannte Significant Data Fiduciaries haben Zusatzpflichten, darunter einen in Indien ansässigen Data Protection Officer, einen unabhängigen Datenauditor und periodische Datenschutz-Folgenabschätzungen (s. 10(2)); Einzelheiten in dpdpa-004. Notifikationen nach s. 10 liegen dem Quellensatz nicht vor.

Eine eigene Kategorie besonders schutzbedürftiger Daten definiert der Act nicht; Sensibilität erscheint nur als Kriterium für die Benennung als Significant Data Fiduciary.

Das Data Protection Board und der Rechtsweg. Das Board ist eine Körperschaft mit eigener Rechtspersönlichkeit (s. 18(2)) und mit G.S.R. 844(E) seit dem 13.11.2025 errichtet. Nach Rule 20, die bereits gilt, arbeitet es als digitales Büro; s. 28(1), der dasselbe für das Verfahren vorgibt, folgt erst in Stufe (c). Mitglieder werden für zwei Jahre ernannt (s. 20(2)); das Auswahlverfahren regelt Rule 17. Gegen Anordnungen des Board führt der Rechtsweg zum Telecom Disputes Settlement and Appellate Tribunal (s. 2(a), s. 29), Einzelheiten in dpdpa-007. Die Errichtung ist bereits wirksam, die Befugnisse zur Untersuchung und Sanktion (s. 27 außer (1)(d), s. 28 bis 34) sind es noch nicht.

Die drei Inkraftsetzungsstufen, genau gelesen. s. 1(2) erlaubt der Zentralregierung, das Gesetz per Notifikation in Kraft zu setzen und für verschiedene Vorschriften verschiedene Daten zu bestimmen. Davon hat sie mit G.S.R. 843(E) Gebrauch gemacht. Die Fristen laufen nach dem Wortlaut ab dem Tag der Veröffentlichung; veröffentlicht wurde am 13.11.2025. Rule 1 der DPDP Rules spiegelt dieselbe Staffelung für die Rules.

• Stufe (a), seit der Veröffentlichung am 13.11.2025: s. 1(2), s. 2 (Definitionen), s. 18 bis 26 (Errichtung, Zusammensetzung, Amtszeit und Organisation des Board), s. 35 (Haftungsfreistellung bei Handeln in gutem Glauben), s. 38 bis 43 (Verhältnis zu anderem Recht, Ausschluss der Zivilgerichte, Ermächtigung zu Rules, Vorlage an das Parlament, Änderung des Schedule, Beseitigung von Schwierigkeiten) sowie s. 44(1) und (3) (Folgeänderungen am Telecom Regulatory Authority of India Act, 1997 und am Right to Information Act, 2005). Aus den Rules: Rules 1, 2 und 17 bis 21 (Ernennung der Mitglieder, Bezüge, Sitzungen und Beglaubigung, Arbeit als digitales Büro, Personal des Board).
• Stufe (b), ein Jahr nach der Veröffentlichung: s. 6(9) (Registrierung der Consent Manager beim Board) und s. 27(1)(d) (Untersuchung von Verstößen gegen Registrierungsbedingungen), aus den Rules Rule 4 (Registrierung und Pflichten der Consent Manager mit der First Schedule).
• Stufe (c), achtzehn Monate nach der Veröffentlichung: s. 3 bis 5, s. 6(1) bis (8) und (10), s. 7 bis 17, s. 27 außer (1)(d), s. 28 bis 34, s. 36, s. 37 und s. 44(2). Aus den Rules: Rules 3, 5 bis 16, 22 und 23.

Drei Folgerungen ergeben sich aus dieser Staffelung. Erstens tritt der Anwendungsbereich (s. 3) erst mit Stufe (c) in Kraft; bis dahin gibt es keine Norm, die den Act auf eine konkrete Verarbeitung anwendet. Zweitens sind die in Kraft befindlichen Teile der Stufe (a) Organisations- und Rahmenrecht: Sie richten das Board ein und ermächtigen zu Rules, verpflichten aber keinen Data Fiduciary. Drittens ist die Stufe (b) eine Sonderstufe für Consent Manager: Plattformbetreiber können sich registrieren lassen, bevor Data Principals ihre Einwilligungen nach s. 6(7) über sie steuern können, denn diese Vorschrift folgt erst in Stufe (c). Der Schedule mit den Höchstbeträgen wird in G.S.R. 843(E) nicht gesondert genannt; er wird über s. 33(1) angewandt, das in Stufe (c) in Kraft tritt.

Eine Auslegungsregel in s. 1(2) ist für Übergangsfragen wichtig: Wo eine Vorschrift vom Inkrafttreten "dieses Act" spricht, ist das Inkrafttreten dieser Vorschrift gemeint. Für s. 5(2), die nachträgliche Notice für vorher erteilte Einwilligungen, ist das also der Beginn der Stufe (c). Einwilligungen, die ein Unternehmen heute in Indien einholt, fallen damit später unter diese Nachholpflicht. s. 5(2)(b) lässt die Fortsetzung der Verarbeitung bis zu einem Widerruf zu; die übrigen ab Stufe (c) geltenden Pflichten bleiben davon unberührt, insbesondere die Löschung nach s. 8(7), sobald vernünftigerweise anzunehmen ist, dass der festgelegte Zweck nicht mehr erfüllt wird, soweit keine gesetzliche Aufbewahrungspflicht besteht.

Was für ein deutsches Unternehmen heute gilt und was noch nicht. Aus dem DPDP Act und den Rules gilt heute keine Pflicht, die ein deutsches Unternehmen, seine indische Tochter oder sein indisches Servicezentrum als Data Fiduciary erfüllen müsste. Es gibt das Board als Behörde, aber es kann noch nicht nach s. 27 und 28 untersuchen und nach s. 33 keine Geldstrafen verhängen. Mit Stufe (b) ändert sich das nur für Consent Manager: Wer sich registrieren lässt, unterliegt ab dann den Pflichten aus Rule 4(3) und Part B der First Schedule, darunter Aufzeichnungen über Einwilligungen und angemessene Sicherheitsvorkehrungen. Für die Zeit bis Stufe (c) belegt der Quellensatz außerdem nur, dass die in s. 44(2) vorgesehene Streichung von s. 43A Information Technology Act, 2000 erst dann wirksam wird. Ob und mit welchem Inhalt s. 43A und andere indische Vorschriften außerhalb des DPDP Act heute gelten, ist nicht Teil des Quellensatzes dieses Tracks; Aussagen dazu trifft der Korpus nicht. Ebenso wenig liegen Notifikationen nach s. 10 (Significant Data Fiduciaries), s. 16 (Übermittlungsbeschränkungen) oder s. 17(3) und (5) (Freistellungen) vor; ob es sie gibt, ist nicht gemessen.

Umsetzungsperspektive

1. Die Stichtage richtig ableiten. Im Kalender stehen zwei Termine: ein Jahr und achtzehn Monate nach dem 13.11.2025. Das konkrete Tagesdatum sollte die Rechtsabteilung oder lokale Beratung bestätigen, weil der Quellensatz die Fristberechnung nicht ausdrücklich regelt.
2. Betroffenheit vorab klären. Für jede Rechtseinheit und jede Verarbeitung mit Indienbezug festhalten, ob sie unter s. 3 fällt und ob eine Ausnahme nach s. 17 greift (dpdpa-002). Das ist die Grundlage aller weiteren Schritte.
3. Rollen je Verarbeitung festlegen. Wer bestimmt Zweck und Mittel, wer verarbeitet im Auftrag? Im Konzern ist das selten einheitlich.
4. Die Rules-Anforderungen in Systemanforderungen übersetzen. Notice-Inhalte, Widerrufswege, Protokollierung, Meldeprozess, Löschfristen und Kontaktstellen sind Produkt- und Betriebsanforderungen mit Vorlaufzeit (dpdpa-003 bis dpdpa-005).
5. Altbestände an Einwilligungen inventarisieren. Für Einwilligungen, die vor Stufe (c) eingeholt werden und danach weiter genutzt werden sollen, ist die nachträgliche Notice nach s. 5(2) vorzubereiten.
6. Benennungen beobachten. Notifikationen nach s. 10, s. 16 und s. 17 können die Pflichtenlage für einzelne Unternehmen oder Klassen verändern; sie erscheinen im Official Gazette.

Typische Fehler

1. Das Erscheinen der Rules am 13.11.2025 wird als Inkrafttreten aller Pflichten gelesen, weil eine Sekundärquelle das so darstellt.
2. Aus "noch nicht in Kraft" wird "kein Handlungsbedarf", obwohl die dritte Stufe viele Pflichten gleichzeitig auslöst und technische Vorlaufzeit braucht.
3. Ein konkretes Tagesdatum für Stufe (b) oder (c) wird als gesichert in Verträge oder Projektpläne übernommen, ohne die Fristberechnung bestätigen zu lassen.
4. Die Errichtung des Board wird mit dessen Sanktionsbefugnis gleichgesetzt.
5. Der Begriff Data Fiduciary wird ungeprüft in DSGVO-Terminologie übersetzt, und Eigenheiten des DPDP Act wie die Beschränkung auf digitale Daten gehen verloren.
6. Die Einstufung als Significant Data Fiduciary wird an einer selbst gesetzten Größenschwelle gemessen, obwohl sie eine Notifikation der Zentralregierung voraussetzt.
7. Indisches Recht außerhalb des DPDP Act wird nicht geprüft, weil man annimmt, das neue Gesetz habe es bereits ersetzt, obwohl die Streichung von s. 43A IT Act nach s. 44(2) erst mit Stufe (c) wirksam wird.

Risiken und Trade-offs

Der Grundkonflikt ist der Zeitpunkt der Investition. Wer früh umsetzt, baut auf einem Rechtsstand, der durch weitere Notifikationen, Anordnungen nach s. 43 oder Änderungen am Schedule nach s. 42 noch beeinflusst werden kann. Wer spät umsetzt, muss Notice, Einwilligungsverwaltung, Protokollierung und Meldeprozess unter Zeitdruck einführen und riskiert, mit dem ersten Tag der Stufe (c) Pflichten nicht erfüllen zu können.

Ein zweiter Trade-off betrifft die Konzernsteuerung. Eine zentrale Umsetzung aus Deutschland vermeidet Doppelarbeit, verkennt aber leicht indische Eigenheiten, etwa die Sprachoptionen für Notices oder den Beschwerdeweg vor dem Board. Eine rein lokale Umsetzung in der indischen Tochter erfasst diese Eigenheiten, verliert aber die Verarbeitungen, die von Deutschland aus für indische Kunden laufen.

Entscheidungspunkte

• Welche Stichtage für Stufe (b) und (c) legen wir unseren Plänen zugrunde, und wer bestätigt sie verbindlich?
• Welche Rechtseinheiten und Verarbeitungen fallen voraussichtlich unter den DPDP Act, und welche Ausnahmen wollen wir in Anspruch nehmen?
• Wer verantwortet die Umsetzung im Konzern: die deutsche Zentrale, die indische Tochter oder beide gemeinsam?
• Bis wann sollen Notice, Einwilligungsverwaltung, Protokollierung und Meldeprozess bereitstehen?
• Wer beobachtet das Official Gazette auf Notifikationen nach s. 10, s. 16 und s. 17?

Praktische Empfehlungen

• Den Rechtsstand mit Fundstelle dokumentieren: G.S.R. 843(E) für den Act, Rule 1 für die Rules, jeweils mit Datum der Veröffentlichung.
• Eine Indien-Betroffenheitsanalyse je Rechtseinheit und Verarbeitung anlegen und vor Stufe (c) abschließen.
• Bei der Projektplanung Stufe (c) als festen Meilenstein führen und Puffer für Systemanpassungen einplanen.
• Für die Zeit bis Stufe (c) mit lokaler Beratung klären, welche Pflichten aus indischem Recht außerhalb des DPDP Act bestehen.
• Notifikationen der Zentralregierung beobachten lassen und die Analyse bei jeder neuen Notifikation aktualisieren.

Relevante Normreferenzen

• DPDP Act, 2023 (No. 22 of 2023): s. 1(2) (Inkraftsetzung, Auslegungsregel zum Inkrafttreten), s. 2 (Definitionen, insbesondere (a), (f), (g), (i), (j), (k), (z)), s. 5(2) (Notice für vorher erteilte Einwilligungen), s. 6(7) bis (9) (Consent Manager), s. 8(1) und (2) (Verantwortung des Data Fiduciary, Vertrag mit dem Data Processor), s. 10 (Significant Data Fiduciary), s. 18 bis 26 (Board), s. 27 bis 34 (Befugnisse, Verfahren, Rechtsmittel, Sanktionen), s. 38 (Verhältnis zu anderem Recht), s. 40 (Rules), s. 44 (Folgeänderungen, darunter s. 44(2) zur Streichung von s. 43A IT Act).
• G.S.R. 843(E) vom 13.11.2025 (Inkraftsetzung in drei Stufen); G.S.R. 844(E) vom 13.11.2025 (Errichtung des Board, Sitz); G.S.R. 845(E) vom 13.11.2025 (vier Mitglieder).
• DPDP Rules, 2025 (G.S.R. 846(E) vom 13.11.2025): Rule 1 (gestaffeltes Inkrafttreten), Rule 4 und First Schedule (Consent Manager), Rule 17 bis 21 (Board).
• Nicht im Quellensatz und deshalb nicht ausgewertet: Information Technology Act, 2000 und seine Durchführungsvorschriften; Notifikationen nach s. 10, s. 16, s. 17(3) und (5); Erläuterungen des Ministry of Electronics and Information Technology.
• Abgrenzung: Die DSGVO-Seite des deutschen Unternehmens, einschließlich der Übermittlung aus der EU nach Indien, behandelt der dsgvo-Track (dsgvo-005, Datenpannen nach DSGVO in dsgvo-003); Vergleiche hier sind nur Orientierung. Der lgpd-Track ist ein strukturell vergleichbarer Auslandstrack für Brasilien, ohne Rechtsaussage für Indien. Innerhalb dieses Tracks: Anwendungsbereich und Ausnahmen in dpdpa-002, Einwilligung und Notice in dpdpa-003, Pflichten des Data Fiduciary in dpdpa-004, Datenpannen in dpdpa-005, Übermittlung ins Ausland in dpdpa-006, Board, Verfahren und Sanktionen in dpdpa-007.