Die meisten Organisationen behandeln Datenschutz als Dokumentenübung. Eine Datenschutzerklärung wird verfasst, ein Consent-Banner gesetzt, ein Ordner voller PDFs abgelegt — und alle nehmen an, das Häkchen sei gesetzt.

Dann verlangt eine betroffene Person Auskunft über alles, was Sie über sie speichern, oder deren Löschung — und der wahre Zustand wird sichtbar: Niemand weiß, wo alle personenbezogenen Daten wirklich liegen.

Bei DZDSoft ist Datensicherheit einer der am häufigsten nachgefragten Services, und das Muster ist fast immer dasselbe: Die Policy ist in Ordnung. Das System darunter nicht. So denken wir darüber, diese Lücke zu schließen.

Personenbezogene Daten verstecken sich an mehr Orten als gedacht

Die Datenschutzerklärung beschreibt die ordentliche Version: ein CRM, ein HR-System, eine Kundendatenbank. Die Realität ist unordentlicher. Personenbezogene Daten sammeln sich an in:

• Tabellen auf einzelnen Laptops und geteilten Laufwerken.
• E-Mail-Postfächern und Anhängen, unbefristet.
• Datenbank-Backups, die die kopierten Datensätze überleben.
• Anwendungs-Logs, Analytics-Events und Support-Tickets.
• Altsystemen, die niemand abgeschaltet hat, denen aber alle noch vertrauen.

Das ist das Shadow-Data-Problem, und es erklärt, warum Datenerkennung — zu wissen, was Sie halten und wo — der erste echte Schritt jeder ernsthaften Konformität ist. Was Sie nicht finden können, können Sie nicht schützen, löschen oder melden.

Die drei harten Probleme: Erkennung, Löschung, Aufbewahrung

Streicht man die juristische Sprache, verlangen sowohl DSGVO als auch KVKK drei konkrete technische Fähigkeiten. Alles andere baut darauf auf.

Die unbequeme Wahrheit: Die meisten Organisationen können alle drei beschreiben und keine zuverlässig ausführen. Beschreiben ist Policy-Arbeit. Ausführen ist Engineering — und genau dieser Teil fehlt meist.

KVKK und DSGVO: dasselbe Rückgrat, andere Details

Für Organisationen in der Türkei und der EU — was auf die meisten unserer Kunden zutrifft — die gute Nachricht: KVKK (Gesetz Nr. 6698) und DSGVO teilen dasselbe Rückgrat. Bauen Sie eines sauber, sind Sie beim anderen weitgehend am Ziel.

Sie unterscheiden sich im Detail: KVKK hat eigene Registrierungspflichten (VERBİS), eigene Regeln zu ausdrücklicher Einwilligung und Drittlandtransfer, eine eigene Aufsichtsbehörde. Die DSGVO trägt höhere Maximalstrafen und einen ausgereifteren Leitlinienkorpus. Doch das zugrunde liegende Engineering — Verzeichnis, Rechtsgrundlage, Aufbewahrung, Zugriffskontrolle, Vorfallreaktion — ist ein System, nicht zwei.

Deshalb bauen wir für die strengere Anforderung je Achse, statt parallele Programme zu pflegen. Eine gut konstruierte Datenschicht, konfiguriert für die jeweils strengere Regel, ist günstiger und sicherer als zwei halb gepflegte.

Ins System bauen

Datenschutz, der ein Audit übersteht, ist keine Funktion, die man am Ende ergänzt. Es sind Eigenschaften, die von Anfang an in die Speicherung und Bewegung der Daten hineinkonstruiert werden — Datenschutz durch Technikgestaltung, in den Worten der Verordnung. Konkret:

• Data Mapping, das aktuell bleibt, damit das Verzeichnis die Realität abbildet, nicht das Orgchart von letztem Jahr.
• Aufbewahrungsregeln, bei der Erstellung an Daten geheftet, sodass Archiv und Löschung automatisch geschehen, nicht aus Erinnerung.
• Zugriffskontrolle — Least Privilege, echte Authentifizierung (SSO/LDAP, wo es passt) — damit nur die Richtigen die richtigen Datensätze erreichen.
• Ein Audit-Trail, der festhält, wer worauf zugegriffen hat — aus „wir glauben, wir sind konform" wird „hier ist das Log".
• Verschlüsselung ruhend und in Übertragung, und Pseudonymisierung, wo die rohe Identität nicht gebraucht wird.

Nichts davon ist exotisch. Es ist diszipliniertes Engineering, angewandt auf ein Problem, das die meisten Teams nur auf Papier behandelt haben.

Wann Sie ein Datensicherheitsprojekt brauchen

Nicht jede Organisation braucht ein volles Engagement. Sie wahrscheinlich, wenn:

Treffen zwei oder mehr zu, ist die Lücke zwischen Policy und Systemen eine Haftung, die nur auf eine Anfrage, ein Audit oder eine Datenpanne wartet.

Wie wir vorgehen

Wir behandeln Konformität als Datenengineering-Problem, weil sie das ist. Unsere Arbeit beginnt mit Erkennung — kartieren, wo personenbezogene Daten wirklich liegen — dann bauen wir die Mechanismen, die Erkennung, Löschung und Aufbewahrung automatisch und nachweisbar machen. Wir sind Ingenieure, keine Kanzlei: Wir schreiben nicht Ihr Rechtsgutachten, wir bauen das System, das Ihre Rechtsposition tatsächlich trägt.

Dieselbe Disziplin, die wir in Fassaden-Software und Individualentwicklung einbringen, gilt hier. Eine Konformitätsbehauptung, die Sie im System nicht zeigen können, ist keine Konformität — sie ist eine Hoffnung. Unsere Aufgabe ist, sie zu einer Eigenschaft der Software zu machen.