DSGVO & Datensicherheit

Compliance-Architektur verstehen | Prinzipien statt Checklisten | Technische Fundierung

Auf dieser Seite:

DSGVO-Prinzipien: Die technische Perspektive

Art. 5 DSGVO als System-Design-Anforderungen verstehen

Die DSGVO definiert sechs Grundsätze der Datenverarbeitung (Art. 5 Abs. 1). Diese sind nicht rechtliche Paragrafen, sondern architekturelle Constraints für Ihre System-Design-Entscheidungen.

Zweckbindung

Technisch: Daten dürfen nur für explizit definierte, dokumentierte Zwecke verarbeitet werden. Secondary Use erfordert neue Rechtsgrundlage.

Beispiel:

✓ CRM-Daten für E-Mail-Marketing (wenn consent gegeben)

✗ Dieselben Daten für AI-Training ohne neue Rechtsgrundlage

Datenminimierung

Technisch: Nur Daten erheben, die für den Zweck erforderlich sind. Database Schema sollte minimal sein, keine "nice-to-have" Fields.

Beispiel:

✓ Newsletter: Email-Adresse

✗ Newsletter: Email, Geburtsdatum, Adresse, Telefon (nicht erforderlich)

Speicherbegrenzung

Technisch: Implementierung von Data Retention Policies. Automated Deletion nach Ablauf der Speicherfrist (TTL, Cron Jobs).

Implementation:

• Datenbank: TTL (Time-to-Live) Fields

• Scheduled Job: Tägliches Cleanup abgelaufener Daten

Integrität & Vertraulichkeit

Technisch: Encryption at Rest, Encryption in Transit, Access Control, Audit Logging. Security by Design.

Mindestanforderungen:

• TLS 1.3 für Übertragung

• AES-256 für Storage (Encryption at Rest)

• RBAC (Role-Based Access Control) + Audit Logs

Rechenschaftspflicht (Art. 5 Abs. 2)

Sie müssen nachweisen können, dass Sie die DSGVO einhalten. Das ist keine rechtliche Formalität, sondern eine architekturelle Anforderung: Ihr System muss Compliance dokumentieren können.

Verarbeitungsverzeichnis

Was: Liste aller Datenverarbeitungen

Inhalt: Zweck, Kategorien, Empfänger, Löschfristen

Form: Excel, Database, GDPR-Tool

AVV (Auftragsverarbeitung)

Was: Vertrag mit Dienstleistern (Art. 28)

Wann: Wenn Dienstleister Ihre Daten verarbeitet

Beispiel: Cloud-Provider, CRM, AI-API

TOM (Tech. Maßnahmen)

Was: Dokumentation Security-Maßnahmen

Inhalt: Encryption, Access Control, Backups

Form: Security Policy Document

Data Residency: Wo liegen Ihre Daten?

Schrems II und die architekturelle Bedeutung von Server-Standorten

Data Residency beschreibt den physischen Standort, an dem Daten gespeichert und verarbeitet werden. Nach Schrems II (EuGH, 2020) ist dies nicht nur ein technisches, sondern ein rechtliches Problem.

Das Schrems-II-Problem

Der Europäische Gerichtshof entschied 2020: Privacy Shield ist ungültig. Grund: US-Behörden (NSA, FBI) haben weitreichende Zugriffsmöglichkeiten auf Daten bei US-Unternehmen – auch ohne richterliche Anordnung (FISA 702, Executive Order 12333).

Konsequenz: Datentransfers in die USA sind nicht per se illegal, aber sie erfordern zusätzliche Schutzmaßnahmen (Standard Contractual Clauses + Transfer Impact Assessment). In der Praxis: hohes Risiko.

Die Lösung: EU Data Residency

EU Data Residency bedeutet: Daten werden ausschließlich in EU-Rechenzentren verarbeitet. Physische Server stehen in EU-Ländern (DE, NL, FR, etc.).

Technisch: Cloud-Provider bieten EU-Regionen an (z.B. Frankfurt, Amsterdam). Bei Vertragsabschluss muss Region Lock garantiert sein: Daten dürfen Region nicht verlassen, auch nicht für Backups oder Analytics.

Data Residency: Drei Kategorien

EU-Residency

Definition: Daten ausschließlich in EU

Beispiel: EU-Region Cloud, EU-VPS, On-Premise

DSGVO: Unkompliziert, empfohlen

Vorteil: Keine Schrems-II-Problematik, AVV ausreichend

Drittland mit Garantien

Definition: Nicht-EU, aber mit Schutzmechanismen

Beispiel: US-Cloud mit SCC + TIA

DSGVO: Möglich, aber aufwendig

Anforderung: Standard Contractual Clauses + Transfer Impact Assessment

On-Premise (Air-Gapped)

Definition: Lokale Infrastruktur, kein Cloud

Beispiel: Server im eigenen Rechenzentrum

DSGVO: Maximale Kontrolle

Vorteil: Keine Drittstaaten-Transfers, volle Kontrolle

Compliance-Architekturen verstehen

Cloud-EU, Cloud-US, Self-Hosted – architekturelle Trade-offs

Es gibt drei fundamentale Architektur-Muster für DSGVO-konforme Datenverarbeitung. Jedes hat unterschiedliche Trade-offs bezüglich Compliance, Kosten und operationalem Aufwand.

Cloud-EU Enterprise

Managed Cloud mit EU Data Residency Garantie

Architektur

• Hosting: EU-Region Cloud (Frankfurt, Amsterdam, etc.)

• Vertrag: Business Associate Agreement (BAA) / AVV

• Garantie: Region Lock (Daten verlassen EU nicht)

• Beispiele: Azure EU-Regions, Google Cloud EU, AWS EU

Trade-offs

Vorteil: DSGVO-konform, keine eigene Infrastruktur, Enterprise-Support

Nachteil: Höhere Kosten als Standard-Cloud, Vendor-Abhängigkeit

Use Case: Business-kritische Daten, keine eigene IT-Infrastruktur

Cloud-US mit Schutzmaßnahmen

Standard US-Cloud mit SCC + TIA

Architektur

• Hosting: US-Cloud (oder sonstiges Drittland)

• Vertrag: Standard Contractual Clauses (SCC)

• Pflicht: Transfer Impact Assessment (TIA)

• Beispiele: Standard Cloud-APIs ohne EU-Garantie

Trade-offs

Vorteil: Günstiger, größere Auswahl, schneller verfügbar

Risiko: Schrems-II-Problematik, TIA erforderlich, rechtliches Restrisiko

Use Case: Nicht-sensitive Daten, Marketing-Only, kein Personenbezug

Self-Hosted (On-Premise / EU-VPS)

Eigene Infrastruktur, volle Kontrolle

Architektur

• Hosting: Eigener Server oder EU-VPS

• Kontrolle: Volle Kontrolle über Infrastruktur

• Standort: Sie bestimmen physischen Standort

• Beispiele: Bare-Metal, VPS (Hetzner, OVH), On-Prem

Trade-offs

Vorteil: Maximale DSGVO-Kontrolle, kein Vendor Lock-In, niedrige lfd. Kosten

Nachteil: Wartungsaufwand, Infrastruktur-Know-how nötig, hohe Anfangsinvestition

Use Case: Hochsensible Daten (Gesundheit, Recht), hohe Compliance-Anforderungen

Entscheidungsmatrix: Welche Architektur?

Kriterium	Cloud-EU Enterprise	Cloud-US (SCC)	Self-Hosted
DSGVO-Compliance	Hoch	Mittel (Risiko)	Maximal
Operationaler Aufwand	Niedrig	Niedrig	Hoch
Kosten	Hoch	Niedrig	Mittel
Vendor Lock-In	Ja	Ja	Nein
Rechtliches Risiko	Niedrig	Mittel-Hoch	Minimal

Technische und Organisatorische Maßnahmen (TOM)

Security by Design: Konkrete Implementierung

Art. 32 DSGVO fordert "geeignete technische und organisatorische Maßnahmen". Das ist keine Checkliste, sondern ein Risiko-basierter Ansatz: Je sensibler die Daten, desto höher die Anforderungen.

Verschlüsselung

Encryption in Transit

Mindestanforderung: TLS 1.2 oder höher (besser: TLS 1.3)

Alle HTTP-Verbindungen über HTTPS. Certificate Pinning bei Mobile Apps.

Encryption at Rest

Mindestanforderung: AES-256 für sensitive Daten

Database Encryption, Disk Encryption. Key Management System (KMS) nutzen.

End-to-End Encryption

Optional: Für hochsensible Kommunikation

Nur Client kann Daten entschlüsseln. Server hat keinen Zugriff auf Klartext.

Zugriffskontrolle

RBAC (Role-Based Access Control)

Zugriff basiert auf Rollen, nicht auf Individuen

Beispiel: "Admin", "Editor", "Viewer". Principle of Least Privilege.

Multi-Factor Authentication (MFA)

Pflicht: Für Zugriff auf personenbezogene Daten

TOTP (Time-based One-Time Password), Hardware Token, Biometrie

Audit Logging

Alle Zugriffe auf sensitive Daten loggen

Who accessed what, when? Log Retention: Mind. 6 Monate, max. 2 Jahre.

Data Protection

Backup & Disaster Recovery

3-2-1 Regel: 3 Kopien, 2 Medien, 1 Off-site

Automated Backups (täglich), Recovery Time Objective (RTO) definieren

Pseudonymisierung

Trennung von identifizierenden Daten

User ID statt Name in Logs. Separate Key-Table für Re-Identifikation.

Data Anonymization

Irreversible Entfernung von Identifikatoren

Für Analytics: Aggregierte Daten ohne Personenbezug.

Incident Response

Breach Notification (Art. 33/34)

Frist: 72 Stunden Meldung an Aufsichtsbehörde

Prozess definieren: Detection → Assessment → Notification → Remediation

Security Monitoring

Intrusion Detection, Anomaly Detection

SIEM (Security Information and Event Management) für Enterprise

Incident Response Plan

Dokumentierter Prozess für Datenpanne

Who does what? Escalation Path, Communication Template

TOM-Dokumentation: Beispiel-Template

# Technische und Organisatorische Maßnahmen

## 1. Zutrittskontrolle (Physisch)

- Rechenzentrum: ISO 27001 zertifiziert (Hetzner/Frankfurt)

- Zugang: Biometric Access Control, 24/7 Security

## 2. Zugangskontrolle (System)

- MFA für alle Admin-Accounts (TOTP)

- RBAC implementiert (Admin, Editor, Viewer)

- Session Timeout: 30 Min Inaktivität

## 3. Zugriffskontrolle (Daten)

- Least Privilege Principle

- Audit Logging aller DB-Queries

- Log Retention: 12 Monate

## 4. Verschlüsselung

- In Transit: TLS 1.3

- At Rest: AES-256 (PostgreSQL Transparent Data Encryption)

- Key Management: AWS KMS (EU-Region)

Entscheidungsframework: DSGVO-konforme Architektur wählen

Systematischer Ansatz für Compliance-Entscheidungen

3-Schritt-Framework

Daten-Klassifizierung

Frage: Welche Art von Daten verarbeiten Sie?

Öffentlich / Unkritisch

Marketing-Content, Blog-Posts, öffentliche Produktdaten

→ Alle Architekturen möglich

Geschäftskritisch

Kundennamen, E-Mails, Verträge, CRM-Daten

→ Cloud-EU oder Self-Hosted

Hochsensibel

Gesundheitsdaten, Finanzdaten, Anwaltskommunikation

→ Nur Self-Hosted

Risiko-Analyse

Fragen:

• Was sind die Konsequenzen eines Data Breach?
• Welche Branchen-Compliance ist erforderlich? (HIPAA, PCI-DSS, etc.)
• Sind besondere Kategorien betroffen? (Art. 9: Gesundheit, Religion, etc.)
• Wie groß ist die betroffene Personengruppe?

Formel: Risiko = Eintrittswahrscheinlichkeit × Schadenshöhe
Beispiel: Gesundheitsdaten-Breach → Hohes Risiko → Self-Hosted erforderlich

Architektur-Entscheidung

Basierend auf Klassifizierung und Risiko-Analyse

Datenkategorie	Risiko	Empfohlene Architektur
Öffentlich	Niedrig	Cloud-EU, Cloud-US, Self-Hosted
Geschäftskritisch	Mittel	Cloud-EU Enterprise, Self-Hosted (VPS)
Hochsensibel	Hoch	Self-Hosted On-Premise (Air-Gapped)

Quick Decision Tree

❓ Verarbeiten Sie EU-Personendaten?

✓ Ja → Weiter

✗ Nein → Alle Optionen möglich (DSGVO nicht anwendbar)

❓ Sind die Daten hochsensibel? (Art. 9 DSGVO)

✓ Ja → Self-Hosted On-Premise

✗ Nein → Weiter

❓ Haben Sie technisches Personal für Infrastruktur-Wartung?

✓ Ja → Self-Hosted VPS (EU) (niedrigste Kosten)

✗ Nein → Cloud-EU Enterprise (wartungsfrei, DSGVO-konform)

❓ Budget für Enterprise-Cloud vorhanden?

✓ Ja → Cloud-EU Enterprise

✗ Nein → Cloud-US mit SCC + TIA (Restrisiko akzeptieren)

Key Takeaways

DSGVO ist System-Design, nicht nur Compliance. Art. 5 DSGVO definiert architekturelle Constraints für Ihre Datenverarbeitung.

Data Residency ist kritisch. Nach Schrems II: EU-Hosting ist der sicherste Weg. US-Cloud erfordert SCC + TIA und hat Restrisiko.

Drei Architektur-Muster. Cloud-EU (einfach, teurer), Cloud-US (günstiger, riskanter), Self-Hosted (maximal sicher, aufwendig).

TOM ist mehr als Checkliste. Technische Maßnahmen (Encryption, Access Control) müssen risiko-basiert gewählt werden.

Rechenschaftspflicht bedeutet Dokumentation. Verarbeitungsverzeichnis, AVVs, TOM müssen nachweisbar sein. Compliance ist ein Prozess, kein Zustand.

Brauchen Sie Hilfe bei DSGVO-konformer Architektur?

Wir beraten Sie zu Compliance-Architekturen, technischen Maßnahmen und DSGVO-konformer Implementierung.

Kostenlose DSGVO-Beratung DSGVO-konforme Lösungen