Ein externer Dienst ist schnell eingebunden: Fotogalerie, Terminbuchung, Newsletter, Kontaktformular, Analyse-Tool, CRM oder Cloud-Speicher. Genau deshalb wird eine Datenpanne bei einem Anbieter nicht automatisch zum Problem eines anderen. Wenn dort personenbezogene Daten verarbeitet werden, muss der eigene Betrieb wissen, welche Rolle er hat, welche Daten betroffen sein könnten und wer innerhalb weniger Stunden entscheiden kann.

Der aktuelle Anlass zeigt das sehr konkret. Die österreichische Datenschutzbehörde berichtet über laufende Meldungen heimischer Fotograf:innen und Fotostudios nach einem Hacker-Angriff auf die deutsche Portraitbox GmbH. Betroffen sein können laut DSB unter anderem Namen, E-Mail-Adressen, Lieferadressen, Bestellhistorien, Zugangsdaten zu Fotogalerien und Fotodateien. Die zuständige Aufsicht in Nordrhein-Westfalen weist darauf hin, dass der Angriff zwar beim Dienstleister passiert ist, die nutzenden Betriebe aber datenschutzrechtlich verantwortlich bleiben können.

Für Website-Betreiber in Österreich ist der Fall nicht nur für Fotostudios relevant. Er ist ein gutes Praxisbeispiel für jedes Unternehmen, das externe Dienste in Website, Shop, Marketing oder Kundenkommunikation einbindet. Wer erst im Ernstfall herausfinden muss, ob ein Tool Auftragsverarbeiter, eigenständiger Verantwortlicher oder gemeinsamer Verantwortlicher ist, verliert wertvolle Zeit.

Warum eine Dienstleister-Datenpanne eigene Arbeit auslöst

Die zentrale Frage lautet nicht: „Wessen Server wurde angegriffen?“ Entscheidend ist, wer über Zwecke und Mittel der Verarbeitung entscheidet. Die DSB beschreibt Verantwortliche als jene Organisationen, die festlegen, warum und wie personenbezogene Daten verarbeitet werden. Ein Auftragsverarbeiter verarbeitet personenbezogene Daten dagegen im Auftrag und nach Weisung des Verantwortlichen.

Übertragen auf eine Website heißt das: Wenn ein Betrieb ein Buchungstool, eine Galerieplattform, einen Newsletterdienst oder ein Support-System auswählt, um eigene Kundendaten zu verarbeiten, bleibt er häufig selbst der Verantwortliche. Der Anbieter muss informieren und unterstützen, aber die Meldung an die Aufsichtsbehörde kann beim Website-Betreiber liegen. Genau diese Rollenverteilung sollte vor der Einbindung eines Tools geklärt sein, nicht erst nach einer Sicherheitsmeldung am Freitagnachmittag.

Die DSB erklärt außerdem, dass die Meldepflicht an die Datenschutzbehörde die Verantwortlichen trifft, nicht den Auftragsverarbeiter. Auftragsverarbeiter müssen ihren Vertragspartner unverzüglich über einen Data Breach informieren, wenn der Vorfall im Rahmen der beauftragten Verarbeitung eintritt. In guten Auftragsverarbeitungsverträgen ist daher nicht nur geregelt, dass es eine Information gibt, sondern auch wie schnell, an welche Adresse und mit welchen Mindestangaben.

Welche Website-Dienste in den Blick gehören

Viele Datenschutzrisiken liegen nicht im sichtbaren Frontend. Die Datenschutzerklärung erwähnt zwar oft Analyse, Karten, Videos, Newsletter oder Zahlungsanbieter. Im operativen Alltag kommen aber weitere Systeme dazu: Formular-Backends, Bewerbungsportale, Chat-Tools, Event-Registrierung, Kundenbewertungen, Bild- und Dokumentenspeicher, Backup-Dienste, Helpdesk-Systeme, CDN, Hoster, Agenturzugänge oder Shop-Erweiterungen.

Für jedes dieser Systeme sollten drei Punkte auffindbar sein: Welche personenbezogenen Daten fließen hinein? Auf welcher Rolle und Vertragsgrundlage wird der Dienst genutzt? Wer wird im Vorfall informiert? Diese Informationen gehören nicht nur in einen Ordner für Datenschutz-Audits. Sie müssen im Ernstfall praktisch nutzbar sein, zum Beispiel als gepflegtes Dienstleister-Verzeichnis mit Notfallkontakten, Vertragsstatus und interner Verantwortlichkeit.

Wer gerade seine Website-Dokumentation aktualisiert, sollte die öffentliche Seite und die internen Nachweise zusammen denken. Der AdSimple Datenschutz Generator hilft dabei, eingesetzte Dienste in der Datenschutzerklärung sauber zu dokumentieren. Für Tracking-, Marketing- und Einwilligungsthemen ist zusätzlich ein belastbares Consent-Setup sinnvoll; der AdSimple Consent Manager unterstützt dabei, einwilligungspflichtige Dienste kontrollierter einzubinden.

Der erste Tag nach der Meldung

Wenn ein Anbieter einen Sicherheitsvorfall meldet, sollte die erste Reaktion nicht aus hektischem Weiterleiten bestehen. Der Betrieb braucht einen kleinen, klaren Ablauf. Zuerst wird der Eingang dokumentiert: Zeitpunkt, Absender, betroffener Dienst, erste Beschreibung, bekannte Datenkategorien und bereits gesetzte Maßnahmen. Danach muss geprüft werden, ob der Dienst tatsächlich personenbezogene Daten des eigenen Unternehmens verarbeitet und welche Kunden, Nutzer:innen, Mitarbeiter:innen oder Kontaktpersonen betroffen sein könnten.

Danach folgt die Risikoeinschätzung. Die DSB nennt für Data-Breach-Meldungen unter anderem Art der Verletzung, Kategorien und ungefähre Zahl der betroffenen Personen, betroffene Datensätze, wahrscheinliche Folgen und ergriffene oder vorgeschlagene Maßnahmen. Diese Informationen liegen am Anfang oft nicht vollständig vor. Das ist kein Freibrief für Untätigkeit: Bei größeren Vorfällen können Informationen schrittweise nachgereicht werden, unangemessene Verzögerungen sollte man aber vermeiden.

Praktisch bedeutet das: Ein Verantwortlicher braucht eine Person oder ein kleines Team, das Vorfälle einordnet, Rückfragen an den Anbieter stellt, interne Systeme prüft und entscheidet, ob externe Hilfe nötig ist. Für KMU muss das kein überdimensioniertes Krisenhandbuch sein. Eine zweiseitige Prozessnotiz mit Zuständigkeiten, Meldewegen, Vorlagen und Prüffragen ist oft wertvoller als ein umfangreiches Dokument, das niemand findet.

72 Stunden sind kurz, wenn der Plan fehlt

Nach Art. 33 DSGVO ist eine Meldung an die Aufsichtsbehörde erforderlich, wenn die Verletzung voraussichtlich zu einem Risiko für Rechte und Freiheiten natürlicher Personen führt. Die DSB beschreibt dafür die Frist „unverzüglich und möglichst binnen 72 Stunden“, nachdem der Data Breach bekannt wurde. Wenn die Meldung später erfolgt, muss die Verzögerung begründet werden.

Die 72 Stunden beginnen nicht erst, wenn alle Details perfekt aufbereitet sind. Genau deshalb ist Vorbereitung so wichtig. Wer bereits weiß, welcher Dienst welche Daten verarbeitet, wer intern entscheiden darf und wo die DSB-Meldung eingebracht wird, kann belastbarer handeln. Wer diese Informationen erst aus E-Mails, Agenturverträgen und Plugin-Listen zusammensuchen muss, startet mit Rückstand.

Eine Information an betroffene Personen kommt nach Art. 34 DSGVO in Betracht, wenn voraussichtlich ein hohes Risiko besteht. Die Aufsicht in Nordrhein-Westfalen hat im Portraitbox-Kontext besonders auf die Sensibilität der betroffenen Daten hingewiesen und empfohlen, Kund:innen zu benachrichtigen. Für Website-Betreiber heißt das nicht, dass jeder Dienstleistervorfall automatisch eine Kundenmail verlangt. Es heißt aber, dass die Entscheidung nachvollziehbar dokumentiert werden sollte: Welche Daten? Welche Folgen? Welche Schutzmaßnahmen können Betroffene selbst setzen?

Rollenklärung vor der Tool-Auswahl

Die WKO weist darauf hin, dass externe Dienstleister zur Datenverarbeitung als Auftragsverarbeiter auftreten können, etwa Cloud-Anbieter, IT-Dienstleister, Werbeagenturen oder Newsletteranbieter. Gleichzeitig ist die Einordnung im Einzelfall nicht immer einfach. Banken, Versicherungen oder Behörden sind typischerweise keine Auftragsverarbeiter, weil sie eigene Zwecke und Mittel verfolgen. Auch Plattformen, Marketingdienste oder Softwareanbieter können je nach Funktion unterschiedlich einzuordnen sein.

Für die Praxis lohnt sich eine einfache Frage beim Tool-Onboarding: Verarbeitet der Anbieter personenbezogene Daten ausschließlich nach unseren Weisungen, oder entscheidet er auch selbst über Zwecke und Mittel? Daraus folgen Vertrag, Datenschutzhinweis, technische Einstellungen und Vorfallprozess. Wenn ein Auftragsverarbeiter eingesetzt wird, braucht es eine Vereinbarung nach Art. 28 DSGVO. Bei Drittlandbezug kommen zusätzlich Transferfragen dazu.

Dieser Schritt ist kein Papierluxus. Er entscheidet im Vorfall darüber, ob klar ist, von wem Informationen kommen, welche Subdienstleister eingebunden sind, welche technischen und organisatorischen Maßnahmen zugesagt wurden und welche Unterstützung der Anbieter leisten muss. Besonders bei Website-Projekten mit mehreren Agenturen, Plugins und SaaS-Tools sollte diese Klärung Teil des Go-live-Prozesses sein.

Ein belastbares Data-Breach-Setup für Websites

Ein gutes Setup beginnt mit einem aktuellen Dienstleister-Inventar. Darin stehen Dienstname, Zweck, Datenkategorien, betroffene Personengruppen, Rolle, Vertragsstatus, Speicherort, Subdienstleister-Hinweise, Notfallkontakt und interner Owner. Ergänzend braucht es eine Liste kritischer Website-Funktionen: Formulare, Shop, Newsletter, Login, Terminbuchung, Kundenbereich, Mediengalerien, Tracking und Support.

Danach folgt die Beweissicherung. Für jeden Vorfall sollte nachvollziehbar bleiben, wann man erstmals Kenntnis hatte, welche Informationen der Anbieter geliefert hat, welche Rückfragen gestellt wurden, welche Entscheidung getroffen wurde und welche Maßnahmen gesetzt wurden. Das hilft nicht nur gegenüber der Datenschutzbehörde, sondern auch intern, weil spätere Rückfragen nicht aus dem Gedächtnis beantwortet werden müssen.

Auch die Datenschutzerklärung sollte mit dem tatsächlichen Stack übereinstimmen. Wenn ein Dienst ausgetauscht, ein Formular erweitert oder ein neuer Marketingkanal aktiviert wird, müssen Dokumentation und Einwilligungslogik nachziehen. Wer hier Struktur braucht, kann das AdSimple Business Paket nutzen, um Datenschutz, Impressum, Consent und laufende Website-Pflichten gebündelt im Blick zu behalten.

Wo der aktuelle Fall besonders lehrreich ist

Der Portraitbox-Vorfall zeigt drei typische Schwachstellen. Erstens: Spezialisierte Branchen-Tools verarbeiten oft deutlich sensiblere Daten, als ihr unscheinbarer Website-Einsatz vermuten lässt. Eine Galerieplattform kann nicht nur Namen und E-Mails, sondern auch Fotos, Bestellhistorien und Zugangsdaten enthalten. Zweitens: Betroffene Betriebe können auch dann handeln müssen, wenn sie selbst keinen Server betreiben. Drittens: Kundenkommunikation braucht konkrete Hinweise, nicht nur eine abstrakte Entschuldigung.

Für andere Branchen lässt sich das leicht übertragen. Ein Friseursalon mit Terminbuchung, eine Ärztin mit Online-Formular, ein Verein mit Mitgliederplattform, ein Hotel mit Buchungs- und Newslettertools oder ein Webshop mit externem Fulfillment können in ähnliche Situationen geraten. Entscheidend ist, dass der eigene Website-Stack nicht als reine Technikliste behandelt wird, sondern als Datenschutzlandkarte.

Wer den nächsten Schritt pragmatisch angehen will, kann mit drei Fragen beginnen: Welche externen Dienste erhalten personenbezogene Daten? Welche davon sind für Kundenkontakt, Bestellungen oder sensible Inhalte besonders relevant? Und wer bekommt im Unternehmen die erste Anbieterwarnung, wenn etwas passiert? Schon diese Klärung reduziert den Stress, wenn eine echte Meldung eintrifft.

Fazit: Externe Tools brauchen einen internen Plan

Eine Datenpanne beim Dienstleister ist kein Randthema für Großunternehmen. Sie betrifft jeden Betrieb, der Website-Funktionen, Marketing, Kommunikation oder Kundendaten an externe Dienste anbindet. Der rechtliche Kern bleibt: Verantwortlichkeit, Risiko, Meldepflicht und Betroffeneninformation müssen konkret geprüft werden. Dieser Beitrag ersetzt keine individuelle Rechtsberatung, zeigt aber, welche Vorarbeit Website-Betreiber in Österreich jetzt sinnvoll leisten können.

Der beste Zeitpunkt für diese Vorarbeit ist vor dem Vorfall. Wer Dienstleister, Datenflüsse, Verträge, Datenschutztexte, Consent-Einstellungen und Notfallkontakte aktuell hält, kann im Ernstfall schneller und ruhiger reagieren. Passend dazu helfen unsere internen Leitfäden zu Datenpannen und 72-Stunden-Vorbereitung sowie zu Phishing und Firmenstammdaten, die organisatorische Seite weiter zu schärfen.

Quellen