Zum Inhalt springen
D'Cloud
Startseite
Über uns
Leistungen
Projekte
Blog
Kontakt
Datenschutz & Compliance26. Januar 20266 Min Lesezeit

DSGVO-konforme Software entwickeln: 7 Fallstricke für B2B-Produktverantwortliche

TL;DR· Kurzfassung

  • Artikel 25 DSGVO verlangt „Privacy by Design" — viele B2B-Produkte erfüllen die Pflicht formell auf dem Papier, nicht technisch in der Architektur.
  • Die sieben häufigsten Fallstricke liegen in Protokollierung, Drittlandtransfers, Löschkonzept, Auftragsverarbeitung, Pseudonymisierung, Rechtsgrundlage und Consent-Kopplung.
  • Compliance ist kein einmaliges Audit. Sie gehört in die Definition of Done jedes Sprints — architektonisch verankert, nicht als Checkliste nachgeholt.

Fallstrick 1: Protokollierung ohne Zweckbindung

Die meisten Anwendungen loggen Zugriffe, um Vorfälle zu analysieren. Korrekt. Die Pflicht beginnt dort, wo Logs personenbezogene Daten enthalten — und das tun sie fast immer (User-ID, IP-Adresse, E-Mail-Hash, Session-Token). Artikel 5 DSGVO verlangt eine klar definierte Speicherdauer. Ein Log-Eimer ohne Rotation ist rechtlich betrachtet ein unbegrenztes Profil.

Pragmatische Umsetzung: Retention-Regel auf Speicherebene festschreiben (z. B. 30 Tage Zugriffslogs, 7 Tage Debug-Logs), Tools wie Loki oder Elasticsearch mit ILM konfigurieren, personenbezogene Felder vor dem Verlassen der Software hashen oder trunkieren. Für eine DSGVO-konforme Infrastruktur lohnt sich der Blick auf unsere DevOps- und Cloud-Leistungen, bei denen Protokollierung und Retention standardmäßig sauber konfiguriert werden.

Fallstrick 2: Drittlandtransfers in der Toolchain

CRM, Mail-Provider, Error-Tracking, Analytics — die durchschnittliche B2B-Anwendung überträgt Daten an zwanzig bis fünfzig externe Dienste. Nach Schrems II (EuGH, C-311/18) reicht der Standardvertragsklausel-Abschluss allein nicht mehr. Erforderlich ist zusätzlich ein Transfer Impact Assessment, das dokumentiert, warum das Zielland einen im Wesentlichen gleichwertigen Schutz bietet.

Zurück zum Blog
D'Cloud

Digitalagentur & Software-Team aus Mersin — aktiv auf 3 Kontinenten. Von Web bis Mobile, ERP bis KI — Ihr digitaler Transformationspartner in 4 Sprachen.

Software-Services

  • Web- & Softwareentwicklung
  • Mobile-App-Entwicklung
  • E-Commerce-Lösungen
  • ERP- & Geschäftsmanagement
  • KI & Automatisierung
  • Cybersicherheit

Digital-Services

  • DevOps & Cloud-Infrastruktur
  • UI/UX-Design

Besonders heikel: US-Cloud-Anbieter mit europäischen Tochterunternehmen. Die Tochter mag in Frankfurt sitzen, die Muttergesellschaft unterliegt dennoch dem CLOUD Act. Prüfen Sie pro Dienst die tatsächliche Datenflussroute, nicht nur die Rechnungsadresse.

Fallstrick 3: Löschkonzept existiert, wird aber nicht ausgeführt

Artikel 17 DSGVO — Recht auf Löschung. Die meisten Produkte haben ein schriftliches Konzept. Wenige haben einen getesteten Prozess. Der Realitätscheck: Legen Sie in Ihrer Produktionsdatenbank heute einen Testnutzer an, lassen Sie die Löschanfrage über den offiziellen Weg laufen und prüfen Sie in achtundvierzig Stunden, ob sämtliche Spuren verschwunden sind — inklusive Backups, Log-Streams und Event-Queues.

Fast jede Architektur wird Reste hinterlassen. Das ist weniger eine DSGVO-Frage als eine Architekturfrage: Gibt es einen klaren Data-Lifecycle-Owner pro Entität?

Fallstrick 4: Auftragsverarbeitungsverträge ohne technische Substanz

Der klassische AVV nach Artikel 28 wird oft als Vorlage übernommen und unterzeichnet. Die entscheidende Frage — welche Sicherheitsmaßnahmen der Auftragsverarbeiter konkret ergreift — landet in Anlage 2 als generische Liste. „Angemessene Verschlüsselung" ist keine Spezifikation, sondern eine Platzhalterformulierung.

Ein belastbarer AVV benennt: Hashing-Verfahren für Passwörter (mindestens Argon2id oder bcrypt mit cost ≥ 12), TLS-Version (≥ 1.2, bevorzugt 1.3), Zugriffsprotokollierung mit Integritätsschutz, Incident-Response-Zeitfenster in Stunden. Wenn Ihr Dienstleister diese Angaben nicht liefern kann, ist der Vertrag formal gültig und inhaltlich wertlos.

Fallstrick 5: Pseudonymisierung als Etikettenschwindel

Pseudonymisierung nach Artikel 4 Nr. 5 DSGVO bedeutet: Die Zuordnung zur Person erfolgt nur unter Verwendung zusätzlicher, gesondert aufbewahrter Informationen. Eine User-ID, die numerisch fortläuft und in allen Datenbanken dasselbe Subjekt referenziert, ist keine Pseudonymisierung — sondern ein stabiler Identifikator.

Korrekte Umsetzung: Separate Key-Tabelle, die User-ID auf einen Pseudo-Schlüssel abbildet, Analytics-Datenbank enthält nur den Pseudo-Schlüssel. Die Zusatzinformation liegt in einem anderen Sicherheitsbereich mit strikter Zugriffsbeschränkung.

Fallstrick 6: Rechtsgrundlage nicht sauber gewählt

Artikel 6 Absatz 1 zählt sechs Rechtsgrundlagen auf, die meisten B2B-Produkte berufen sich pauschal auf Vertragserfüllung (lit. b) oder berechtigtes Interesse (lit. f). Beides kann passen — oder eben nicht.

Beispiel: Ein Newsletter-Tool versendet nach dem Vertrag eine monatliche Produktinformation. Das ist Vertragserfüllung. Das gleiche Tool versendet eine „Customer Success"-Umfrage, die faktisch Marketing ist. Dafür gilt Vertragserfüllung nicht. Es braucht eine Einwilligung nach lit. a oder eine saubere Abwägung nach lit. f mit Widerspruchsmöglichkeit.

Einsortierung pro Datenkategorie und Zweck in einem Verarbeitungsverzeichnis klärt das — und ist ohnehin nach Artikel 30 Pflicht.

Fallstrick 7: Consent an Leistung gekoppelt

Das Kopplungsverbot aus Artikel 7 Absatz 4 verbietet, eine Dienstleistung von einer Einwilligung abhängig zu machen, die für die Erbringung nicht erforderlich ist. Trotzdem koppeln viele B2B-Anwendungen den Login an ein Marketing-Opt-in oder zwingen zu Tracking-Cookies.

Die saubere Trennung: Funktionale Cookies ohne Zustimmung (Artikel 6 lit. f), alles Weitere mit echter Einwilligung, Ablehnung-Option genauso prominent wie Zustimmung, kein „Dark Pattern" im Banner-Design.

Wie D'Cloud das strukturell verankert

Für unsere Software-Projekte gehört DSGVO-Compliance in die Definition of Done jedes Sprints. Das heißt konkret: Jede neue User-Story, die personenbezogene Daten berührt, durchläuft eine kurze Privacy-Review vor dem Code-Merge — drei Fragen (Rechtsgrundlage? Speicherdauer? Löschpfad?) müssen beantwortet sein. Produktionsdaten deutscher Kunden liegen in EU-Regionen, Entwicklung mit synthetischen Daten, Standardvertragsklauseln 2021/914 mit Transfer Impact Assessment als Vertragsbasis. Die technische Umsetzung lehnt sich eng an unsere Leistungen im Bereich Cybersicherheit an — Sicherheit und Datenschutz werden nicht als zwei separate Themen behandelt.

Software-Werkverträge nach § 631 BGB enthalten die technischen Sicherheitsmaßnahmen als Anlage — nicht als pauschale Absichtserklärung. Innerhalb von fünfzehn Tagen nach Projektübergabe beheben wir Fehler kostenfrei, inklusive aller Compliance-Nachbesserungen, die bei der ersten Inbetriebnahme auffallen.

Nächster Schritt

Wenn Ihre Software in den nächsten Monaten eine Datenschutz-Folgenabschätzung durchläuft oder ein Audit ansteht, lohnt sich eine strukturierte Bestandsaufnahme vor dem Prüftermin. Vereinbaren Sie eine kostenlose Online-Sondierung — wir arbeiten die sieben Punkte durch und geben eine realistische Einschätzung des Aufwands. Ergänzend empfehlen wir den Beitrag zu BSI-Grundschutz und Secure Software Development; er behandelt die operative Sicherheitsschicht, die über das reine DSGVO-Thema hinaus gefordert wird.

Häufige Fragen

Was unterscheidet Artikel 25 von Artikel 32 DSGVO?

Artikel 25 verlangt Datenschutz durch Technikgestaltung und Voreinstellungen — also eine Architektur, die ohne Zutun des Nutzers datensparsam ist. Artikel 32 verlangt angemessene Sicherheitsmaßnahmen nach dem Stand der Technik. Die beiden überlappen, sind aber nicht identisch: Artikel 25 ist architektonisch, Artikel 32 operativ.

Ist ein separates Datenschutz-Audit sinnvoll?

Ein externes Audit ergibt Sinn, wenn das Produkt bereits in Betrieb ist und Sie einen unabhängigen Blick brauchen — etwa vor einer Zertifizierung oder bei einer Transaktion. In der Entwicklungsphase ist die bessere Investition ein internes Privacy-Review-Template in der Definition of Done.

Wie gehen wir mit Subunternehmern der Subunternehmer um?

Jeder Sub-Auftragsverarbeiter braucht einen eigenen AVV, der die Pflichten aus Ihrem AVV weitergibt. Kritischer Punkt: Der Hauptdienstleister muss dokumentieren, welche Sub-AVs er einsetzt, und Sie müssen zustimmen können. Generalkonsens ohne Nennung ist nicht rechtssicher.

Wie oft muss ein Verarbeitungsverzeichnis aktualisiert werden?

Formal bei jeder wesentlichen Änderung der Verarbeitungstätigkeit, praktisch mindestens einmal im Quartal. Pflegen Sie es als lebendes Dokument in einem Git-Repository oder einem Compliance-Tool — nicht als Excel-Tabelle im Fileshare.

Lohnt sich eine Datenschutz-Folgenabschätzung auch bei kleineren Produkten?

Verpflichtend ist sie nur bei voraussichtlich hohem Risiko nach Artikel 35. Sinnvoll ist sie schon bei mittlerem Risiko — sie zwingt zur strukturierten Dokumentation der Entscheidungen und schützt rückblickend bei Audits oder Beschwerden.

Inhaltsverzeichnis

Doğuhan Bulut

Gründer & CTO

Teilen

  • Twitter / X
  • LinkedIn
  • WhatsApp
Digital Marketing & SEO
  • Social-Media-Management
  • Grafik- & Markendesign
  • Beratung & Schulung
  • Unternehmen

    • Über uns
    • Projekte
    • Blog
    • Kontakt
    • Datenschutz
    • Datenschutz-Hinweis

    Kontakt

    • Profit İş Merkezi Kat:135 İhsaniye 4903. Sokak No:23 D:138 33070 , Akdeniz, Mersin 33110
    • +90 531 212 92 04
    • info [at] dcloudsoftware [dot] com

    © 2026 D'Cloud Software & Digital Agency. Alle Rechte vorbehalten.

    Datenschutz|KVKK-Hinweis