Cybervize

Gilt der DPDP Act für uns? Anwendungsbereich, Ausnahmen nach s. 17 und der Fall des indischen Entwicklungs- oder Servicezentrums deutscher Unternehmen

Indien: DPDP ActCISODatenschutzbeauftragterCompliance ManagerGeschäftsführung

Herausgeber: Cybervize Redaktion

Kernaussage

Der Anwendungsbereich des DPDP Act steht in s. 3 und tritt wie die Ausnahmen in s. 17 erst achtzehn Monate nach der Veröffentlichung von G.S.R. 843(E) am 13.11.2025 in Kraft. Ab dann gilt der Act für die Verarbeitung digitaler personenbezogener Daten in Indien, wenn die Daten digital erhoben oder nichtdigital erhoben und später digitalisiert wurden, und für Verarbeitungen außerhalb Indiens, wenn sie im Zusammenhang mit einer Tätigkeit stehen, die sich auf das Angebot von Waren oder Dienstleistungen an Data Principals in Indien bezieht. Eine indische Niederlassung ist dafür keine Voraussetzung. Nicht erfasst sind Daten, die eine natürliche Person für persönliche oder häusliche Zwecke verarbeitet, und Daten, die die betroffene Person selbst öffentlich zugänglich gemacht oder deren Veröffentlichung sie veranlasst hat oder die eine nach indischem Recht dazu verpflichtete Person öffentlich zugänglich gemacht oder hat zugänglich machen lassen.

Für das typische indische Entwicklungs- oder Servicezentrum eines deutschen Konzerns ist s. 17(1)(d) die wichtigste Norm. Sie greift nur, wenn alle Voraussetzungen zusammen vorliegen: Es geht um personenbezogene Daten von Data Principals, die sich nicht in Indien befinden; die Daten werden aufgrund eines Vertrags verarbeitet; und diesen Vertrag hat eine in Indien ansässige Person mit einer Person außerhalb Indiens geschlossen. Dann gelten Kapitel II außer s. 8(1) und (5), Kapitel III und s. 16 nicht.

Es bleibt also nicht nichts übrig. Der Data Fiduciary bleibt nach s. 8(1) für die Einhaltung verantwortlich und muss nach s. 8(5) angemessene Sicherheitsvorkehrungen gegen Datenpannen treffen, auch für Verarbeitungen durch seinen Data Processor; stellt das Board nach Abschluss einer Untersuchung einen erheblichen Verstoß gegen s. 8(5) fest, kann es nach s. 33(1) und dem Schedule eine Geldstrafe von bis zu 250 crore Rupien verhängen. Die Vorschriften über Board, Verfahren und Sanktionen gelten weiter. Die Ausnahme gilt nur für den Teil der Verarbeitung, der alle Voraussetzungen erfüllt; Daten von Personen, die sich in Indien befinden, etwa der vor Ort tätigen Beschäftigten oder von Kunden in Indien, fallen nicht darunter. Maßgeblich ist der Aufenthalt der betroffenen Person, nicht Staatsangehörigkeit, Beschäftigtenstatus oder Zugehörigkeit zum Kundenbestand.

Auf dieser Seite
  1. Problem in der Praxis
  2. CISO-Einordnung
  3. Umsetzungsperspektive
  4. Typische Fehler
  5. Risiken und Trade-offs
  6. Entscheidungspunkte
  7. Praktische Empfehlungen
  8. Relevante Normreferenzen

Problem in der Praxis

Deutsche Konzerne betreiben in Indien häufig Einheiten, die für die Zentrale oder für europäische Kunden arbeiten: Softwareentwicklung, IT-Betrieb, Kundenservice, Buchhaltung, HR-Shared-Services. Für diese Einheiten wird oft pauschal angenommen, der DPDP Act sei "nicht relevant, weil es um europäische Daten geht". Das ist in zwei Richtungen zu grob.

Erstens greift die Ausnahme des s. 17(1)(d) nicht für alles, was in einem solchen Zentrum verarbeitet wird. Die Daten der eigenen, in Indien tätigen Beschäftigten, der Bewerber vor Ort, von Dienstleistern oder Kunden in Indien betreffen in aller Regel Personen, die sich in Indien befinden, und fallen dann unter s. 3(a) ohne diese Ausnahme. Maßgeblich ist der Aufenthalt der betroffenen Person, nicht Staatsangehörigkeit, Beschäftigtenstatus oder Zugehörigkeit zum Kundenbestand. Ein Zentrum hat deshalb fast immer einen erfassten und einen ausgenommenen Teil, und die Grenze verläuft quer durch Systeme, Ticketsysteme und Datenbanken.

Zweitens ist die Ausnahme keine vollständige Freistellung. Die Pflicht zu angemessenen Sicherheitsvorkehrungen bleibt, und gerade sie ist mit dem höchsten Betrag im Schedule bewehrt. Wer das Zentrum aus dem Indien-Programm herausnimmt, nimmt damit auch die Sicherheitsfrage heraus, die der Act ausdrücklich stehen lässt.

Spiegelbildlich unterschätzen Vertriebs- und Digitalbereiche in Deutschland den Auslandstatbestand: Ein Webshop, eine App oder ein SaaS-Angebot, das von Deutschland aus an Kunden in Indien geht, kann nach s. 3(b) erfasst sein, ohne dass in Indien eine Gesellschaft besteht.

CISO-Einordnung

Die zwei Anknüpfungspunkte des s. 3. Erfasst ist erstens die Verarbeitung digitaler personenbezogener Daten innerhalb Indiens, wenn die Daten digital erhoben wurden oder nichtdigital erhoben und anschließend digitalisiert wurden (s. 3(a)). Dieser Tatbestand knüpft am Ort der Verarbeitung an, nicht an der Herkunft oder Staatsangehörigkeit der betroffenen Person. Deshalb erfasst er grundsätzlich auch Daten europäischer Personen, die in Indien verarbeitet werden, und deshalb braucht es die Ausnahme in s. 17(1)(d). Erfasst ist zweitens die Verarbeitung außerhalb Indiens, wenn sie im Zusammenhang mit einer Tätigkeit steht, die sich auf das Angebot von Waren oder Dienstleistungen an Data Principals innerhalb Indiens bezieht (s. 3(b)). Der Act definiert "offering" nicht näher und kennt neben dem Angebot keinen weiteren Auslandstatbestand, etwa für die bloße Beobachtung von Verhalten.

Zwei Begriffe begrenzen beide Tatbestände. Der Act gilt nur für digitale personenbezogene Daten; Papierakten, die nie digitalisiert werden, liegen außerhalb. Und Verarbeitung ist ein ganz oder teilweise automatisierter Vorgang an digitalen Daten (s. 2(x)). Personenbezogen sind Daten über eine Person, die durch oder in Bezug auf diese Daten identifizierbar ist (s. 2(t)).

Die Ausnahmen in s. 3(c). Der Act gilt nicht für personenbezogene Daten, die eine natürliche Person für persönliche oder häusliche Zwecke verarbeitet, und nicht für Daten, die öffentlich zugänglich gemacht wurden oder deren Veröffentlichung veranlasst wurde, und zwar entweder von der betroffenen Person selbst oder von einer anderen Person, die nach in Indien geltendem Recht zur Veröffentlichung verpflichtet ist ("made or caused to be made publicly available"). Für Unternehmen ist die zweite Ausnahme die relevante, aber sie hängt daran, wer die Veröffentlichung vorgenommen oder veranlasst hat. Hat die betroffene Person oder eine gesetzlich zur Veröffentlichung verpflichtete Person die Veröffentlichung veranlasst, ist es unschädlich, dass ein Dritter ohne eigene Pflicht sie ausgeführt hat. Nicht darunter fallen Daten, deren Veröffentlichung weder die betroffene Person noch eine gesetzlich zur Veröffentlichung verpflichtete Person vorgenommen oder veranlasst hat.

Was das für die Konzernsicht heißt. Der Act behandelt jede Person gesondert; Person ist auch eine Gesellschaft (s. 2(s)). Ein Konzernprivileg kennt er nicht. Typische Konstellationen, jeweils als Prüfrichtung und nicht als Einstufung:

  • Die indische Tochter verarbeitet die Daten ihrer Beschäftigten, Bewerber und indischen Geschäftspartner in Indien. Das ist s. 3(a), und s. 17(1)(d) greift nicht, soweit sich die betroffenen Personen in Indien befinden.
  • Die deutsche Zentrale verkauft von Deutschland aus an Kunden in Indien. Das kann s. 3(b) sein, ohne indische Gesellschaft.
  • Die deutsche Zentrale nutzt Infrastruktur in Indien, etwa ein dort betriebenes Rechenzentrum, für eigene Verarbeitungen. Dann findet die Verarbeitung in Indien statt (s. 3(a)), und es kommt darauf an, ob s. 17(1)(d) greift.
  • Die deutsche Zentrale verarbeitet in Deutschland Daten indischer Beschäftigter der Tochter, etwa in einem zentralen HR-System. Ob das unter s. 3(b) fällt, hängt daran, ob es mit dem Angebot von Waren oder Dienstleistungen an Data Principals in Indien zusammenhängt; der Wortlaut entscheidet diese Konstellation nicht ausdrücklich. Die vorgelagerte Übermittlung aus Indien behandelt dpdpa-006.

Rollen im Servicezentrum. Data Fiduciary ist, wer allein oder gemeinsam mit anderen Zweck und Mittel bestimmt (s. 2(i)); Data Processor, wer in seinem Auftrag verarbeitet (s. 2(k)). Im typischen Outsourcing-Fall bestimmt die deutsche Zentrale oder der europäische Kunde, das indische Zentrum verarbeitet. Der Act richtet seine Pflichten an den Data Fiduciary; eine Vorschrift, die sich ausdrücklich und unmittelbar an den Data Processor richtet, enthalten weder Act noch Rules. Der Data Fiduciary bleibt nach s. 8(1) auch für Verarbeitungen seines Processor verantwortlich, ungeachtet abweichender Vereinbarungen. Wie sich das auf einen ausländischen Data Fiduciary auswirkt, dessen indischer Processor im Rahmen des s. 17(1)(d) tätig ist, regelt die Quelle nicht ausdrücklich. Ob eine Geldstrafe nach s. 33, die sich allgemein gegen eine "person" richtet, auch einen Processor unmittelbar treffen kann, lässt der Wortlaut ebenfalls offen. Beides gehört in die lokale Beratung.

s. 17(1)(d) mit allen Voraussetzungen. Die Ausnahme verlangt kumulativ:

  1. Die verarbeiteten personenbezogenen Daten betreffen Data Principals, die sich nicht im Hoheitsgebiet Indiens befinden. Der Wortlaut stellt auf den Aufenthalt ab, nicht auf Staatsangehörigkeit oder Wohnsitz; auf welchen Zeitpunkt es ankommt, regelt er nicht.
  2. Die Verarbeitung erfolgt aufgrund eines Vertrags ("pursuant to any contract").
  3. Der Vertrag wurde von einer in Indien ansässigen Person mit einer Person außerhalb Indiens geschlossen. "Based in India" definiert der Act nicht.

Der Wortlaut nennt keine Notifikation, keine Anzeige beim Board und keine Bewertung des Datenschutzniveaus im Land des Vertragspartners als Voraussetzung. Er schließt auch Verträge innerhalb eines Konzerns nicht aus, setzt aber zwei Vertragsparteien voraus. Daraus folgen drei praktische Fragen, die die Quelle nicht beantwortet: ob eine unselbständige indische Zweigniederlassung eines deutschen Unternehmens, die keine eigene Person ist, die Ausnahme auslösen kann; wie ein Datenbestand zu behandeln ist, der Personen in und außerhalb Indiens mischt; und wie Personen einzuordnen sind, die sich nur vorübergehend in Indien aufhalten.

Die Rechtsfolge, genau gelesen. Wo eine der Fallgruppen des s. 17(1) vorliegt, gelten die Vorschriften des Kapitels II mit Ausnahme von s. 8(1) und (5), die des Kapitels III und s. 16 nicht. Konkret entfallen damit für den ausgenommenen Teil unter anderem die Anforderungen an Rechtsgrundlage, Notice und Einwilligung (s. 4 bis 7), die Meldung von Datenpannen an Board und Betroffene (s. 8(6)), die Lösch- und Kontaktstellenpflichten (s. 8(7) bis (10)), die Regeln für Kinder (s. 9), die Zusatzpflichten als Significant Data Fiduciary (s. 10), die Betroffenenrechte (s. 11 bis 14) und die Übermittlungsbeschränkung (s. 16).

Weiter gelten:

  • s. 8(1): die Verantwortung des Data Fiduciary für die Einhaltung, auch für Verarbeitungen durch seinen Data Processor.
  • s. 8(5): die Pflicht, personenbezogene Daten in seinem Besitz oder unter seiner Kontrolle durch angemessene Sicherheitsvorkehrungen gegen Datenpannen zu schützen, einschließlich der Verarbeitung durch seinen Data Processor. Stellt das Board nach Abschluss einer Untersuchung einen erheblichen Verstoß fest, kann es nach s. 33(1) in Verbindung mit Nr. 1 des Schedule eine Geldstrafe von bis zu 250 crore Rupien verhängen.
  • Die übrigen Kapitel: Anwendungsbereich und Definitionen (Kapitel I), das Board mit seinen Untersuchungs- und Anordnungsbefugnissen (Kapitel V und VI), Rechtsmittel (Kapitel VII), Sanktionen (Kapitel VIII) und die Schlussvorschriften (Kapitel IX), darunter das Auskunftsverlangen der Zentralregierung nach s. 36 und das Verhältnis zu anderem indischem Recht nach s. 38.

Für die Rules ist die Lage weniger klar, als es die Gesetzesnorm nahelegt. Rule 6 beschreibt den Mindestinhalt der Sicherheitsvorkehrungen nach s. 8(5), darunter Verschlüsselung, Verschleierung, Maskierung oder Token, Zugriffskontrolle, Protokollierung und Überwachung, eine einjährige Aufbewahrung von Protokollen und Daten, soweit Gesetze nichts anderes verlangen, Datensicherungen und eine Sicherheitsklausel im Vertrag mit dem Data Processor. s. 17(1) benennt nur Vorschriften des Act; ob Rule 6 im Fall des s. 17(1)(d) vollständig als Maßstab des s. 8(5) gilt, sagt die Quelle nicht ausdrücklich. Ebenso offen ist, ob die Aufbewahrungspflicht für Daten und Protokolle nach Rule 8(3) und die Anforderungen nach Rule 15 an Übermittlungen ins Ausland den ausgenommenen Teil erfassen. Die vorsichtige Planung nimmt Rule 6 als Maßstab, weil die zugrunde liegende Pflicht aus s. 8(5) unstreitig weiter gilt.

Und schließlich: s. 17(1)(d) befreit nur vom DPDP Act. Ob andere indische Vorschriften, etwa sektorale Melde- oder Aufbewahrungspflichten, für das Zentrum gelten, ist nicht Gegenstand dieses Quellensatzes.

Die übrigen Ausnahmen im Überblick. Dieselbe Rechtsfolge wie bei (d) gilt in den anderen Fallgruppen des s. 17(1): Verarbeitung, die zur Durchsetzung eines Rechts oder Anspruchs erforderlich ist; Verarbeitung durch Gerichte, Tribunale oder andere gesetzlich mit gerichtlichen, quasigerichtlichen, regulatorischen oder aufsichtlichen Aufgaben betraute Stellen in Indien, soweit für diese Aufgaben erforderlich; Verarbeitung im Interesse der Verhütung, Aufdeckung, Untersuchung oder Verfolgung von Straftaten oder Rechtsverstößen nach indischem Recht; Verarbeitung, die für eine von Gericht, Tribunal oder zuständiger Behörde genehmigte Umstrukturierung wie Verschmelzung oder Spaltung erforderlich ist; und Verarbeitung zur Feststellung der Finanzinformationen sowie der Vermögenswerte und Verbindlichkeiten einer Person, die mit einer Zahlung aus einem bei einem Finanzinstitut aufgenommenen Darlehen oder Vorschuss in Verzug ist, sofern die Verarbeitung den einschlägigen Offenlegungsvorschriften entspricht. Für deutsche Konzerne ist die Umstrukturierungsausnahme relevant, sie setzt aber eine Genehmigung durch die zuständige Stelle voraus.

Weiter gehen s. 17(2) bis (5): Der ganze Act gilt nicht für Verarbeitungen notifizierter staatlicher Stellen in den dort genannten Staatsinteressen und nicht für Verarbeitungen, die für Forschungs-, Archiv- oder Statistikzwecke erforderlich sind, wenn die Daten nicht für eine Entscheidung über eine bestimmte Person verwendet werden und die vorgeschriebenen Standards eingehalten sind (Rule 16 mit Second Schedule). Die Zentralregierung kann bestimmte Data Fiduciaries, auch in Indien gegründete Startups, von einzelnen Pflichten freistellen (s. 17(3)) und innerhalb von fünf Jahren ab Inkrafttreten der Vorschrift erklären, dass Bestimmungen für bestimmte Data Fiduciaries befristet nicht gelten (s. 17(5)). Notifikationen nach s. 17(2)(a), (3) und (5) liegen dem Quellensatz nicht vor; s. 17(2)(b) wirkt dagegen unmittelbar unter seinen Voraussetzungen.

Präsenzanforderungen und Durchsetzung gegenüber ausländischen Anbietern. Eine allgemeine Pflicht ausländischer Data Fiduciaries, einen Vertreter in Indien zu bestellen, enthält der Act nicht. In Indien ansässig sein muss nur der Data Protection Officer eines Significant Data Fiduciary (s. 10(2)(a)(ii)), und zwar nur, soweit s. 10 auf die Verarbeitung anwendbar ist; für den nach s. 17(1) ausgenommenen Teil gilt s. 10 nicht; Consent Manager müssen nach der First Schedule der Rules in Indien gegründete Gesellschaften sein. Für Anbieter aus dem Ausland ist s. 37 wichtig: Teilt das Board der Zentralregierung schriftlich mit, dass es gegen einen Data Fiduciary in zwei oder mehr Fällen Geldstrafen verhängt hat, und rät es im Interesse der Allgemeinheit zur Sperrung, kann die Zentralregierung nach Anhörung des Data Fiduciary, wenn sie das im Interesse der Allgemeinheit für notwendig oder zweckmäßig hält, mit schriftlicher Begründung anordnen, dass der öffentliche Zugang zu Informationen in den Computerressourcen gesperrt wird, über die der Data Fiduciary seine Angebote an Data Principals in Indien betreibt.

Umsetzungsperspektive

  1. Verarbeitungen je Rechtseinheit kartieren. Für jede Verarbeitung mit Indienbezug festhalten: Ort der Verarbeitung, Herkunft und Aufenthalt der betroffenen Personen, digitale oder nichtdigitale Erhebung, Angebot an Personen in Indien.
  2. Das Zentrum in einen erfassten und einen ausgenommenen Teil zerlegen. Daten von Personen, die sich in Indien befinden, etwa der eigenen Beschäftigten vor Ort, sind erfasst; Auftragsdaten von Personen außerhalb Indiens kommen für s. 17(1)(d) in Frage. Maßgeblich ist der Aufenthalt, nicht die Staatsangehörigkeit.
  3. Die Vertragsgrundlage herstellen. s. 17(1)(d) verlangt eine Verarbeitung aufgrund eines Vertrags zwischen der in Indien ansässigen Person und der Person außerhalb Indiens. Konzerninterne Leistungen sollten deshalb schriftlich vereinbart sein, mit einer Sicherheitsklausel, die sich am Maßstab von Rule 6 orientiert.
  4. Die Sicherheitsvorkehrungen auch für den ausgenommenen Teil führen. s. 8(5) gilt weiter; ein Sicherheitsprogramm für das Zentrum ist deshalb keine freiwillige Leistung.
  5. Grenzfälle dokumentieren und klären lassen. Zweigniederlassung statt Tochter, gemischte Datenbestände, Personen mit wechselndem Aufenthalt und die Rollenverteilung zwischen Zentrale und Zentrum.
  6. Den Auslandstatbestand im Vertrieb prüfen. Digitale Angebote an Kunden in Indien sind ein eigener Prüfpunkt, unabhängig von einer indischen Gesellschaft.

Typische Fehler

  1. Das indische Servicezentrum wird insgesamt als ausgenommen behandelt, obwohl die Daten seiner Beschäftigten vor Ort und anderer Personen, die sich in Indien befinden, nicht unter s. 17(1)(d) fallen.
  2. Die Ausnahme wird als vollständige Freistellung gelesen; s. 8(1) und s. 8(5) sowie Board und Sanktionen bleiben unbeachtet.
  3. Konzerninterne Leistungen laufen ohne Vertrag, obwohl die Ausnahme eine Verarbeitung aufgrund eines Vertrags verlangt.
  4. Eine unselbständige Zweigniederlassung wird ohne Prüfung wie eine Tochtergesellschaft behandelt.
  5. Der Auslandstatbestand des s. 3(b) wird übersehen, weil in Indien keine Gesellschaft besteht.
  6. Die Ausnahme für öffentlich zugängliche Daten wird auf alles angewandt, was im Internet steht, obwohl es darauf ankommt, wer die Veröffentlichung vorgenommen oder veranlasst hat.
  7. Aus der Rolle als Data Processor wird geschlossen, der Act betreffe das Zentrum nicht, ohne die Verantwortung des Data Fiduciary und die offene Frage der Sanktionierung zu klären.
  8. Die Prüfung wird mit dem heutigen Rechtsstand begründet, obwohl s. 3 und s. 17 erst achtzehn Monate nach der Veröffentlichung am 13.11.2025 in Kraft treten.

Risiken und Trade-offs

Der zentrale Trade-off liegt in der Trennung der Datenbestände. Wer Auftragsdaten von Personen außerhalb Indiens und Daten von Personen in Indien technisch und organisatorisch trennt, kann die Ausnahme des s. 17(1)(d) sauber begründen, zahlt dafür aber mit Architektur- und Betriebsaufwand. Wer nicht trennt, muss für gemischte Bestände mit der vollen Pflichtenlage rechnen oder eine Abgrenzung im Ereignisfall nachträglich herleiten.

Ein zweiter Trade-off betrifft die Vertragsgestaltung im Konzern. Ausführliche konzerninterne Verträge schaffen eine belastbare Grundlage für die Ausnahme und für die Sicherheitsvorgaben, erzeugen aber Pflege- und Abstimmungsaufwand zwischen Rechtsabteilungen in zwei Ländern. Schlanke Rahmenverträge sind schneller, lassen aber gerade die Fragen offen, die im Streitfall entscheiden.

Schließlich die Frage der Gestaltung der indischen Präsenz. Eine Tochtergesellschaft schafft eine eigene Vertragspartei; eine Zweigniederlassung ist einfacher, wirft aber die offene Frage auf, ob sie die Ausnahme überhaupt auslösen kann. Diese Entscheidung sollte nicht allein steuerlich getroffen werden.

Entscheidungspunkte

  • Welche unserer Verarbeitungen fallen ab Stufe (c) unter s. 3(a), welche unter s. 3(b), und welche gar nicht?
  • Für welche Verarbeitungen des indischen Zentrums wollen wir uns auf s. 17(1)(d) stützen, und liegt dafür ein Vertrag vor?
  • Trennen wir ausgenommene und erfasste Datenbestände technisch, oder behandeln wir das Zentrum vorsorglich insgesamt als erfasst?
  • Wer ist in den einzelnen Verarbeitungen Data Fiduciary, die Zentrale, der Kunde oder das Zentrum selbst?
  • Lassen wir die Grenzfälle, insbesondere Zweigniederlassung und gemischte Datenbestände, vor Stufe (c) lokal klären?

Praktische Empfehlungen

  • Den Anwendungsbereich je Verarbeitung dokumentieren, mit Tatbestand (s. 3(a) oder (b)), geprüfter Ausnahme und Begründung.
  • Für s. 17(1)(d) jede der drei Voraussetzungen einzeln belegen: Aufenthalt der betroffenen Personen, Vertrag, Vertragsparteien.
  • Das Sicherheitsprogramm des Zentrums unabhängig von der Ausnahme führen und an Rule 6 ausrichten.
  • Konzerninterne Leistungsbeziehungen mit Indien schriftlich regeln und die Vertragspartei in Indien eindeutig benennen.
  • Digitale Angebote an Kunden in Indien in die Betroffenheitsanalyse aufnehmen, auch ohne indische Gesellschaft.
  • Für Grenzfälle indische Rechtsberatung einholen; ein Verfahren zur verbindlichen Vorabauskunft über die Anwendbarkeit sieht der Act nicht vor.

Relevante Normreferenzen

  • DPDP Act, 2023 (No. 22 of 2023): s. 2(i), (k), (n), (s), (t), (x) (Data Fiduciary, Data Processor, digitale personenbezogene Daten, Person, personenbezogene Daten, Verarbeitung), s. 3 (Anwendungsbereich: (a) Inland, (b) Ausland bei Angebot an Data Principals in Indien, (c) Ausnahmen), s. 8(1) und (5) (Verantwortung, Sicherheitsvorkehrungen), s. 10(2)(a)(ii) (Data Protection Officer in Indien), s. 17(1)(a) bis (f) (Ausnahmen mit derselben Rechtsfolge, insbesondere (d)), s. 17(2) bis (5), s. 33(1) und Schedule Nr. 1 (Geldstrafe bis zu 250 crore Rupien bei erheblichem Verstoß gegen s. 8(5), festgestellt nach Abschluss einer Untersuchung), s. 36, s. 37, s. 38.
  • G.S.R. 843(E) vom 13.11.2025: Inkrafttreten von s. 3 und s. 17 achtzehn Monate nach der Veröffentlichung.
  • DPDP Rules, 2025 (G.S.R. 846(E)): Rule 6 (Mindestinhalt der Sicherheitsvorkehrungen), Rule 8(3) und Rule 15 (Anwendbarkeit im Fall des s. 17(1)(d) offen), Rule 16 mit Second Schedule (Forschung, Archiv, Statistik), First Schedule Part A (Consent Manager als in Indien gegründete Gesellschaft).
  • Nicht im Quellensatz und deshalb nicht ausgewertet: Notifikationen nach s. 17(2)(a), (3) und (5); sektorale indische Vorschriften; Information Technology Act, 2000.
  • Abgrenzung: Ob die DSGVO auf das deutsche Unternehmen anwendbar ist und wie Übermittlungen aus der EU nach Indien zu beurteilen sind, behandelt der dsgvo-Track (dsgvo-005); hier steht nur, wann der DPDP Act gilt. Der lgpd-Track (lgpd-002) behandelt die strukturell vergleichbare Frage für Brasilien, ohne Rechtsaussage für Indien. Innerhalb dieses Tracks: Überblick und Inkraftsetzung in dpdpa-001, Pflichten des Data Fiduciary einschließlich Sicherheitsvorkehrungen in dpdpa-004, Übermittlung aus Indien in dpdpa-006, Board und Sanktionen in dpdpa-007.

Häufige Fragen

Unser indisches Entwicklungszentrum arbeitet nur mit Daten europäischer Kunden. Gilt der DPDP Act dafür?+

Grundsätzlich ja, weil die Verarbeitung in Indien stattfindet (s. 3(a)). Nach s. 17(1)(d) entfallen aber Kapitel II außer s. 8(1) und (5), Kapitel III und s. 16, wenn die Daten Personen betreffen, die sich nicht in Indien befinden, und die Verarbeitung aufgrund eines Vertrags erfolgt, den eine in Indien ansässige Person mit einer Person außerhalb Indiens geschlossen hat. Die Verantwortung nach s. 8(1) und die Sicherheitspflicht nach s. 8(5) bleiben, ebenso Board und Sanktionen. Beides gilt erst achtzehn Monate nach der Veröffentlichung von G.S.R. 843(E) am 13.11.2025.

Was gilt für die Daten der Beschäftigten dieses Zentrums?+

Soweit sich die Beschäftigten in Indien befinden, greift s. 17(1)(d) nicht, denn die Ausnahme setzt Data Principals voraus, die sich nicht in Indien befinden. Maßgeblich ist der Aufenthalt, nicht Staatsangehörigkeit oder Beschäftigtenstatus. Für diese Daten gelten ab Stufe (c) die Pflichten des Act ohne diese Ausnahme.

Brauchen wir für die Ausnahme einen Vertrag, auch innerhalb des Konzerns?+

Die Ausnahme verlangt eine Verarbeitung aufgrund eines Vertrags zwischen einer in Indien ansässigen Person und einer Person außerhalb Indiens. Konzerninterne Verträge schließt der Wortlaut nicht aus. Ohne Vertrag fehlt eine Voraussetzung.

Reicht eine indische Zweigniederlassung statt einer Tochter?+

Das regelt die Quelle nicht. Die Ausnahme setzt zwei Vertragsparteien voraus, und "based in India" ist nicht definiert. Ob eine unselbständige Zweigniederlassung genügt, sollte indische Rechtsberatung klären.

Wir haben keine Gesellschaft in Indien, verkaufen aber online an indische Kunden. Sind wir erfasst?+

Möglich. s. 3(b) erfasst Verarbeitungen außerhalb Indiens, wenn sie mit dem Angebot von Waren oder Dienstleistungen an Data Principals in Indien zusammenhängen; eine Niederlassung verlangt der Act dafür nicht. Das gilt ab Stufe (c).

Fallen öffentlich zugängliche Daten aus dem Internet heraus?+

Nur, wenn die betroffene Person sie selbst öffentlich gemacht oder die Veröffentlichung veranlasst hat oder wenn eine andere Person, die nach in Indien geltendem Recht zur Veröffentlichung verpflichtet ist, sie öffentlich gemacht oder die Veröffentlichung veranlasst hat (s. 3(c)(ii)). Hat weder die betroffene Person noch eine gesetzlich zur Veröffentlichung verpflichtete Person die Veröffentlichung vorgenommen oder veranlasst, sind die Daten nicht ausgenommen.

Müssen wir eine Datenpanne im ausgenommenen Teil an das Board melden?+

Nach dem DPDP Act nicht, denn s. 8(6) gehört zu den Vorschriften, die im Fall des s. 17(1)(d) nicht gelten; die Sicherheitspflicht nach s. 8(5) bleibt. Ob andere indische Vorschriften eine Meldung verlangen, ist nicht Gegenstand dieses Tracks.

Brauchen wir als ausländisches Unternehmen einen Vertreter in Indien?+

Eine allgemeine Vertreterpflicht enthält der Act nicht. In Indien ansässig sein muss der Data Protection Officer, wenn die Zentralregierung ein Unternehmen als Significant Data Fiduciary notifiziert hat (s. 10(2)(a)(ii)), ab Stufe (c) und nur, soweit s. 10 auf die Verarbeitung anwendbar ist. Für den nach s. 17(1)(d) ausgenommenen Teil gilt s. 10 nicht.

Vom Wissen zur Umsetzung

Sie wissen jetzt, was gefordert ist. Erfüllt ist es erst, wenn jemand es umsetzt und nachweist. Ohne eigenen CISO übernimmt das ein externer CISO (vCISO), ab 3.600 €/Monat; er arbeitet mit OdySecure.

Erstgespräch vereinbaren

Mit eigenem Team: OdySecure ansehen

Standort bestimmen Fünf Stationen von der ersten Einordnung bis zum Audit, der Einstieg ist kostenlos.

Teil der Cybervize-Wissensbasis, Stand 14. Oktober 2026. Eigene Fachredaktion, KI ausschließlich zur redaktionellen Unterstützung. Referenz: dpdpa-002.