GDPR & Hosting-Verträge: Diese Klauseln müssen Webhosting-Anbieter beachten

GDPR Hosting verlangt klare Verträge: Ich definiere Verantwortlichkeiten, sichere Daten mit TOMs ab und lege den Serverstandort transparent fest. So verhindere ich Bußgelder, reagiere auf Auskunftsersuchen zügig und halte Subunternehmer, Löschkonzepte sowie Meldepflichten sauber vertraglich fest [1][2].

Zentrale Punkte

Für einen belastbaren Hosting-Vertrag setze ich auf wenige, dafür essenzielle Klauseln mit klaren Rechten und Pflichten.

• AVV-Pflicht: Art. 28 DSGVO sauber abbilden
• TOM konkret: Verschlüsselung, Backups, Zugriff
• Serverstandort: EU, SCC bei Drittstaat
• Subunternehmer: Liste, Zustimmung, Audit
• Haftung: Grenzen klar, keine Freistellung

Wer braucht DSGVO-feste Hosting-Verträge?

Jede Website mit Kontaktformular, Shop oder Tracking verarbeitet Personendaten. Damit agiere ich als Verantwortlicher und der Hoster als Auftragsverarbeiter, was einen AVV zwingend macht [1][2]. Ohne klare Regeln zu Zweck, Umfang und Löschung entstehen unnötige Risiken. Auch kleine Projekte bleiben nicht außen vor, denn selbst IP-Adressen gelten als personenbezogene Daten. Ich halte fest, welche Daten fließen, auf welcher Rechtsgrundlage ich sie verarbeite und wie der Hoster mich bei Betroffenenrechten unterstützt.

Der Auftragsverarbeitungsvertrag (AVV) erklärt

Ein vollständiger AVV klärt Rollen eindeutig: Ich als Verantwortlicher gebe Weisungen, der Hoster setzt sie um [1]. Der Vertrag nennt Zweck, Art der Daten, Kategorien von Betroffenen und die Dauer der Verarbeitung. Zudem beschreibt er die TOM nicht vage, sondern messbar: Verschlüsselung, Zugangskontrollen, Notfallprozesse, Protokollierung. Für Subunternehmer fordere ich transparente Listen, Informationspflichten bei Änderungen und ein dokumentiertes Zustimmungsverfahren [1]. Nach Vertragsende verpflichte ich den Hoster zur Löschung oder Rückgabe der Daten inklusive Nachweis, plus Unterstützung bei Audit, Auskunft und Meldungen von Datenschutzvorfällen [2].

Technisch-organisatorische Maßnahmen (TOM) praxisnah

Ich verlange obligatorische Verschlüsselung in Transit (TLS) und at rest, Härtung der Systeme sowie sauber gepflegte Firewalls. Backups müssen regelmäßig laufen, verschlüsselt sein und sich testweise wiederherstellen lassen, damit Recovery-Zeiten belegt sind [2]. Zugriff erhält nur, wer ihn wirklich braucht; Multifaktor-Authentifizierung und Protokollierung helfen bei Nachvollziehbarkeit. Patch-Management, Malware-Schutz und DDoS-Abwehr senken das Risiko von Ausfällen oder Datenabfluss. Für Notfälle verlange ich ein dokumentiertes Incident- und Continuity-Management mit definierten Reaktionszeiten [1][2][6].

Serverstandort und Drittstaatentransfers

Ein EU-Serverstandort reduziert rechtliche Risiken spürbar, weil ich so keinen rechtswidrigen Drittstaatentransfer provoziere [7]. Greifen Anbieter oder Subunternehmer aus Drittländern auf Daten zu, setze ich EU-Standardvertragsklauseln ein und prüfe zusätzliche Schutzmaßnahmen wie Verschlüsselung mit exklusiver Schlüsselkontrolle [9][10]. Technische Gestaltung ist hier entscheidend: Ohne Zugriff auf Klartextdaten im Drittland sinkt die Angriffsfläche deutlich. Für Detailfragen nutze ich vertiefende Leitfäden zu Cross-Border-Transfers. Vertragsseitig verpflichte ich den Hoster, jeden Wechsel der Standorte und Datenpfade vorab mitzuteilen [1][7].

Prüf- und Kontrollrechte richtig nutzen

Ich sichere mir Auditrechte zu und fordere Nachweise: Zertifikate, Prüfberichte, technische Beschreibungen und Log-Ausschnitte [1]. Berichte älter als zwölf Monate bewerte ich kritisch und verlange Aktualität. Remote-Assessments reichen oft aus, bei erhöhtem Risiko plane ich Vor-Ort-Prüfungen. Reaktions- und Bereitstellungszeiten für Nachweise lege ich vertraglich fest, damit Anfragen nicht versanden. Orientierung zu Pflichten hole ich mir bei Bedarf über die Hinweise zu rechtlichen Pflichten [1].

Haftung, Pflichten und Kundenverantwortung

Eine Haftungsfreistellung des Hosters über alle Risiken hinweg akzeptiere ich nicht, denn solche Klauseln tragen vor Gericht oft nicht [5]. Stattdessen begrenze ich Haftung nachvollziehbar, differenziere zwischen leichter und grober Fahrlässigkeit und benenne Kardinalpflichten. Der Vertrag hält meine eigenen Pflichten fest: Daten nur rechtmäßig einspielen, keine unzulässigen Inhalte, sichere Passwörter und Schutz vor unberechtigter Nutzung [8]. Meldepflichten bei Datenschutzvorfällen müssen zeitnah, nachvollziehbar und dokumentiert laufen. Klare Zuständigkeiten vermeiden Streit, wenn Sekunden zählen [5][8].

Zertifizierungen sinnvoll einordnen

Ein ISO-27001-Siegel liefert wertvolle Indizien, ersetzt aber keine Vertragsprüfung [1]. Ich prüfe Geltungsbereich, betroffene Standorte und ob die Zertifikate aktuell sind. Zusätzlich fordere ich Reports über Penetrationstests, Schwachstellenmanagement und Restore-Tests. Entscheidend bleibt, dass die im AVV genannten TOMs tatsächlich dem zertifizierten Scope entsprechen. Ohne Abgleich zwischen Zertifikat und Vertrag lasse ich mich nicht in Sicherheit wiegen [1][2].

Transparenz bei Subunternehmern

Für jeden Unterauftragnehmer verlange ich eine öffentlich zugängliche Liste oder ein Kundenportal mit Änderungsbenachrichtigung. Ich sichere ein Widerspruchsrecht oder mindestens das Recht zur Kündigung bei gravierenden Änderungen. Der Hoster verpflichtet jeden Subunternehmer auf identische Datenschutzstandards und stellt mir relevante Verträge oder Zusammenfassungen bereit [1]. Zugriffsketten müssen nachvollziehbar dokumentiert sein, inklusive Standorte und Datenkategorien. Nur so halte ich die Kontrolle über die gesamte Lieferkette.

Vertragliche Mindestinhalte im Überblick

Um Entscheidungen zu erleichtern, stelle ich die wichtigsten Kriterien gegenüber und bewerte die DSGVO-Tauglichkeit anhand harter Merkmale [1][2].

Anbieter	Serverstandort EU	AV-Vertrag	TLS/Backups	ISO 27001	DSGVO-Status
webhoster.de	Deutschland	ja	ja	ja	hoch
Anbieter B	EU	ja	ja	teilweise	gut
Anbieter C	außerhalb EU	auf Anfrage	ja	nein	eingeschränkt

Die Tabelle ersetzt keine eigene Prüfung, hilft mir aber, Mindeststandards rasch zu erkennen und kritische Punkte direkt anzusprechen [2][7].

Praxis-Check vor Vertragsabschluss

Vor der Unterschrift fordere ich den AVV im Originaltext, prüfe TOMs auf Nachvollziehbarkeit und verlange konkrete Nachweise wie Backuptest-Protokolle. Ich kläre, wie ich Weisungen erteile, wie schnell der Support reagiert und wie Vorfälle gemeldet werden. Für Subunternehmer lasse ich mir die aktuelle Liste zeigen und nehme Änderungen in einen Benachrichtigungsprozess auf. Den Datenlebenszyklus bespreche ich von Import über Speicherung bis zur Löschung inklusive Sicherungsbeständen. Bei internationalen Transfers bestehe ich auf SCC, zusätzlicher Verschlüsselung und dokumentierten Risikobewertungen [1][2][9][10].

SLA, Verfügbarkeit und Support vertraglich fixieren

Ich prüfe SLA-Werte für Verfügbarkeit, Reaktionszeit und Wiederherstellung und gleiche sie mit meinen Geschäftsrisiken ab [4]. Vertragslaufzeit, Kündigungsfenster und Migrationshilfe gehören in klare Absätze. Für Backups lasse ich Intervalle, Aufbewahrungsdauer und Restore-Zeiten dokumentieren, damit ich im Ernstfall belastbare Ansprüche habe. Eine transparente Support-Eskalation spart Tage, wenn es brennt. Praktische Tipps zur Vertragslektüre erhalte ich im Leitfaden zu SLA und Haftung [4][5].

Rollenabgrenzung und Shared Responsibility

Ich halte schriftlich fest, wo meine Verantwortung endet und die des Hosters beginnt. Der Hoster verarbeitet Daten nur auf Weisung, betreibt Infrastruktur und sichert diese nach AVV; ich bleibe verantwortlich für Inhalte, Rechtsgrundlagen und die Konfiguration meiner Anwendungen [1][2]. Gerade bei Managed-Services grenze ich sauber ab: Wer patcht die Applikation? Wer konfiguriert Webserver-Logs, wer Cookie-Banner? Ich definiere, was eine Weisung ist (z. B. Ticket, Change-Request) und welche Fristen gelten. Im Zweifel vermeide ich eine faktische Joint Controllership, indem ich Entscheidungs- und Zugriffsbefugnisse klar meinem Verantwortungsbereich zuordne und dokumentiere [1].

• Benennung fester Ansprechpartner auf beiden Seiten
• Prozess für Changes: Beantragung, Bewertung, Freigabe
• Grenzen von Managed-Leistungen: Was ist inkludiert, was nicht
• Pflicht zur Dokumentation aller Weisungen und Umsetzungen

DPIA-Unterstützung und Risikoabwägung

Wenn eine Datenschutz-Folgenabschätzung (DPIA) nötig ist, verlange ich strukturierte Zuarbeit: Datenflüsse, TOM-Beschreibungen, Rest-Risiken und etwaige Kompensationen [1][2]. Ich mappe technische Kennzahlen auf Risiko: RPO/RTO, Zonenmodelle, Recovery-Übungen, physische Sicherheit. Der Hoster liefert mir die Bausteine, ich entscheide über Risikoakzeptanz und dokumentiere die Ergebnisse. Änderungen mit Risikoauswirkung (neuer Standort, neues Logging-System, neue CDN-Kette) bewerte ich erneut und lasse sie vorab anzeigen [7].

Löschung, Archivierung und Backups im Detail

Ich differenziere die Datenlebenszyklen: Primärspeicher, Caches, Logdaten, Metadaten und Sicherungen. Für jedes Segment lege ich Löschfristen, Trigger und Nachweispflichten fest. Im AVV verankere ich, dass der Hoster Löschungen nicht nur im Produktivsystem, sondern auch in Snapshots und Backups berücksichtigt – technisch realistisch mit Ablauf der Aufbewahrungsfristen oder durch selektive Maskierung, wo möglich [2].

• Lösch- oder Rückgabepflicht mit Fristen nach Vertragsende
• Protokollierte Löschbestätigungen inkl. Datenträger- und Systembezug
• Trennung zwischen rechtlicher Aufbewahrung und technischer Archivierung
• Regelmäßige Tests, dass Restores keine „vergessenen“ Altbestände zurückbringen

Für Logs setze ich Datenminimierung um: IP-Anonymisierung, begrenzte Retention, klare Zugriffsrechte. So reduziere ich Betroffenenrisiken und halte zugleich forensische Anforderungen im Gleichgewicht [1][2].

Betroffenenrechte effizient unterstützen

Der AVV verpflichtet den Hoster, mich bei Art.-15–22-DSGVO-Anfragen zu unterstützen. Ich schreibe Formate und Fristen fest: Datenexporte maschinenlesbar, Logauszüge nach definierten Filtern, Korrekturen innerhalb definierter Zeitfenster. Ich regle Identitätsprüfung und sichere, dass der Hoster nur auf meine Weisung hin personenbezogene Auskünfte erteilt. Bei komplexen Recherchen (z. B. Logsuche über mehrere Systeme) verhandle ich transparente Kostensätze und Reaktionszeiten, damit die 30-Tage-Frist realistisch eingehalten werden kann [1][2].

• Standardisierte Exportprofile (z. B. JSON/CSV) und Prüfsummen
• Redaktionspflichten: Schwärzungen von Dritten in Logdateien
• Ticket-Workflows mit Eskalationslogik und Zeitstempeln

Mandantenfähigkeit, Isolation und Protokollierung

Gerade in Multi-Tenant-Umgebungen verlange ich Isolation auf Netzwerk-, Compute- und Storage-Ebene. Ich frage nach Hypervisor- und Container-Härtung, Mandantentrennung, Secret-Scopes und JIT-Access für Administratoren. Privilegierte Zugriffe protokolliert der Hoster revisionssicher; Zugriff auf Produktionsdaten erfolgt nur nach Vier-Augen-Prinzip und dokumentierter Freigabe. Logdaten halte ich zweckgebunden und minimiert; Retention richte ich an Sicherheits- und Compliance-Vorgaben aus, nicht am „nice to have“ [1][6].

Schlüssel- und Geheimnismanagement

Ich lege fest, wie Kryptoschlüssel erzeugt, gespeichert, rotiert und vernichtet werden. Idealerweise nutze ich kundenseitig kontrollierte Schlüssel (BYOK/HYOK) mit klarer Trennung der Rollen. Der Hoster dokumentiert KMS/HSM-Einsatz, Schlüsselzugriffsprozesse und Notfallpfade. Rotation und Versionierung halte ich im AVV fest; für Backups existieren getrennte Schlüssel und Zugriffsprotokolle. Wo Drittstaatenrisiken bestehen, ist exklusive Schlüsselkontrolle ein wirkungsvolles Zusatzschild [9][10].

Internationale Ketten: CDN, DNS, E-Mail und Monitoring

Ich sehe mir alle Datenpfade an, nicht nur den primären Serverstandort. CDN-Edge-Caches, DNS-Resolver, E-Mail-Relay, Support-Tools oder Cloud-Monitoring können personenbezogene Daten berühren. Deshalb gehören sie in die Subunternehmerliste inklusive Standorte, Datenkategorien und Zweck [1][7]. Ich verlange EU-Optionen, IP-Anonymisierung am Rand, und schalte nicht zwingende Dienste ab, wenn sie keinen Mehrwert liefern. Für Remote-Support regle ich, wie Bildschirmfreigaben, Logzugriffe und temporäre Adminrechte DSGVO-konform ablaufen.

Behördenanfragen und Transparenz

Ich verpflichte den Hoster, Behördenersuchen zu prüfen, mich zu informieren (soweit zulässig) und nur minimal erforderliche Daten herauszugeben. Ein definierter Prozess mit Ansprechstellen, Fristen und Dokumentation ist Pflicht. Der Hoster bewahrt gerichtliche Anordnungen, Ablehnungen und Korrespondenz auf und teilt mir regelmäßig aggregierte Transparenzangaben mit. So bleibe ich auskunftsfähig gegenüber Betroffenen und Aufsichtsbehörden [7].

Exit-Strategie, Migration und Datenportabilität

Bereits zu Beginn plane ich den Exit: Formate für Datenexport, Migrationsfenster, paralleler Betrieb, Priorisierung kritischer Systeme. Ich verankere Unterstützungspakete (Stundenkontingente), Datenintegritätsprüfungen und verbindliche Zeitpläne. Nach erfolgreicher Migration fordere ich die Bestätigung der vollständigen Datenlöschung inklusive Offsite-Backups, Logarchiven und Notfallkopien. Vertragsklauseln stellen klar: Kein Datenpfand, keine künstlichen Hürden, und AVV-Pflichten (z. B. Geheimhaltung) gelten über das Vertragsende hinaus [1][2].

Incident-Response und Meldepflichten konkretisieren

Ich schreibe Inhalt und Timing von Vorfallsmeldungen fest: Erste Meldung innerhalb definierter Stunden, mit Mindestinhalten (Umfang, betroffene Datenarten, Erkennungszeitpunkt, Erstmaßnahmen). Innerhalb von 72 Stunden erwarte ich ein Update, das mir die Bewertung nach Art. 33/34 DSGVO ermöglicht. Root-Cause-Analysen, Abstellmaßnahmen und Lessons Learned bekommt meine Organisation schriftlich und prüffähig. So verliere ich im Ernstfall keine Zeit [2][6].

Kosten, Changes und Wartungsfenster

Vertraglich halte ich fest, welche Kosten für Sonderleistungen (z. B. Betroffenenrechte, besondere Exportformate, zusätzliche Audits) anfallen dürfen und welche Leistungen als Teil der AVV-Pflichten ohne Zusatzkosten zu erbringen sind [1]. Geplante Changes kommuniziert der Hoster frühzeitig; Wartungsfenster liegen außerhalb kritischer Geschäftszeiten und sind mit verbindlichen Downtime-Grenzen versehen. Nach Störungen erwarte ich Post-Mortems, daraus abgeleitete Maßnahmen und gegebenenfalls Gutschriften gemäß SLA [4][5].

Zusammenfassung für Entscheider

Mit einem klaren AVV, belastbaren TOMs und EU-Standorten halte ich Datenschutzrisiken im Zaum. Ich sichere Auditrechte, Subunternehmertransparenz und realistische Haftungsgrenzen vertraglich ab. Für Drittstaatenzugriffe nutze ich SCC und zusätzliche Technik, damit Daten geschützt bleiben [7][9][10]. Ein sauberer Lösch- und Rückgabeprozess verhindert Altlasten nach Vertragsende. So bleibt mein Hosting-Setup rechtlich belastbar und fachlich solide dokumentiert – und ich reagiere gelassen auf Prüfungen der Aufsicht [1][2].