DPDP Act Indien: Pflichten des Data Fiduciary, Significant Data Fiduciary sowie Rechte und Pflichten der Data Principals

Problem in der Praxis

Drei Konstellationen erzeugen bei deutschen Unternehmen die meisten Fehleinschätzungen.

Die erste ist der Vertragsreflex: Wer gewohnt ist, Verantwortung über Verträge zu verteilen, erwartet, dass ein indischer Dienstleister mit einem guten Vertrag die Pflichten übernimmt. s. 8(1) schließt das für den Data Fiduciary ausdrücklich aus. Der Vertrag mit dem Data Processor ist Pflicht (s. 8(2)), entlastet aber nicht.

Die zweite ist die Lösch- und Aufbewahrungslogik: Viele Löschkonzepte arbeiten mit "so kurz wie möglich". Die DPDP Rules verlangen daneben ausdrücklich eine Mindestaufbewahrung von einem Jahr für personenbezogene Daten, Verkehrsdaten und Verarbeitungsprotokolle (Rule 8(3)) und für sicherheitsbezogene Protokolle (Rule 6(1)(e)). Die amtliche Illustration zu Rule 8 macht deutlich, dass das auch gilt, wenn die Person ihr Konto gelöscht hat, und dass der Data Fiduciary auch seinen Cloud-Dienstleister zur einjährigen Aufbewahrung anhalten muss. Wer nur die Löschpflicht implementiert, verletzt die Aufbewahrungspflicht und umgekehrt.

Die dritte ist das Rechtemodell: Wer ein konzernweites Verfahren für Betroffenenanfragen nach Indien überträgt, übersieht leicht, dass Auskunft und Berichtigung nach dem Wortlaut an eine Einwilligung einschließlich s. 7(a) gebunden sind, dass eine Beschwerdefrist von höchstens neunzig Tagen veröffentlicht werden muss und dass die Person ihre Rechte für den Todes- oder Handlungsunfähigkeitsfall auf eine andere Person übertragen kann.

CISO-Einordnung

Gesamtverantwortung und Data Processor. Nach s. 8(1) ist der Data Fiduciary für die Einhaltung des Gesetzes und der Rules bei jeder Verarbeitung verantwortlich, die er selbst oder ein Data Processor in seinem Auftrag vornimmt, und zwar ungeachtet einer gegenteiligen Vereinbarung und auch dann, wenn die Data Principal ihre eigenen Pflichten nicht erfüllt. Data Processors darf er für Tätigkeiten im Zusammenhang mit dem Angebot von Waren oder Dienstleistungen an Data Principals nur auf Grundlage eines gültigen Vertrags einsetzen (s. 8(2)). Einen Mindestinhalt dieses Vertrags legt der Quellensatz nur an einer Stelle fest: Rule 6(1)(f) verlangt, soweit einschlägig, eine angemessene Regelung zu angemessenen Sicherheitsvorkehrungen. Die Pflichten in s. 8 sind nach dem Wortlaut an den Data Fiduciary adressiert; den Data Processor erfassen sie über Vertrag und über die Pflicht des Data Fiduciary, ihn zur Einstellung oder Löschung zu veranlassen.

Für Konzerne ist die Rollenfrage vorgelagert: Ob die deutsche Muttergesellschaft, die indische Tochter oder beide Data Fiduciary sind, und wann die indische Einheit nur im Auftrag ausländischer Auftraggeber Daten von Personen außerhalb des indischen Staatsgebiets verarbeitet, behandelt dpdpa-002. Für diesen Outsourcing-Fall nach s. 17(1)(d), also die Verarbeitung von Daten von Personen, die sich nicht im indischen Staatsgebiet befinden ("not within the territory of India"), durch eine in Indien ansässige ("based in India") Person aufgrund eines Vertrags mit einer Person außerhalb Indiens, gelten Kapitel II mit Ausnahme von s. 8(1) und (5), Kapitel III und s. 16 nicht; Gesamtverantwortung und Sicherheitsvorkehrungen bleiben also auch dort Pflicht, die übrigen Pflichten dieses Artikels einschließlich Kontaktstelle, Beschwerdemechanismus, Löschung und Betroffenenrechten dagegen nicht. Ob die Mindestaufbewahrung nach Rule 8(3), die keinem einzelnen Abschnitt des Gesetzes zugeordnet ist, in diesen Fällen gilt, regelt die Quelle nicht ausdrücklich; Rule 6 konkretisiert s. 8(5) und bleibt damit einschlägig.

Richtigkeit und Maßnahmen. Werden Daten voraussichtlich für eine Entscheidung genutzt, die die Data Principal betrifft, oder an einen anderen Data Fiduciary weitergegeben, muss der verarbeitende Data Fiduciary ihre Vollständigkeit, Richtigkeit und Konsistenz sicherstellen (s. 8(3)). Allgemein hat er angemessene technische und organisatorische Maßnahmen zu treffen, um die wirksame Einhaltung des Gesetzes und der Rules sicherzustellen (s. 8(4)).

Sicherheitsvorkehrungen nach s. 8(5) und Rule 6. Der Data Fiduciary muss die Daten in seinem Besitz oder unter seiner Kontrolle, einschließlich der Verarbeitung durch Data Processors, durch angemessene Sicherheitsvorkehrungen vor einer Datenschutzverletzung (personal data breach) schützen. Rule 6 nennt dafür einen Mindestumfang. Für die CISO-Praxis am folgenreichsten sind daraus drei Punkte: Schutz der Daten selbst, etwa durch Verschlüsselung oder Tokenisierung; Protokollierung, Überwachung und Auswertung der Zugriffe, damit unbefugte Zugriffe erkannt, untersucht und künftig verhindert werden; und die Aufbewahrung der dafür nötigen Protokolle und personenbezogenen Daten für ein Jahr, soweit kein geltendes Gesetz anderes verlangt. Die übrigen Punkte, darunter Zugriffskontrolle, Fortführung der Verarbeitung und die Vertragsregelung mit dem Data Processor, stehen vollständig in Rule 6(1) und sind dort nachzulesen. Die Mindestliste ist kein abschließender Katalog und ersetzt kein Sicherheitsmanagement. Einen bestimmten Standard oder eine Zertifizierung schreiben s. 8(5) und Rule 6 nicht vor.

Die Anlage zu s. 33(1) nennt für einen Verstoß gegen die Pflicht aus s. 8(5) eine Strafe, die sich auf bis zu zweihundertfünfzig crore Rupien erstrecken kann; das ist der höchste Einzelbetrag der Anlage. Verfahren und Bemessung behandelt dpdpa-007. Die Meldung einer Datenschutzverletzung an das Board und an jede betroffene Person nach s. 8(6) und Rule 7 behandelt dpdpa-005.

Löschung, Inaktivität und Mindestaufbewahrung. Nach s. 8(7) muss der Data Fiduciary, soweit nicht die Aufbewahrung zur Einhaltung eines geltenden Gesetzes erforderlich ist, die Daten löschen, sobald die Person ihre Einwilligung widerruft oder sobald vernünftigerweise anzunehmen ist, dass der bestimmte Zweck nicht mehr erfüllt wird, je nachdem, was früher eintritt, und seinen Data Processor veranlassen, die ihm überlassenen Daten zu löschen. Die amtliche Illustration nennt eine Bank, die Identitätsdaten wegen einer bankrechtlichen Pflicht nach Kontoschließung weiter aufbewahrt.

Nach s. 8(8) gilt der Zweck als nicht mehr erfüllt, wenn die Person den Data Fiduciary für einen vorgeschriebenen Zeitraum weder zur Zweckerfüllung kontaktiert noch ihre Rechte ausübt; s. 8(11) stellt klar, dass "nicht kontaktiert" jede Zeit meint, in der sie keinen Kontakt aufgenommen hat, persönlich oder durch elektronische oder physische Kommunikation. Den Zeitraum legt Rule 8 mit der Dritten Anlage fest, aber nur für drei Klassen: E-Commerce-Anbieter mit mindestens zwei crore registrierten Nutzern in Indien, Online-Gaming-Intermediäre mit mindestens fünfzig lakh registrierten Nutzern in Indien und Social-Media-Intermediäre mit mindestens zwei crore registrierten Nutzern in Indien. Für sie gilt, sofern nicht ein Gesetz die Aufbewahrung verlangt, eine Frist von drei Jahren ab dem letzten Kontakt oder der letzten Rechteausübung oder ab dem Inkrafttreten der DPDP Rules, je nachdem, was später liegt; ausgenommen sind der Zugang zum Nutzerkonto und zu virtuellen Tokens, die vom Data Fiduciary oder in seinem Namen ausgegeben, auf seiner Plattform gespeichert und für Geld, Waren oder Dienstleistungen nutzbar sind. Die Anlage spricht vom "commencement" der DPDP Rules, 2025; welches der gestaffelten Inkrafttretensdaten der Rules damit gemeint ist, regelt die Quelle nicht ausdrücklich. Mindestens achtundvierzig Stunden vor Ablauf muss der Data Fiduciary die Person informieren, dass gelöscht wird, sofern sie sich nicht anmeldet, Kontakt aufnimmt oder ihre Rechte ausübt (Rule 8(2)). Für alle anderen Data Fiduciaries nennt der Quellensatz keinen festen Zeitraum; für sie bleibt es bei der allgemeinen Regel des s. 8(7).

Daneben steht Rule 8(3), unbeschadet der Absätze 1 und 2: Personenbezogene Daten, zugehörige Verkehrsdaten und andere Verarbeitungsprotokolle sind für jede Verarbeitung durch den Data Fiduciary oder seinen Data Processor mindestens ein Jahr ab der Verarbeitung für die Zwecke der Siebten Anlage aufzubewahren und danach zu löschen, sofern nicht ein anderes Gesetz oder eine Notifikation der Regierung eine längere Aufbewahrung verlangt. Die Siebte Anlage nennt Verwendungen durch den Staat und die Bewertung für die Notifizierung als SDF. Die amtlichen Illustrationen zeigen die Folge: Eine E-Book-Plattform bewahrt Bestell-, Zahlungs- und Lieferdaten mindestens ein Jahr auf, auch wenn die Person ihr Konto löscht, und ein Unternehmen muss sicherstellen, dass sein Cloud-Dienstleister Daten und Protokolle ebenfalls mindestens ein Jahr aufbewahrt, sofern kein anderes Gesetz eine längere Frist verlangt.

Kontaktstelle und Beschwerdemechanismus. Jeder Data Fiduciary muss die geschäftlichen Kontaktdaten eines Data Protection Officer, soweit vorhanden, oder einer Person veröffentlichen, die Fragen der Data Principal zur Verarbeitung in seinem Namen beantworten kann (s. 8(9)). Rule 9 verlangt, diese Angaben an prominenter Stelle auf Website oder App zu veröffentlichen und in jeder Antwort auf eine Anfrage zur Rechteausübung zu nennen. Einen Data Protection Officer im Sinne des Gesetzes bestellt nach s. 2(l) und s. 10(2)(a) nur der SDF; für alle übrigen genügt nach dem Wortlaut eine auskunftsfähige Kontaktperson. Außerdem muss jeder Data Fiduciary einen wirksamen Mechanismus zur Beschwerdebearbeitung einrichten (s. 8(10)).

Significant Data Fiduciary. Die Zentralregierung kann einen Data Fiduciary oder eine Klasse von Data Fiduciaries nach einer Bewertung relevanter Faktoren als SDF notifizieren; das Gesetz nennt unter anderem Umfang und Sensibilität der Daten, das Risiko für die Rechte der Data Principals, mögliche Auswirkungen auf Souveränität und Integrität Indiens, das Risiko für die Wahldemokratie, die Sicherheit des Staates und die öffentliche Ordnung (s. 10(1)). Schwellenwerte nennt der Quellensatz nicht. Ein SDF muss einen Data Protection Officer bestellen, der ihn vertritt, in Indien ansässig ist, dem Vorstand oder einem vergleichbaren Leitungsorgan verantwortlich ist und Ansprechpartner für den Beschwerdemechanismus ist; er muss einen unabhängigen Datenauditor bestellen, der die Einhaltung des Gesetzes bewertet, und periodisch eine Datenschutz-Folgenabschätzung (Data Protection Impact Assessment) und ein Audit durchführen sowie weitere vorgeschriebene Maßnahmen treffen (s. 10(2)).

Rule 13 konkretisiert das: Folgenabschätzung und Audit sind einmal in jedem Zwölfmonatszeitraum ab der Notifizierung oder der Aufnahme in die notifizierte Klasse durchzuführen, und der SDF muss veranlassen, dass die Durchführenden dem Board einen Bericht mit den wesentlichen Feststellungen vorlegen. Der SDF muss mit gebotener Sorgfalt prüfen, dass seine technischen Maßnahmen einschließlich algorithmischer Software für Hosting, Anzeige, Hochladen, Veränderung, Veröffentlichung, Übermittlung, Speicherung, Aktualisierung oder Weitergabe der Daten voraussichtlich kein Risiko für die Rechte der Data Principals darstellen. Und er muss sicherstellen, dass von der Zentralregierung auf Empfehlung eines Ausschusses bestimmte personenbezogene Daten samt der Verkehrsdaten zu ihrem Fluss Indien nicht verlassen; diese Lokalisierungsfolge behandelt dpdpa-006. Eine SDF-Notifikation und eine Festlegung nach Rule 13(4) liegen im Quellensatz nicht vor; ob es sie gibt, ist nicht gemessen. Für einen Verstoß gegen die Pflichten aus s. 10 nennt die Anlage zu s. 33(1) eine Strafe, die sich auf bis zu hundertfünfzig crore Rupien erstrecken kann.

Rechte der Data Principals. Das Auskunftsrecht nach s. 11 richtet sich gegen den Data Fiduciary, dem die Person zuvor eine Einwilligung gegeben hat, einschließlich des Falls von s. 7(a). Sie kann eine Zusammenfassung der verarbeiteten Daten und der Verarbeitungstätigkeiten verlangen, die Identität aller anderen Data Fiduciaries und Data Processors, an die die Daten weitergegeben wurden, mit einer Beschreibung der weitergegebenen Daten, und weitere vorgeschriebene Informationen. Die Angaben zu Empfängern und weiteren Informationen entfallen bei Weitergaben an einen gesetzlich befugten Data Fiduciary auf dessen schriftliche Anfrage zur Verhütung, Aufdeckung oder Untersuchung von Straftaten oder Cybervorfällen oder zur Strafverfolgung (s. 11(2)).

Das Recht auf Berichtigung, Vervollständigung, Aktualisierung und Löschung nach s. 12 knüpft ebenfalls an eine zuvor gegebene Einwilligung einschließlich s. 7(a) an und besteht nach Maßgabe etwaiger Anforderungen oder Verfahren anderer geltender Gesetze. Auf Antrag muss der Data Fiduciary unrichtige oder irreführende Daten berichtigen, unvollständige vervollständigen und Daten aktualisieren (s. 12(2)); auf einen Löschantrag muss er löschen, sofern die Aufbewahrung nicht für den bestimmten Zweck oder zur Einhaltung eines geltenden Gesetzes erforderlich ist (s. 12(3)). Für Verarbeitungen, die auf anderen legitimate uses als s. 7(a) beruhen, etwa auf Beschäftigungszwecken nach s. 7(i), sieht der Wortlaut von s. 11 und s. 12 diese Rechte nicht vor; welche Folgen das im Einzelfall hat, regelt die Quelle nicht weiter.

Rule 14 regelt die Ausübung: Data Fiduciary und, soweit einschlägig, Consent Manager müssen an prominenter Stelle veröffentlichen, auf welchem Weg Anträge gestellt werden können und welche Angaben, etwa ein Nutzername oder eine Kundennummer, zur Identifizierung nach ihren Nutzungsbedingungen nötig sind; die Person stellt den Antrag an den Data Fiduciary, dem sie zuvor eine Einwilligung gegeben hat. Eine eigene Antwortfrist für Auskunfts-, Berichtigungs- oder Löschanträge nennt der Quellensatz nicht.

Beschwerde, Ausschöpfung und Frist. Nach s. 13 hat die Person Anspruch auf leicht zugängliche Mittel der Beschwerde beim Data Fiduciary oder Consent Manager wegen jeder Handlung oder Unterlassung bei deren Pflichten oder bei der Ausübung ihrer Rechte. Der Data Fiduciary oder Consent Manager muss innerhalb einer vorgeschriebenen Frist ab Eingang antworten (s. 13(2)), und die Person muss diese Möglichkeit ausschöpfen, bevor sie sich an das Board wendet (s. 13(3)). Rule 14(3) verlangt von jedem Data Fiduciary und Consent Manager, im Rahmen seines Beschwerdesystems eine angemessene Antwortfrist von höchstens neunzig Tagen an prominenter Stelle zu veröffentlichen und durch geeignete technische und organisatorische Maßnahmen sicherzustellen, dass innerhalb dieser Frist geantwortet wird. Der Wortlaut von Rule 14(3) ist grammatisch unvollständig; die Neunzig-Tage-Obergrenze für die Beschwerdeantwort ergibt sich aus ihm zusammen mit s. 40(2)(o), was genau zu veröffentlichen ist, nur sinngemäß.

Benennung für Tod und Handlungsunfähigkeit. Die Person kann eine andere natürliche Person benennen, die im Fall ihres Todes oder ihrer Handlungsunfähigkeit ihre Rechte ausübt (s. 14); Handlungsunfähigkeit meint die Unfähigkeit zur Rechteausübung wegen geistiger Störung oder körperlicher Gebrechlichkeit. Nach Rule 14(4) kann sie nach den Nutzungsbedingungen des Data Fiduciary und dem anwendbaren Recht eine oder mehrere Personen benennen, auf dem Weg und mit den Angaben, die der Data Fiduciary dafür verlangt. Unternehmen brauchen also einen Prozess für die Entgegennahme von Benennungen und für die spätere Legitimationsprüfung.

Pflichten der Data Principals. s. 15 verpflichtet die Person, bei der Rechteausübung geltendes Recht einzuhalten, sich nicht als jemand anderes auszugeben, bei staatlich ausgestellten Dokumenten, Kennungen und Nachweisen keine wesentlichen Informationen zu unterdrücken, keine falschen oder leichtfertigen Beschwerden einzureichen und bei Berichtigung oder Löschung nur überprüfbar echte Angaben zu machen. Die Anlage zu s. 33(1) sieht dafür eine Strafe vor, die sich auf bis zu zehntausend Rupien erstrecken kann. Für den Data Fiduciary ist s. 15 keine Entlastung: Nach s. 8(1) bleibt er verantwortlich, auch wenn die Person ihre Pflichten nicht erfüllt.

Ausnahmen, nur als Hinweis. Die Zentralregierung kann nach s. 17(3) bestimmte Data Fiduciaries oder Klassen, einschließlich Startups, mit Blick auf Umfang und Art der Daten von s. 5, s. 8(3) und (7), s. 10 und s. 11 freistellen; für den Staat gelten Sonderregeln nach s. 17(4). Eine Notifikation nach s. 17(3) liegt im Quellensatz nicht vor. Den Anwendungsbereich der Ausnahmen behandelt dpdpa-002.

Geltungsbeginn. s. 8, 10 bis 15 gelten nach G.S.R. 843(E) achtzehn Monate nach der Veröffentlichung vom 13.11.2025, Rules 6, 8, 9, 13 und 14 nach Rule 1(4) ebenfalls achtzehn Monate danach. Am Stand dieses Artikels (10.10.2026) gelten sie noch nicht. Ein Tagesdatum nennen die Quellen nicht.

Umsetzungsperspektive

1. Rollen festlegen, bevor Verträge geschrieben werden. Für jede Verarbeitung mit Indienbezug bestimmen, wer Data Fiduciary und wer Data Processor ist, und den Outsourcing-Fall nach s. 17(1)(d) gesondert prüfen.
2. Verträge mit Data Processors nachziehen. Gesetzlich verlangt ist ein gültiger Vertrag für den Einsatz von Data Processors bei Tätigkeiten im Zusammenhang mit dem Angebot von Waren oder Dienstleistungen an Data Principals (s. 8(2)); ihn als eigene organisatorische Praxis auf jede Auftragsverarbeitung zu erstrecken, ist eine Empfehlung, keine Vorgabe des Quellensatzes. Inhalt: Sicherheitsregelung nach Rule 6(1)(f), soweit einschlägig; Einstellung der Verarbeitung nach einem Widerruf innerhalb angemessener Zeit auf Veranlassung des Data Fiduciary, außer die Verarbeitung ohne Einwilligung ist nach dem Gesetz, den Rules oder anderem in Indien geltendem Recht vorgeschrieben oder zugelassen (s. 6(6)); Löschung auf Veranlassung nach s. 8(7)(b), vorbehaltlich gesetzlicher Aufbewahrung; einjährige Aufbewahrung nach Rule 8(3).
3. Rule 6 gegen das bestehende ISMS abgleichen. Verschlüsselung oder Tokenisierung, Zugriffskontrolle, Protokollierung mit Auswertung, Datensicherung und einjährige Protokollaufbewahrung je System nachweisen.
4. Löschkonzept um die Mindestaufbewahrung erweitern. Löschung nach Zweckende und Widerruf und einjährige Aufbewahrung nach Rule 8(3) und Rule 6(1)(e) gemeinsam modellieren; gesetzliche Aufbewahrungspflichten Indiens gesondert erheben.
5. Bei großen Plattformen die Dritte Anlage prüfen. Nutzerzahlen in Indien gegen die drei Klassen halten, Inaktivitätsfrist und Achtundvierzig-Stunden-Hinweis einplanen.
6. Kontaktstelle und Beschwerdeweg veröffentlichen. Kontaktdaten nach Rule 9 auf Website oder App und in jeder Antwort, Beschwerdesystem mit veröffentlichter Frist von höchstens neunzig Tagen.
7. Rechteprozess aufsetzen. Antragswege und Identifizierungsangaben nach Rule 14 veröffentlichen, Empfängerliste für Auskünfte pflegen, Benennungen nach s. 14 entgegennehmen.
8. SDF-Lage beobachten. Eigene Verarbeitungen gegen die Faktoren des s. 10(1) einordnen und Notifikationen verfolgen; für den Fall einer Notifizierung DPO in Indien, Auditor, jährliche Folgenabschätzung und Audit vorbereiten.

Typische Fehler

1. Die Verantwortung wird per Vertrag auf den indischen Dienstleister verlagert, obwohl s. 8(1) das ausschließt.
2. Ein Data Processor wird für Tätigkeiten im Zusammenhang mit dem Angebot von Waren oder Dienstleistungen ohne gültigen Vertrag oder ohne Sicherheitsregelung eingesetzt.
3. Löschung wird ohne die einjährige Mindestaufbewahrung nach Rule 8(3) und Rule 6(1)(e) umgesetzt, oder umgekehrt.
4. Die Dreijahresfrist der Dritten Anlage wird auf alle Data Fiduciaries übertragen, obwohl sie nur für drei Klassen großer Plattformen gilt.
5. Die Kontaktdaten stehen nur in der Datenschutzerklärung und nicht in jeder Antwort auf eine Rechteanfrage.
6. Ein "Data Protection Officer" wird nach fremdem Recht benannt und als SDF-DPO verstanden, obwohl der Gesetzesbegriff nur den SDF betrifft und dort einen Sitz in Indien verlangt.
7. Es wird keine Beschwerdefrist veröffentlicht oder eine Frist über neunzig Tagen angesetzt.
8. Die Empfängerangaben für Auskünfte nach s. 11(1)(b) sind nicht vorhanden, weil Weitergaben an Dienstleister nicht dokumentiert werden.
9. Das Benennungsrecht nach s. 14 ist nicht vorgesehen.

Risiken und Trade-offs

Der zentrale Zielkonflikt liegt zwischen Löschung und Aufbewahrung. Die Löschpflicht nach s. 8(7) und die Mindestaufbewahrung nach Rule 8(3) verlangen eine präzise Trennung von Zweckdaten und Protokolldaten; wer pauschal ein Jahr länger aufbewahrt, hält mehr als nötig vor, wer pauschal früher löscht, verletzt die Rules. Der Aufwand liegt in der Datenmodellierung, nicht im Löschjob.

Bei Data Processors steht Kontrolltiefe gegen Kosten. Weil s. 8(1) die Verantwortung beim Data Fiduciary hält, ist eine nur vertragliche Absicherung billig, aber im Ernstfall wertlos; Audits und technische Nachweise sind teurer, aber die einzige Absicherung, die das Risiko tatsächlich senkt.

Bei der SDF-Frage steht Vorbereitung gegen Ungewissheit. Ohne Notifikation ist nicht bekannt, wen sie trifft; wer früh einen DPO in Indien, einen Auditor und eine Folgenabschätzung einplant, investiert womöglich umsonst, wer wartet, hat nach einer Notifikation wenig Zeit, da Rule 13 den Zwölfmonatszeitraum ab der Notifizierung laufen lässt.

Entscheidungspunkte

• Welche Einheit ist für welche Verarbeitung Data Fiduciary, und welche indischen Dienstleister sind Data Processors?
• Wie modellieren wir Löschung nach Zweckende und die einjährige Mindestaufbewahrung gemeinsam, und wer verantwortet das?
• Fallen wir mit einer Plattform unter eine Klasse der Dritten Anlage?
• Welche Beschwerdefrist veröffentlichen wir, und können wir sie mit den vorhandenen Ressourcen einhalten?
• Bereiten wir uns auf eine mögliche SDF-Notifizierung vor, und wer wäre DPO in Indien?
• Wie gehen wir mit Rechteanfragen zu Verarbeitungen um, die nicht auf Einwilligung oder s. 7(a) beruhen?

Praktische Empfehlungen

• Ein Verzeichnis aller Data Processors mit Vertragsstatus, Sicherheitsregelung und Lösch- und Aufbewahrungsklauseln für Indien führen.
• Rule 6 als Prüfraster im ISMS hinterlegen und je System nachweisen, ohne sie als abschließende Liste zu behandeln.
• Aufbewahrungs- und Löschregeln je Datenkategorie dokumentieren, mit Rechtsgrund für jede Abweichung von der Löschung.
• Kontaktdaten, Antragswege, Identifizierungsangaben und Beschwerdefrist an einer prominenten Stelle von Website oder App bündeln und in Antwortvorlagen einbauen.
• Empfänger der Daten laufend dokumentieren, damit die Auskunft nach s. 11 vollständig möglich ist.
• Notifikationen nach s. 10 und s. 17(3) beobachten und bei Bekanntwerden neu bewerten.
• Für Fragen zu indischen Aufbewahrungspflichten und zur Einordnung als SDF indische Rechtsberatung einholen.

Relevante Normreferenzen

• DPDP Act (Act No. 22 of 2023): s. 2(i), (k), (l), (z) (Data Fiduciary, Data Processor, Data Protection Officer, Significant Data Fiduciary), s. 8(1) bis (5) und (7) bis (11) (Pflichten des Data Fiduciary), s. 8(6) nur verwiesen, s. 10 (Significant Data Fiduciary), s. 11 (Auskunft), s. 12 (Berichtigung und Löschung), s. 13 (Beschwerde), s. 14 (Benennung), s. 15 (Pflichten der Data Principal), s. 17(1)(d), (3), (4) nur als Hinweis, s. 40(2)(o) (Ermächtigung zur Beschwerdefrist), Anlage zu s. 33(1) (Strafrahmen, Orientierung).
• DPDP Rules, 2025 (G.S.R. 846(E)): Rule 1 (Inkrafttreten), Rule 2(1)(c) (Nutzerkonto), Rule 6 (Sicherheitsvorkehrungen), Rule 8 mit Dritter und Siebter Anlage (Inaktivitätsfrist, Mindestaufbewahrung), Rule 9 (Kontaktdaten), Rule 13 (SDF), Rule 14 (Rechteausübung, Beschwerdefrist, Benennung); Rule 7 nur verwiesen.
• G.S.R. 843(E) vom 13.11.2025 (Inkraftsetzung des Gesetzes in drei Stufen).
• Nicht im Quellensatz und deshalb nicht ausgewertet: Notifikationen nach s. 10 und s. 17(3), Festlegungen nach Rule 13(4), Information Technology Act, 2000 (Begriff computer resource in Rule 6), Consumer Protection Act, 2019 und Intermediary Rules, 2021 (Begriffe der Dritten Anlage), sektorale indische Aufbewahrungspflichten.
• Abgrenzung: Sicherheit der Verarbeitung, Datenschutz-Folgenabschätzung und Auftragsverarbeitung nach DSGVO für das deutsche Unternehmen im dsgvo-Track (dsgvo-002, dsgvo-004, dsgvo-005), hier steht ausschließlich die indische Seite; Rollen im Konzern und Ausnahmen in dpdpa-002; Einwilligung, Notice und Kinder in dpdpa-003; Datenpannenmeldung in dpdpa-005; Datenlokalisierung in dpdpa-006; Strafen und Verfahren in dpdpa-007. Der lgpd-Track ist ein strukturell vergleichbarer Auslandstrack und dient nur als Querverweis, nicht als Auslegungshilfe.