Datenpannen nach dem indischen DPDP Act: jede Panne an jede betroffene Person und an das Board, in zwei Stufen und ohne Risikoschwelle

Problem in der Praxis

Viele Incident-Response-Prozesse deutscher Konzerne entscheiden über eine Meldung anhand einer Risikobewertung; welche Schwellen dort aus EU-Sicht gelten, beurteilt sich nach dsgvo-003. Für Indien trägt ein solcher Filter nicht: Der DPDP Act kennt keinen Filter, der kleine oder risikoarme Pannen von der Meldung ausnimmt. Wer seinen Konzernprozess unverändert auf die indische Einheit überträgt, wird Pannen, die nach eigenem Raster "nicht meldepflichtig" sind, in Indien nicht melden und damit gegen s. 8(6) verstoßen.

Hinzu kommt die doppelte Adressierung. Die Benachrichtigung der Betroffenen ist kein Folgeschritt nach der Behördenmeldung, sondern eine eigenständige Pflicht mit eigenem Mindestinhalt, und der ausführliche Bericht an das Board muss ausdrücklich einen Bericht über die erfolgten Benachrichtigungen enthalten. Beide Mitteilungen sind ohne Verzögerung fällig; eine Reihenfolge oder Gleichzeitigkeit schreibt die Quelle nicht vor. Wer die Kundenkommunikation aber bis nach der Board-Meldung zurückstellt, riskiert, die eigenständige Pflicht "ohne Verzögerung" gegenüber den Betroffenen zu verfehlen, und hat im 72-Stunden-Bericht über die Benachrichtigungen entsprechend wenig zu berichten.

Drittens ist der Begriff der Datenpanne weit. Er umfasst nach s. 2(u) DPDP Act jede unbefugte Verarbeitung sowie die versehentliche Offenlegung, Erlangung, Weitergabe, Nutzung, Veränderung, Vernichtung oder den Verlust des Zugriffs auf personenbezogene Daten, wenn dadurch Vertraulichkeit, Integrität oder Verfügbarkeit beeinträchtigt werden. Ein Ransomware-Vorfall, der Daten nur unzugänglich macht, ist damit ebenso erfasst wie ein fehlgeleiteter E-Mail-Verteiler.

Schließlich die Konzernfrage: Welche Gesellschaft ist Data Fiduciary, wer erfährt wann von der Panne, und gilt das Gesetz für die betroffene Verarbeitung überhaupt? Bei einem indischen Servicezentrum, das ausschließlich Daten europäischer Kunden im Auftrag der deutschen Mutter verarbeitet, kann die Meldepflicht nach s. 17(1)(d) entfallen, die Sicherheitspflicht aber nicht.

CISO-Einordnung

Was eine Datenpanne ist

Der Begriff nach s. 2(u) DPDP Act hat zwei Varianten: die unbefugte Verarbeitung und eine Reihe versehentlicher Ereignisse (Offenlegung, Erlangung, Weitergabe, Nutzung, Veränderung, Vernichtung, Verlust des Zugriffs). Beide setzen voraus, dass Vertraulichkeit, Integrität oder Verfügbarkeit der Daten beeinträchtigt werden. Weil das Gesetz nach s. 3 nur digitale personenbezogene Daten erfasst (auch nachträglich digitalisierte), betrifft die Meldepflicht Pannen an digitalen Daten. Einen Unterschied zwischen vermuteter und bestätigter Panne macht die Quelle nicht; Rule 7 stellt auf das Kenntniserlangen ab.

Wer meldet

Adressat der Pflicht ist der Data Fiduciary. s. 8(1) stellt klar, dass er unabhängig von abweichenden Vereinbarungen für die Einhaltung des Gesetzes verantwortlich bleibt, auch bei Verarbeitung durch einen Data Processor in seinem Auftrag. Eine Meldepflicht des Data Processor gegenüber dem Data Fiduciary oder dem Board regelt der Quellensatz nicht. Rule 6(1)(f) verlangt eine angemessene Vertragsklausel zu Sicherheitsvorkehrungen zwischen Data Fiduciary und Data Processor; eine ausdrückliche Pflicht, darin eine Meldepflicht des Verarbeiters zu vereinbaren, enthält sie nicht. Der Data Fiduciary braucht diese Klausel trotzdem, weil seine Fristen ab seiner eigenen Kenntnis laufen.

Mitteilung an die Betroffenen (Rule 7(1))

Der Data Fiduciary teilt jeder betroffenen Person nach bestem Wissen, knapp, klar und verständlich und ohne Verzögerung mit, was geschehen ist. Der Kanal ist vorgegeben: das Nutzerkonto (Rule 2(1)(c) versteht darunter auch Profile, Handles, E-Mail-Adresse oder Mobilnummer, über die die Person den Dienst nutzt) oder ein von ihr registrierter Kommunikationsweg. Inhaltlich verlangt Rule 7(1) eine Beschreibung der Panne mit Art, Umfang und Zeitpunkt, die für die Person wahrscheinlichen Folgen, die ergriffenen und laufenden Maßnahmen zur Risikominderung (soweit vorhanden), Schutzmaßnahmen, die die Person selbst ergreifen kann, und die geschäftlichen Kontaktdaten einer Person, die für den Data Fiduciary Rückfragen beantworten kann. Bei Kindern umfasst "Data Principal" nach s. 2(j) auch Eltern oder gesetzliche Vormunde, bei Menschen mit Behinderung den gesetzlichen Vormund, der für sie handelt.

Eine Ausnahme von der Benachrichtigung, etwa bei verschlüsselten Daten oder unverhältnismäßigem Aufwand, sieht der Quellensatz nicht vor. Eine bestimmte Stundenfrist nennt Rule 7(1) ebenfalls nicht; "ohne Verzögerung" ist ein unbestimmter Maßstab, den das Board auslegen wird.

Meldung an das Board (Rule 7(2))

Die Meldung an das Board hat zwei Stufen:

1. Ohne Verzögerung: eine Beschreibung der Panne mit Art, Umfang, Zeitpunkt und Ort des Auftretens sowie den wahrscheinlichen Auswirkungen.
2. Innerhalb von 72 Stunden ab Kenntnis, oder innerhalb einer längeren Frist, die das Board auf schriftlichen Antrag gewähren kann: aktualisierte und ausführliche Angaben zur Beschreibung, die wesentlichen Tatsachen zu Ereignissen, Umständen und Gründen, die zur Panne geführt haben, die umgesetzten oder geplanten Maßnahmen zur Risikominderung (soweit vorhanden), etwaige Erkenntnisse über die Person, die die Panne verursacht hat, Abhilfemaßnahmen gegen eine Wiederholung und ein Bericht über die Benachrichtigungen der Betroffenen.

Die Fristverlängerung ist eine Ermessensentscheidung des Board ("may allow"), kein Anspruch, und sie betrifft nur die zweite Stufe. Die Sofortmeldung bleibt davon unberührt. Ein Formular oder einen Meldekanal schreibt Rule 7 nicht vor, obwohl s. 40(2)(f) die Rules dazu ermächtigt; s. 28(1) und Rule 20 sehen das Board als digitales Büro. Wie die Meldung technisch einzureichen ist, regelt der Quellensatz nicht.

Fristbeginn

Beide Stufen und die Benachrichtigung der Betroffenen beginnen "on becoming aware", also mit der Kenntnis des Data Fiduciary. Wann Wissen einer Konzerngesellschaft, eines Data Processor oder eines externen Dienstleisters dem Data Fiduciary zugerechnet wird, regelt die Quelle nicht. Wer die Frist erst mit der Bestätigung durch die Forensik laufen lässt, trägt das Risiko, dass das Board den Zeitpunkt früher ansetzt.

Wann die Meldepflicht nicht greift

• Außerhalb des Anwendungsbereichs: Das Gesetz gilt nach s. 3(a) für jede Verarbeitung digitaler personenbezogener Daten in Indien (digital erhoben oder nachträglich digitalisiert), ohne dass es auf ein Angebot ankommt; nach s. 3(b) außerdem für Verarbeitung außerhalb Indiens, wenn sie im Zusammenhang mit dem Angebot von Waren oder Dienstleistungen an Data Principals in Indien steht; ausgenommen sind unter anderem rein persönliche Zwecke und bestimmte öffentlich gemachte Daten. Einzelheiten in dpdpa-002.
• s. 17(1): In den dort genannten Fällen gilt Kapitel II mit Ausnahme von s. 8(1) und 8(5) nicht, also auch s. 8(6) nicht. Für deutsche Unternehmen zentral ist s. 17(1)(d): personenbezogene Daten von Data Principals, die sich nicht in Indien befinden, werden von einer in Indien ansässigen Person aufgrund eines Vertrags mit einer Person außerhalb Indiens verarbeitet. Alle drei Voraussetzungen müssen zusammen vorliegen. Die Sicherheitspflicht nach s. 8(5) bleibt bestehen; die Meldepflicht entfällt nur für diese Verarbeitung, nicht für andere Verarbeitungen derselben Gesellschaft. Weitere Fälle des s. 17(1) betreffen unter anderem die Durchsetzung von Rechtsansprüchen und die Verhütung und Verfolgung von Straftaten.
• s. 17(2): Das Gesetz gilt insgesamt nicht für die Verarbeitung durch von der Zentralregierung notifizierte staatliche Stellen in den dort genannten Staatsinteressen und nicht für Verarbeitung zu Forschungs-, Archiv- oder Statistikzwecken, wenn die Daten nicht für eine auf eine bestimmte Person bezogene Entscheidung genutzt werden und die Verarbeitung den vorgeschriebenen Standards folgt (Rule 16 mit Second Schedule; Einzelheiten in dpdpa-002).
• s. 17(3) und 17(5): Die Freistellung bestimmter Data Fiduciaries, einschließlich Startups, nach s. 17(3) umfasst s. 8(6) nicht. Die Zentralregierung kann nach s. 17(5) innerhalb von fünf Jahren ab Inkrafttreten weitere Freistellungen notifizieren; solche Notifikationen liegen dem Quellensatz nicht vor.

Was das Board mit der Meldung tun kann

Nach s. 27(1)(a) DPDP Act kann das Board auf eine Meldung hin dringende Abhilfe- oder Minderungsmaßnahmen anordnen, die Panne untersuchen und eine Strafe verhängen. Die Meldung ist damit zugleich der Auslöser eines möglichen Verfahrens (Einzelheiten zu Verfahren, Strafen und Rechtsmitteln in dpdpa-007). Bei der Strafbemessung berücksichtigt das Board nach s. 33(2)(e) unter anderem, ob und wie rechtzeitig und wirksam Maßnahmen zur Minderung der Folgen ergriffen wurden.

Strafrahmen

Der Schedule zu s. 33(1) DPDP Act sieht für den Verstoß gegen die Pflicht, das Board oder die betroffene Person über eine Panne zu informieren, eine Strafe von bis zu zweihundert crore Rupien vor. Getrennt davon kann der Verstoß gegen die Pflicht zu angemessenen Sicherheitsvorkehrungen nach s. 8(5) mit bis zu zweihundertfünfzig crore Rupien geahndet werden. Eine Strafe setzt nach s. 33(1) voraus, dass das Board nach Abschluss einer Untersuchung einen erheblichen Verstoß feststellt und der Person Gelegenheit zur Anhörung gegeben hat.

Geltungsbeginn

s. 2 (Begriffe) und das Board (s. 18 bis 26) gelten seit der Veröffentlichung von G.S.R. 843(E) am 13.11.2025. s. 8 einschließlich s. 8(6), s. 17, s. 27 (außer s. 27(1)(d)) und s. 33 treten achtzehn Monate nach dieser Veröffentlichung in Kraft, Rule 7 nach Rule 1(4) DPDP Rules ebenfalls achtzehn Monate nach der Veröffentlichung von G.S.R. 846(E) am 13.11.2025. Bis dahin besteht nach dem DPDP Act keine Meldepflicht. Ob anderes indisches Recht bereits jetzt Meldungen verlangt, ist nicht Gegenstand des Quellensatzes; s. 38(1) stellt klar, dass der DPDP Act andere Gesetze ergänzt und nicht verdrängt, im Konfliktfall aber nach s. 38(2) vorgeht.

Umsetzungsperspektive

Die Übergangszeit bis zum Inkrafttreten ist die Zeit, den Prozess zu bauen, nicht die Zeit, ihn zu vergessen. Vier Bausteine sind nötig.

Rollenklärung je Verarbeitung. Für jede indische Verarbeitung ist festzuhalten, wer Data Fiduciary ist, ob die Verarbeitung unter s. 3 fällt und ob s. 17(1)(d) greift. Diese Einordnung ist vor dem Vorfall zu treffen, denn im Vorfall bleibt dafür keine Zeit.

Meldeweg ohne Filter. Der indische Zweig des Incident-Prozesses braucht einen Pfad, auf dem jede Panne mit indischen Data Principals in die Meldung läuft, unabhängig vom Risikoergebnis der Konzernbewertung. Die Risikobewertung bleibt sinnvoll, sie bestimmt aber Inhalt und Maßnahmen, nicht das Ob der Meldung.

Kommunikationsfähigkeit gegenüber Betroffenen. Die Benachrichtigung muss über das Nutzerkonto oder registrierte Kontaktwege laufen. Das setzt voraus, dass diese Kontaktdaten aktuell und für die Incident-Kommunikation nutzbar sind, und dass Textbausteine für die fünf Inhaltspunkte vorbereitet sind, ohne den Einzelfall vorwegzunehmen.

Forensische Grundlage für die 72 Stunden. Der ausführliche Bericht verlangt unter anderem die wesentlichen Tatsachen und Gründe der Panne, etwaige Erkenntnisse zum Verursacher und die Abhilfemaßnahmen gegen eine Wiederholung. Rule 6(1)(c) und 6(1)(e) verlangen Protokollierung und Überwachung zur Erkennung unbefugter Zugriffe und die Aufbewahrung solcher Protokolle für ein Jahr, soweit kein anderes Gesetz Abweichendes verlangt (Einzelheiten in dpdpa-004). Ohne diese Grundlage ist der 72-Stunden-Bericht kaum belastbar zu füllen, und der Antrag auf Fristverlängerung wird zur Regel statt zur Ausnahme.

Für Data Processors in Indien und außerhalb gehört in jeden Vertrag eine kurze Meldefrist an den Data Fiduciary, die Mitwirkung an den Inhalten der beiden Meldestufen und die Unterstützung bei der Benachrichtigung der Betroffenen.

Typische Fehler

1. Eine Risikoschwelle aus dem Konzernprozess übernehmen. Wer nur bei festgestelltem Risiko meldet, verfehlt die indische Pflicht, die an jede Panne anknüpft.
2. Nur das Board informieren. Die Benachrichtigung der Betroffenen ist eine eigene Pflicht und zugleich Inhalt des 72-Stunden-Berichts.
3. Die 72 Stunden als einzige Frist lesen. Die erste Beschreibung an das Board und die Benachrichtigung der Betroffenen sind "ohne Verzögerung" fällig, also nicht erst am Ende der 72 Stunden.
4. Die Fristverlängerung als sicher einplanen. Das Board "kann" eine längere Frist gewähren, auf schriftlichen Antrag und nur für die zweite Stufe.
5. s. 17(1)(d) zu weit lesen. Die Ausnahme verlangt kumulativ Daten von Personen außerhalb Indiens, eine Verarbeitung durch eine in Indien ansässige Person und einen Vertrag mit einer Person außerhalb Indiens. Sobald Daten von Personen in Indien betroffen sind, trägt sie für diese nicht, und die Sicherheitspflicht gilt ohnehin.
6. Verschlüsselung als Befreiung behandeln. Der Quellensatz kennt keine Befreiung für verschlüsselte Daten; Verschlüsselung ist nach Rule 6(1)(a) eine Sicherheitsmaßnahme, kein Meldeausschluss.
7. Den Geltungsbeginn verwechseln. Das Board besteht seit dem 13.11.2025, die Meldepflicht gilt aber erst achtzehn Monate nach diesem Datum.

Risiken und Trade-offs

Die Meldepflicht ohne Schwelle erzeugt Volumen. Jede fehlgeleitete E-Mail mit Kundendaten eines indischen Kunden wird zu einer Meldung an das Board und zu einer Benachrichtigung. Das ist Aufwand, aber kein vermeidbarer: der Quellensatz gibt keinen Raum, auf eine Meldung wegen Geringfügigkeit zu verzichten.

Die frühe Sofortmeldung zwingt zu Aussagen auf unsicherer Grundlage. Wer zu viel meldet, korrigiert sich später im 72-Stunden-Bericht; wer zu wenig meldet, riskiert den Vorwurf der Verzögerung. Die Rule sieht die Aktualisierung in der zweiten Stufe ausdrücklich vor, das spricht für eine knappe, sachliche erste Meldung.

Die Benachrichtigung der Betroffenen erfolgt "nach bestem Wissen". Welche Wirkung dieser Maßstab hat, wenn sich Angaben später als unvollständig erweisen, regelt die Quelle nicht; den jeweiligen Wissensstand zu dokumentieren, ist deshalb eine praktische Empfehlung zur Nachvollziehbarkeit, keine gesetzliche Voraussetzung. Gleichzeitig kann eine frühe Benachrichtigung Ermittlungen oder die Eindämmung gefährden; eine Ausnahme dafür sieht Rule 7 nicht vor.

Im Konzern konkurrieren Geschwindigkeit und Abstimmung. Eine indische Tochter, die als Data Fiduciary selbst meldet, muss das ohne Freigabeschleife über die deutsche Rechtsabteilung können, sonst ist "ohne Verzögerung" nicht zu halten.

Entscheidungspunkte

• Welche Gesellschaft ist für welche indische Verarbeitung Data Fiduciary, und wer meldet für sie?
• Für welche Verarbeitungen indischer Einheiten wird s. 17(1)(d) in Anspruch genommen, und ist das mit allen drei Voraussetzungen dokumentiert?
• Ab welchem Ereignis gilt im Konzern "Kenntnis" als erreicht, und wie wird dieser Zeitpunkt protokolliert?
• Wer darf die Sofortmeldung an das Board ohne weitere Freigabe absenden?
• Welche Kanäle stehen für die Benachrichtigung der Betroffenen bereit, und sind sie für Massenkommunikation erprobt?
• Wann wird eine Verlängerung der 72-Stunden-Frist beantragt, und wer formuliert den Antrag?
• Wie wird eine parallele DSGVO-Meldung abgestimmt (Bewertung aus EU-Sicht nach dsgvo-003)?

Praktische Empfehlungen

1. Den indischen Meldepfad im Incident-Response-Plan als eigenen Zweig führen, der nicht an einer Risikoschwelle des Konzernprozesses hängt.
2. Die beiden Board-Stufen und die Benachrichtigung der Betroffenen in einem gemeinsamen Zeitplan ab dem dokumentierten Kenntniszeitpunkt planen.
3. Vertragsklauseln mit allen Data Processors um kurze Meldefristen und Mitwirkungspflichten ergänzen.
4. Protokollierung und Aufbewahrung so auslegen, dass Umfang, Ursachen und, soweit ermittelt, der Verursacher innerhalb von 72 Stunden belastbar beschrieben werden können.
5. Die Einordnung nach s. 3 und s. 17(1)(d) je Verarbeitung vorab treffen und bei Grenzfällen indische Rechtsberatung einholen.
6. Die Übergangszeit bis achtzehn Monate nach dem 13.11.2025 für eine Übung nutzen, die beide Meldestufen und die Benachrichtigung einmal vollständig durchspielt.
7. Weitere indische Meldepflichten aus sektoralem oder sonstigem Recht gesondert prüfen lassen; dieser Artikel deckt sie nicht ab.

Relevante Normreferenzen

• DPDP Act 2023 (No. 22 of 2023): s. 2(j) (Data Principal einschließlich Eltern und Vormund), s. 2(u) (personal data breach), s. 3 (Anwendungsbereich), s. 8(1) (Verantwortung des Data Fiduciary auch für Data Processor), s. 8(5) (angemessene Sicherheitsvorkehrungen), s. 8(6) (Mitteilung an Board und jede betroffene Person), s. 17(1) bis (3) und (5) (Ausnahmen), s. 27(1)(a) (Befugnisse des Board auf eine Meldung), s. 33 (Strafen, Bemessung), s. 38 (Verhältnis zu anderen Gesetzen), s. 40(2)(f) (Ermächtigung für Form und Verfahren der Meldung), Schedule Nr. 1 und 2.
• DPDP Rules 2025 (G.S.R. 846(E)): Rule 1(4) (Inkrafttreten), Rule 2(1)(c) (Nutzerkonto), Rule 6(1)(a), (c), (e), (f) (Sicherheitsvorkehrungen, soweit für die Meldung relevant), Rule 7 (Mitteilung an Betroffene und an das Board), Rule 16 (Standards für die Ausnahme nach s. 17(2)(b), nur als Verweis), Rule 20 (Board als digitales Büro).
• G.S.R. 843(E) vom 13.11.2025 (Inkraftsetzung in drei Stufen) und G.S.R. 844(E) vom 13.11.2025 (Errichtung des Board mit Wirkung ab Veröffentlichung).
• Nicht im Quellensatz und deshalb nicht ausgewertet: Information Technology Act 2000 und darauf gestützte Vorgaben, sektorale Meldepflichten, Notifikationen nach s. 17(3) und 17(5), Hinweise des Board zum Meldekanal.
• Abgrenzung: Meldung von Datenschutzverletzungen nach Art. 33 und 34 DSGVO durch das deutsche Unternehmen im dsgvo-Track (dsgvo-003); hier steht ausschließlich die indische Seite. Sicherheitsvorkehrungen im Einzelnen in dpdpa-004, Anwendungsbereich und s. 17 in dpdpa-002, Board, Verfahren und Strafen in dpdpa-007. Der lgpd-Track (lgpd-005) behandelt die strukturell vergleichbare brasilianische Meldepflicht; daraus folgt keine Aussage zum indischen Recht.