Wann SaaS-Anbieter einen Datenschutzbeauftragten benennen müssen: Auslöser der Änderung 13 für Technologieunternehmen

Viele SaaS-Anbieter gehen davon aus, dass die Benennung eines DPO (Data Protection Officer) erst ab einer bestimmten Unternehmensgröße verpflichtend ist. Diese Annahme birgt regulatorische Risiken, da bestimmte Verarbeitungstätigkeiten die Pflicht zur DPO-Benennung unabhängig von der Unternehmensgröße auslösen. Die Änderung 13 des israelischen Datenschutzgesetzes schafft verbindliche Pflichten für Technologieunternehmen, die personenbezogene Daten systematisch oder in großem Umfang verarbeiten. Die Folgen reichen dabei über Geldbußen hinaus und können zu betrieblichen Einschränkungen und Reputationsschäden führen.

Um zu verstehen, wann SaaS-Anbieter einen DPO benennen müssen, ist Klarheit über die Verarbeitungskategorien, den organisatorischen Geltungsbereich und die Unterscheidung zwischen Kern- und unterstützenden Funktionen erforderlich. Für Entscheider in Unternehmen stellt sich nicht die Frage, ob irgendwann ein DPO zu benennen ist, sondern ob die aktuelle Verarbeitung bereits die Verpflichtung auslöst. Dieser Artikel erläutert die spezifischen Auslöser der Änderung 13 für SaaS-Anbieter, wie Sie Ihre Verpflichtung bewerten und wie Sie eine belastbare Governance aufbauen, sobald die Pflicht greift.

Executive Summary

Die Änderung 13 des israelischen Datenschutzgesetzes schreibt die Benennung eines DPO für Organisationen vor, deren Kerntätigkeiten groß angelegte, systematische Überwachung oder die Verarbeitung besonderer Kategorien und sensibler Daten umfassen. SaaS-Anbieter erreichen diese Schwellenwerte häufig durch Authentifizierungsprotokollierung, Verhaltensanalysen, Gesundheitsdatenverarbeitung oder HR-Plattformdienste. Der Auslöser ist nicht an Umsatz oder Mitarbeiterzahl gebunden, sondern wird aktiviert, wenn die Verarbeitungsmerkmale die Definitionen der Compliance erfüllen. Technologieführer in Unternehmen müssen ihre Verarbeitungsinventare anhand der Kriterien der Änderung 13 bewerten, Kern- von unterstützenden Tätigkeiten unterscheiden und eine Governance implementieren, die Unabhängigkeit, Fachwissen und Prüfbereitschaft nachweist. Die Nichtbenennung eines DPO bei bestehender Pflicht setzt Unternehmen dem Risiko von Durchsetzungsmaßnahmen, Vertragsverletzungen und Beschaffungsproblemen aus.

Wichtige Erkenntnisse

1. Verpflichtende DPO-Auslöser. Die Änderung 13 des israelischen Datenschutzgesetzes verpflichtet SaaS-Anbieter zur Benennung eines DPO, wenn sie groß angelegte, systematische Überwachung oder Verarbeitung sensibler Daten durchführen – unabhängig von der Unternehmensgröße.
2. Kernaktivitäten weit gefasst. Zu den Kerntätigkeiten, die die DPO-Pflicht auslösen, zählen Sicherheitsüberwachung, Analysen und Funktionen zur Sicherstellung der Dienstintegrität, die für die SaaS-Bereitstellung wesentlich sind – nicht nur kundenorientierte Funktionen.
3. Kumulative Skalierungsbewertung. Die Bewertung der groß angelegten Verarbeitung erfolgt kumulativ über alle Kundentenants hinweg. Auch mittelgroße SaaS-Anbieter können die Schwellenwerte durch aggregierte Datenmengen erreichen.
4. Auswirkungen automatisierter Entscheidungen. Systematische Überwachung in Verbindung mit automatisierter Entscheidungsfindung verschärft die DPO-Pflichten, selbst bei kleineren Betrieben, da sie erhebliche Auswirkungen auf betroffene Personen hat.

Änderung 13 schafft verpflichtende DPO-Auslöser im israelischen Datenschutzgesetz

Das israelische Datenschutzgesetz legt grundlegende Pflichten für die Verarbeitung personenbezogener Daten fest. Die Änderung 13 erweitert diese erheblich, indem sie verpflichtende DPO-Anforderungen für Organisationen einführt, die groß angelegte, systematische Überwachung oder Verarbeitung sensibler Datenkategorien betreiben. Änderung 13 konkretisiert und operationalisiert diese Pflichten innerhalb der israelischen Gerichtsbarkeit und beseitigt Unklarheiten über Kerntätigkeiten und systematische Überwachung für Unternehmen, die in Israel tätig sind oder Daten israelischer Einwohner verarbeiten.

Für SaaS-Anbieter beschränken sich Kerntätigkeiten nicht auf kundenorientierte Funktionen, sondern umfassen jede Verarbeitung, die für das Servicemodell wesentlich ist. Eine Kollaborationsplattform, die das Nutzerverhalten überwacht, um Kontenkompromittierungen zu erkennen, betreibt systematische Überwachung als Kerntätigkeit. Ein Recruiting-Tool, das Gesundheitsdaten im Rahmen von Nachteilsausgleich verarbeitet, führt groß angelegte Verarbeitung sensibler Kategorien durch. Ein Identitätsanbieter, der Authentifizierungsvorgänge über Unternehmenskunden hinweg protokolliert, betreibt systematische Überwachung im großen Maßstab.

Änderung 13 nimmt vielen Technologieunternehmen den angenommenen Ermessensspielraum. Die Pflicht greift, sobald die Verarbeitungsmerkmale mit den regulatorischen Schwellenwerten übereinstimmen – nicht, wenn das Unternehmen entscheidet, dass eine Benennung sinnvoll wäre. Eine Fehleinschätzung dieses Status führt zu unmittelbarer regulatorischer Gefährdung.

Kernaktivitäten umfassen Sicherheits-, Analyse- und Integritätsfunktionen

SaaS-Anbieter ordnen Sicherheitsüberwachung, Betrugserkennung und Nutzungsanalysen oft unterstützenden Funktionen zu. Änderung 13 betrachtet diese jedoch als Kerntätigkeiten, wenn sie wesentliche Bestandteile der Servicebereitstellung sind. Eine Videoplattform, die das Verhalten von Teilnehmern analysiert, um Belästigungen zu erkennen, nutzt systematische Überwachung als Kerndienst zur Sicherstellung der Integrität. Ein Finanztool, das Transaktionsdaten zur Geldwäscheerkennung verarbeitet, führt zentrale Compliance-Verarbeitung durch.

Entscheidend ist, ob die Verarbeitung untrennbar mit dem Servicemodell verbunden ist. Wenn deren Wegfall das Angebot grundlegend verändern oder ein unvertretbares Risiko schaffen würde, gilt sie als Kernaktivität. Dies umfasst Bedrohungserkennung, Nutzerverhaltensanalysen, Inhaltsmoderation und Compliance-Automatisierung, die viele SaaS-Anbieter implementieren, ohne den DPO-Auslöser zu erkennen.

Sicherheitsverantwortliche in Unternehmen müssen die Verarbeitung nach Funktion und nicht nach Abteilung inventarisieren. Authentifizierungsprotokollierung durch das Sicherheitsteam gilt als Kernüberwachung, auch wenn sie keinen Umsatz generiert. Verhaltensanalysen, die Produktempfehlungen steuern, stellen systematische Überwachung dar – unabhängig von der Teamstruktur.

Groß angelegte Verarbeitung gilt kumulativ über alle Kundentenants hinweg

Änderung 13 verlangt eine kontextbezogene Bewertung des Umfangs anhand der Anzahl betroffener Personen, Datenvolumen, geografischer Reichweite und Dauer. SaaS-Anbieter müssen den Umfang kumulativ über alle Kundentenants hinweg bewerten, nicht isoliert.

Eine HR-Plattform, die fünfzig Unternehmenskunden bedient, verarbeitet möglicherweise personenbezogene Daten von insgesamt 200.000 Mitarbeitenden. Diese Gesamtsumme bestimmt den Status „groß angelegt“, nicht einzelne Kundeneinsätze mit je 4.000 Datensätzen. Eine Marketing-Automatisierungsplattform bewertet den Umfang anhand aller verfolgten Personen über Kundenwebsites hinweg, nicht pro Kampagne.

Diese kumulative Bewertung schafft Auslöser für mittelgroße SaaS-Anbieter, die bei einer Betrachtung pro Tenant nicht greifen würden. Eine Compliance-Plattform mit dreißig Kunden, die sensible Kategoriedaten verarbeitet, erreicht durch das aggregierte Volumen die Schwellenwerte für groß angelegte Verarbeitung, auch wenn einzelne Kunden kleine Organisationen sind.

Multi-Tenant-Architekturen erfordern Verarbeitungsinventare, die die Anzahl betroffener Personen, Zwecke und Kategorien über die gesamte Plattform hinweg erfassen. Für die Bestimmung des Umfangs ist eine kumulative Transparenz erforderlich, die viele SaaS-Anbieter bislang nicht gewährleisten.

Systematische Überwachung umfasst Authentifizierung, Analysen und Bedrohungserkennung

Systematische Überwachung umfasst jede regelmäßige, organisierte Beobachtung betroffener Personen, insbesondere durch automatisierte Verfahren. Für SaaS-Anbieter fallen darunter weit mehr Aktivitäten als klassische Mitarbeiterüberwachung oder Marketing-Tracking.

Authentifizierungssysteme, die Nutzerzugriffe, Geräte-Fingerprints und Standortdaten protokollieren, betreiben systematische Überwachung. Diese Systeme laufen kontinuierlich, analysieren Verhaltensmuster auf Anomalien und erstellen dauerhafte Aktivitätsprotokolle. Die Überwachung dient legitimen Sicherheitszwecken, bleibt aber systematische Überwachung und löst bei großem Umfang als Kerntätigkeit die DPO-Pflicht aus.

Session-Replay-Tools, die Nutzerinteraktionen aufzeichnen, Analysen zur Feature-Nutzung, Inhaltsmoderation bei nutzergenerierten Inhalten und Betrugserkennung bei Transaktionen sind allesamt Formen systematischer Überwachung. Das gemeinsame Merkmal ist die organisierte, fortlaufende Beobachtung – nicht gelegentliche manuelle Überprüfung.

Zero trust-Architekturen schaffen zusätzliche Pflichten zur systematischen Überwachung. Die Bewertung des Nutzerkontexts bei jeder Zugriffsanfrage, Verhaltensanalysen gegen Baselines und die Protokollierung von Entscheidungsfaktoren sind Monitoring-Aktivitäten, die sich zu systematischer Verarbeitung im großen Maßstab summieren.

Automatisierte Entscheidungsfindung verschärft Pflichten unabhängig vom Umfang

Wenn systematische Überwachung automatisierte Entscheidungen mit rechtlichen oder ähnlich erheblichen Auswirkungen speist, verschärft sich die DPO-Pflicht unabhängig vom Umfang. Eine Plattform, die Konten automatisch auf Basis von Verhaltensanalysen sperrt, trifft automatisierte Entscheidungen mit Auswirkungen auf den Dienstzugang. Ein Bewerbermanagementsystem, das Kandidaten per Algorithmus filtert, erzeugt erhebliche Folgen für die Beschäftigung.

Änderung 13 wertet automatisierte Entscheidungsfindung als Verarbeitungsmerkmal, das das Risiko erhöht und die Governance-Anforderungen verschärft. Auch Anbieter, die keine groß angelegten Schwellenwerte erreichen, unterliegen klaren DPO-Pflichten, wenn systematische Überwachung zu folgenreichen automatisierten Entscheidungen führt.

Davon betroffen sind IAM-Plattformen, als SaaS angebotene Security Information and Event Management (SIEM)-Tools, Kundendatenplattformen mit automatisierter Segmentierung und Anwendungen, die auf Basis von Verhaltenssignalen Zugriffe ohne menschliche Prüfung einschränken, gewähren oder ändern. Automatisierung entzieht Entscheidungen, die Rechte oder wesentliche Interessen Betroffener betreffen, der menschlichen Kontrolle.

Unternehmen, die KI-Funktionen implementieren, müssen prüfen, ob diese bestehende Überwachung in automatisierte Entscheidungsfindung überführen. Eine Kollaborationsplattform, die KI-gestützte Inhaltswarnungen einführt, überschreitet diese Schwelle, wenn Warnungen die Sichtbarkeit von Inhalten oder Reputationswerte beeinflussen.

Verarbeitung besonderer Kategorien und biometrische Systeme lösen sofortige Auslöser aus

Die Verarbeitung besonderer Kategorien im großen Umfang ist ein unmittelbarer DPO-Auslöser. Nach Änderung 13 umfassen sensible Datenkategorien Angaben zur rassischen oder ethnischen Herkunft, politischen Meinungen, religiösen Überzeugungen, Gesundheitsdaten, biometrische Daten zur Identifikation, Finanzinformationen und weitere nach israelischem Recht als sensibel eingestufte Kategorien.

SaaS-Anbieter in den Bereichen Gesundheit, HR, Rechtsdienstleistungen und Finanz-Compliance verarbeiten routinemäßig Daten besonderer Kategorien, ohne den vollen Umfang zu erkennen. Eine Benefits-Plattform, die Krankenversicherungswahlen verarbeitet, verarbeitet Gesundheitsdaten. Ein Recruiting-System, das Diversity-Monitoring betreibt, verarbeitet Daten zur ethnischen Herkunft. Ein Legal-Case-Management-Tool, das Vorwürfe dokumentiert, verarbeitet sensible strafrechtliche Daten.

In diesen Kontexten wird die Schwelle für groß angelegte Verarbeitung schnell erreicht. Eine Health-Tech-Plattform mit fünfzehn Unternehmenskunden verarbeitet leicht Gesundheitsdaten von Tausenden Betroffenen. Ein Background-Check-Service erfüllt sowohl die Kriterien für sensible Kategorien als auch für groß angelegte Verarbeitung nahezu unmittelbar nach dem Markteintritt.

Gesichtserkennung, Fingerabdruck-Scanning und andere biometrische Authentifizierung verarbeiten besondere Kategorien, wenn sie zur Identifikation eingesetzt werden. Änderung 13 bewertet biometrische Identifikation als Hochrisikoverarbeitung, die DPO-Aufsicht erfordert – unabhängig von der geschäftlichen Begründung. Eine Plattform, die biometrische Authentifizierung als Sicherheitsfeature anbietet, löst die DPO-Pflicht sofort aus, wenn sie groß angelegt oder als Kerntätigkeit erfolgt.

Bewertung, ob Ihr Unternehmen einen DPO benennen muss

Die DPO-Pflicht erfordert eine strukturierte Bewertung der Verarbeitungsinventare anhand der Kriterien der Änderung 13: Unterscheidung zwischen Kern- und unterstützenden Tätigkeiten, Quantifizierung des Umfangs über alle Tenants, genaue Kategorisierung der Datentypen und ehrliche Einschätzung der Überwachungsmerkmale.

Inventarisieren Sie alle Verarbeitungstätigkeiten mit personenbezogenen Daten nach Verarbeitungszweck, nicht nach System oder Abteilung. Dokumentieren Sie für jede Aktivität, ob sie für die Servicebereitstellung wesentlich ist, welche Datenkategorien betroffen sind, wie viele Personen über alle Kunden hinweg betroffen sind, ob sie kontinuierlich erfolgt und ob automatisierte Entscheidungen getroffen werden.

Ordnen Sie die Aktivitäten den Hauptauslösern der Änderung 13 zu: groß angelegte systematische Überwachung, groß angelegte Verarbeitung sensibler Kategorien und Verarbeitungstätigkeiten mit erhöhtem Rechenschaftsbedarf. Die ersten beiden werden häufig durch Kombinationen aus Authentifizierungsprotokollierung, Analysen, Sicherheitsüberwachung und branchenspezifischer Verarbeitung in SaaS-Umgebungen aktiviert.

Berücksichtigen Sie Wachstumspfade der Verarbeitung. Eine Plattform, die aktuell unterhalb der Schwellenwerte liegt, diese aber aufgrund von Kundenzuwachs bald überschreitet, sollte vorausschauend handeln. Wer erst nach Überschreiten der Schwelle reagiert, riskiert Compliance-Lücken während Benennung und Onboarding. Vorausschauende Governance bedeutet, DPOs proaktiv zu benennen, wenn der Schwellenwert im nächsten Quartal absehbar überschritten wird.

Unabhängigkeits- und Fachanforderungen bestimmen die Benennungsoptionen

Änderung 13 verlangt, dass DPOs über Fachwissen im Datenschutzrecht und in der Praxis verfügen, die Verarbeitung im Unternehmen verstehen und bei Datenschutzaufgaben tatsächlich unabhängig von Weisungen agieren. Diese Anforderungen bestimmen, ob interne Mitarbeitende, externe DPOs oder gruppenübergreifende Ressourcen benannt werden können.

Interne Benennungen sind erfolgreich, wenn Kandidaten nachweislich Datenschutzexpertise besitzen, nicht an das Top-Management berichten (um Interessenkonflikte zu vermeiden) und ausreichend Zeit neben anderen Aufgaben aufbringen können. Die Benennung eines Chief Information Security Officer als DPO birgt Konflikte, wenn Sicherheitsentscheidungen Datenschutzprinzipien widersprechen. Die Benennung des General Counsel ist problematisch, wenn rechtliche Strategien kommerzielle Interessen über die Rechte Betroffener stellen.

Externe DPO-Services bieten Fachwissen und Unabhängigkeit, erfordern aber ein Management, das sicherstellt, dass der DPO die Verarbeitung im Unternehmen ausreichend versteht. Compliance-Verantwortliche sollten Datenschutz-Zertifizierungen, Erfahrung im Umgang mit Aufsichtsbehörden, Verständnis technischer und rechtlicher Aspekte sowie Kommunikationsfähigkeit mit Geschäftsleitung, Technikteams und Betroffenen prüfen.

Governance-Strukturen für die Wirksamkeit des DPO aufbauen

Die Benennung eines DPO erfüllt die Anforderungen der Änderung 13, aber wirksame Governance erfordert unterstützende Strukturen, die die DPO-Funktion ermöglichen. Dazu gehören definierte Eskalationswege, Zugriff auf Verarbeitungsdokumentation, Einbindung in Projekte ab der Designphase und Ressourcen für Datenschutz-Folgenabschätzungen (DPIA).

SaaS-Anbieter müssen sicherstellen, dass DPOs zeitnah über neue Verarbeitungen, Änderungen bestehender Prozesse, Sicherheitsvorfälle mit personenbezogenen Daten und neuartige Betroffenenanfragen informiert werden. Dies erfordert die Integration zwischen Projektmanagement, Incident-Response-Prozessen und Supportsystemen.

Der DPO benötigt die Befugnis, Bedenken direkt an die Geschäftsleitung zu eskalieren, ohne durch Hierarchien gefiltert zu werden. Wenn Produktteams Features mit unverhältnismäßigem Datenschutzrisiko vorschlagen, muss der DPO Zugang zu Entscheidern haben, die Roadmaps anpassen können.

Enterprise-Architekturteams sollten DPOs Lesezugriff auf Verarbeitungsprotokolle, Sicherheitslogs, Datenflussdokumentationen und Lieferantenverträge gewähren. Dies ermöglicht proaktives Monitoring statt reaktiver Untersuchungen. Ein DPO, der problematische Verarbeitung erst durch Incident-Reports statt durch Design-Reviews erkennt, kommt zu spät, um Compliance-Risiken zu verhindern.

Datenschutz-Folgenabschätzungen erfordern DPO-Prüfung

Hochrisikoverarbeitungen erfordern DPIAs vor der Umsetzung. Änderung 13 schreibt die Einbindung des DPO in den DPIA-Prozess vor und schafft damit Workflow-Abhängigkeiten, die Produktteams in Entwicklungszyklen berücksichtigen müssen.

SaaS-Anbieter, die neue Monitoring-Funktionen, automatisierte Entscheidungen, groß angelegte Verarbeitung sensibler Kategorien oder innovative Technologien einführen, müssen DPIAs mit DPO-Beteiligung vor dem Rollout durchführen. Die DPIA dokumentiert Notwendigkeit, Verhältnismäßigkeit, Risikominderung und Schutzmaßnahmen. Der DPO prüft die Bewertung auf Angemessenheit und empfiehlt zusätzliche Kontrollen.

Dies schafft vorgelagerte Abhängigkeiten in der Produktentwicklung. Features, die ohne abgeschlossene DPIA in den User Acceptance Test gehen, bergen Launch-Risiken, falls die Bewertung schwerwiegende Datenschutzprobleme aufdeckt. Effektive Governance verankert DPIA-Anforderungen bereits in der Sprintplanung oder Anforderungsdefinition und bindet den DPO in Design-Reviews ein.

Continuous-Delivery-Pipelines müssen Datenschutz-Gates neben Security- und Qualitäts-Gates enthalten. Automatisierte Prüfungen können Verarbeitungsmerkmale markieren, die DPIAs erfordern, etwa neue Datenkategorien, erweiterte geografische Reichweite oder Integration von Drittanbieter-Analysen. Solche Marker lösen DPO-Benachrichtigungen aus, bevor Code produktiv geht.

Nachweis der DPO-Benennung bei Kundenaudits und Audit-Bereitschaft

Unternehmenskunden verlangen im Rahmen des Lieferantenrisikomanagements zunehmend einen Nachweis über die DPO-Benennung, wenn bei der Beschaffung personenbezogene Daten verarbeitet werden. Sicherheitsfragebögen fragen explizit nach der DPO-Benennung, verlangen Kontaktdaten und prüfen die Berichtslinien, um die Unabhängigkeit zu bewerten.

SaaS-Anbieter, die einen DPO hätten benennen müssen, dies aber versäumt haben, erschweren den Vertrieb an Unternehmen. Beschaffungsteams werten fehlende Benennungen als Indiz für eine unreife Datenschutz-Governance. Diese Wahrnehmung reicht über regulatorische Risiken hinaus und wirft Fragen zur Zuverlässigkeit und Vertragserfüllung auf.

Die Veröffentlichung der DPO-Kontaktdaten in Datenschutzhinweisen und Sicherheitsdokumentationen demonstriert Transparenz und erleichtert Betroffenen die Kontaktaufnahme. Änderung 13 verlangt die Veröffentlichung der DPO-Kontaktdaten, was ein überprüfbares Compliance-Signal für Beschaffungsteams darstellt.

Regulatorische Audits und Kundensicherheitsprüfungen untersuchen die DPO-Benennungsdokumentation, Berichtslinien, Einbindung in zentrale Entscheidungen und Belege für die Unabhängigkeit. Audit-Bereitschaft erfordert Nachweise für die tatsächliche DPO-Funktion, nicht nur die formale Benennung.

Dokumentieren Sie die DPO-Beteiligung an DPIAs, Sicherheitsvorfall-Reviews, Bearbeitung von Betroffenenanfragen, Lieferantenbewertungen und Richtlinienanpassungen. Halten Sie fest, wann der DPO Bedenken geäußert, welche Empfehlungen er gegeben und wie die Geschäftsleitung reagiert hat. Diese Nachweise belegen, dass der DPO als aktiver Governance-Partner und nicht nur nominell agiert.

Verfolgen Sie DPO-Weiterbildungen, berufliche Entwicklung und die Teilnahme an Datenschutz-Arbeitsgruppen. Diese Aktivitäten belegen die kontinuierliche Fachkompetenz, die Änderung 13 fordert. Compliance-Teams sollten Governance-Plattformen implementieren, die DPO-Konsultationen systematisch erfassen und revisionssichere Nachweise für die tatsächliche Einbindung schaffen.

Compliance operationalisieren durch technische Kontrollen und DPO-Aufsicht

Die Benennung eines DPO erfüllt Governance-Pflichten, aber Unternehmen müssen gleichzeitig technische Kontrollen implementieren, die die vom DPO überwachten personenbezogenen Daten schützen. Der DPO übernimmt die Aufsicht, aber der Schutz erfordert Durchsetzungsmechanismen, die unbefugten Zugriff verhindern, anomale Datenbewegungen erkennen und Audit-Belege generieren.

SaaS-Anbieter, die personenbezogene Daten über Kommunikation, Dateitransfers und API-Integrationen verarbeiten, stehen vor besonderen Herausforderungen beim Schutz von Daten in Bewegung. Diese Datenflüsse umgehen oft klassische Perimeter-Kontrollen, überschreiten Ländergrenzen und binden Drittsysteme außerhalb der direkten Verwaltung ein.

Zero trust-Architekturen bilden die Grundlage für den Schutz dieser Flüsse, aber die Umsetzung erfordert inhaltsbasierte Kontrollen, die die Sensibilität der Daten erkennen, granulare Zugriffsrechte durchsetzen und Entscheidungen unveränderlich protokollieren. Der DPO benötigt Transparenz darüber, wie personenbezogene Daten bewegt werden, wer darauf zugreift und ob die Kontrollen wirksam sind.

Sicherheitsverantwortliche in Unternehmen, die zero trust-Prinzipien umsetzen, müssen Kontrollen über Netzwerk- und Identitätsschichten hinaus auf die Inhaltsebene ausdehnen, auf der personenbezogene Daten liegen. Ein Nutzer, der per Multi-Faktor-Authentifizierung (MFA) authentifiziert und durch rollenbasierte Zugriffskontrolle (RBAC) autorisiert ist, kann dennoch personenbezogene Daten exfiltrieren, wenn inhaltsbasierte Kontrollen ausgehende Transfers nicht prüfen.

Änderung 13 verlangt, dass Unternehmen Compliance durch Nachweise belegen, nicht durch Behauptungen. Wenn Betroffene Auskunftsrechte wahrnehmen oder Beschwerden einreichen, prüft der DPO anhand von Audit-Logs, welche Verarbeitung stattgefunden hat, auf welcher Rechtsgrundlage und mit welchen Schutzmaßnahmen.

Audit-Trails müssen ausreichend detailliert sein, um Verarbeitungsvorgänge rekonstruieren zu können, manipulationssicher bleiben und so lange vorgehalten werden, dass sie regulatorische Untersuchungen historischer Verarbeitung unterstützen. Ein SaaS-Anbieter, der keine eindeutigen Nachweise darüber liefern kann, wer wann auf personenbezogene Daten zugegriffen hat, kann Compliance nicht belegen – unabhängig von der Dokumentation der Richtlinien.

Enterprise-Architekturteams sollten zentrales Logging implementieren, das Ereignisse aus Authentifizierungssystemen, Dateizugriffskontrollen, E-Mail-Gateways, API-Plattformen und Datenbankmonitoren aggregiert. Diese Logs speisen SIEM-Plattformen für Sicherheitsanalysen, müssen aber auch Compliance-Abfragen des DPO unterstützen.

Grenzüberschreitende Datenübermittlungen mit DPO-Aufsicht und technischen Schutzmaßnahmen steuern

SaaS-Anbieter mit internationalen Kunden verarbeiten personenbezogene Daten, die Ländergrenzen überschreiten, und unterliegen damit Übermittlungspflichten, die sowohl DPO-Aufsicht als auch technische Kontrollen erfordern. Änderung 13 verlangt, dass DPOs die Einhaltung der Übermittlungsanforderungen überwachen. Die Überwachung allein schützt jedoch nicht die Daten, die zwischen israelischen und internationalen Systemen übertragen werden.

Übermittlungsmechanismen wie Standardvertragsklauseln (SCCs) und von Israel anerkannte Angemessenheitsrahmen schaffen rechtliche Rahmenbedingungen, die technische Sicherheitsmaßnahmen verlangen. Ein SaaS-Anbieter, der SCCs nutzt, muss AES-256-Verschlüsselung für ruhende Daten, TLS 1.3 für Datenübertragungen, Zugriffskontrollen gegen unbefugten Zugriff aus Drittländern und Audit-Fähigkeiten zur Übermittlungs-Compliance sicherstellen. Der DPO prüft die Schutzmaßnahmen; technische Teams setzen sie um.

Sicherheitsteams müssen Übermittlungskontrollen implementieren, die Datenstandort, Zieljurisdiktion und geltende Rechtsrahmen berücksichtigen. Inhaltsbasierte Systeme können Unterscheidungen automatisch anhand von Zielort und Datenklassifizierung durchsetzen.

DPOs benötigen Transparenz über Übermittlungsinventare, die zeigen, welche personenbezogenen Daten grenzüberschreitend übertragen werden, auf welcher Rechtsgrundlage und mit welchen Schutzmaßnahmen. Dieses Inventar ermöglicht das proaktive Monitoring, das Änderung 13 verlangt, und unterstützt regulatorische Anfragen. Technische Systeme müssen dieses Inventar automatisch generieren, da manuelle Dokumentation schnell veraltet.

Warum DPO-Benennung und Datenschutzkontrollen gemeinsam weiterentwickelt werden müssen

SaaS-Anbieter, die die Auslöser der Änderung 13 erfüllen, müssen qualifizierte, unabhängige DPOs benennen und ihnen Ressourcen, Zugriffsrechte und Befugnisse zur effektiven Ausübung ihrer Funktion bereitstellen. Die Benennung erfüllt Governance-Pflichten, aber der Schutz erfordert technische Kontrollen, die personenbezogene Daten über den gesamten Lebenszyklus sichern. Diese Anforderungen verstärken sich gegenseitig, wenn sie integriert werden, und schaffen Compliance-Lücken, wenn sie getrennt behandelt werden.

DPOs identifizieren Risiken, empfehlen Kontrollen und überwachen die Compliance. Technische Systeme setzen Kontrollen durch, generieren Audit-Belege und operationalisieren Richtlinien. Gemeinsam schaffen sie das Verantwortungsrahmenwerk, das Änderung 13 verlangt. Getrennt entstehen entweder Dokumentation ohne Schutz oder Kontrollen ohne Governance-Kontext.

Für Entscheider in Unternehmen besteht der Weg darin, Verarbeitungstätigkeiten ehrlich an den Auslösern der Änderung 13 zu messen, DPOs proaktiv bei Schwellenwertüberschreitung zu benennen, Governance-Strukturen zur Stärkung der DPO-Wirksamkeit aufzubauen und technische Kontrollen zu implementieren, die Datenschutzrichtlinien durchsetzbar machen. Erfolgreiche Unternehmen betrachten die DPO-Benennung als Governance-Grundlage für technische Fähigkeiten zum operativen Schutz personenbezogener Daten.

Fazit

Die Änderung 13 des israelischen Datenschutzgesetzes schafft klare, durchsetzbare DPO-Pflichten für SaaS-Anbieter, deren Kerntätigkeiten systematische Überwachung oder groß angelegte Verarbeitung sensibler Kategorien umfassen. Diese Auslöser werden durch die Verarbeitungsmerkmale aktiviert, nicht durch die Unternehmensgröße, und gelten kumulativ über alle Kundentenants hinweg. Technologieführer in Unternehmen müssen die aktuelle Verarbeitung ehrlich bewerten, qualifizierte DPOs bei Schwellenwertüberschreitung benennen, Governance-Strukturen zur Unterstützung der DPO-Wirksamkeit aufbauen und technische Kontrollen zur Operationalisierung der Datenschutzprinzipien implementieren.

Da israelische Aufsichtsbehörden die Durchsetzung unter Änderung 13 ausweiten und Unternehmenskunden höhere Anforderungen an die Datenschutz-Governance von Anbietern stellen, sind Unternehmen, die jetzt handeln, besser aufgestellt, um sich sensible Aufträge zu sichern, Audits souverän zu bestehen und sich an die Weiterentwicklung des regulatorischen Rahmens anzupassen. Der Aufbau einer DPO-geführten Governance schafft heute eine Grundlage, die mit dem Unternehmenswachstum skaliert und künftige regulatorische Änderungen absorbiert, ohne reaktive Umstrukturierungen zu erfordern.

Datenschutz-Compliance durchsetzen und DPO-Wirksamkeit mit Kiteworks ermöglichen

SaaS-Anbieter, die sich den Anforderungen der Änderung 13 stellen, benötigen technische Architekturen, die personenbezogene Daten schützen und gleichzeitig die Audit-Belege liefern, die DPOs zur Rechenschaft benötigen. Das Kiteworks Private Data Network bietet eine einheitliche Plattform zur Sicherung sensibler Daten in Bewegung, zur Durchsetzung inhaltsbasierter zero trust-Kontrollen und zur Erstellung unveränderlicher Audit-Trails, die DPO-Untersuchungen und regulatorische Anfragen unterstützen.

Kiteworks ermöglicht es Organisationen, Datenflüsse über E-Mail, Filesharing, Managed File Transfer, Web-Formulare und APIs hinweg in einer einzigen Governance-Schicht zu verfolgen. Diese Transparenz unterstützt die Verarbeitungsinventare und Übermittlungsdokumentationen, die DPOs nach Änderung 13 pflegen müssen. Inhaltsbasierte Kontrollen setzen Zugriffsrichtlinien auf Basis von Datenklassifizierung, Verarbeitungszweck und Nutzerkontext durch und operationalisieren so die Prinzipien der Zweckbindung und Datenminimierung, die DPOs überwachen.

Die Plattform erzeugt forensische Audit-Trails, die jeden Zugriffs-, Transfer- und Administrationsvorgang mit manipulationssicherer Integrität erfassen und durch AES-256-Verschlüsselung im ruhenden Zustand sowie TLS 1.3 für alle Datenübertragungen schützen. Diese Protokolle unterstützen Betroffenenrechte, Sicherheitsvorfalluntersuchungen und regulatorische Audits mit eindeutigen Nachweisen. Die Integration mit SIEM-, SOAR- und ITSM-Plattformen verbindet Kiteworks-Auditdaten mit übergreifenden Security- und Compliance-Workflows und ermöglicht automatisierte Reaktionen auf Richtlinienverstöße sowie eine effiziente Incident-Bearbeitung.

Für SaaS-Anbieter, die personenbezogene Daten im großen Umfang verarbeiten, schließt Kiteworks die Lücke zwischen DPO-Governance und technischer Durchsetzung. Vereinbaren Sie eine individuelle Demo, um zu sehen, wie Kiteworks Unternehmen dabei unterstützt, DPO-Aufsicht zu operationalisieren, zero trust-Kontrollen für sensible Daten durchzusetzen und Rechenschaft durch umfassende Audit-Belege zu demonstrieren.