Autor und Sprecher
Thorsten Siefert
Technik und Gestaltung
Thorsten Siefert
Es gilt das gesprochene Wort
Eine gute Idee reicht noch nicht
Stellen wir uns eine Organisation vor, in der Beschäftigte wichtige Informationen heute nur umständlich am Arbeitsplatz oder über größere mobile Arbeitsmittel abrufen können.
Die Idee liegt nahe: Kleine mobile Geräte sollen die benötigten Informationen unmittelbar dort verfügbar machen, wo sie gebraucht werden. Identifizieren, abrufen, entscheiden , schnell und ohne unnötige Wege.
Fachlich ist das überzeugend.
Die Anforderungen werden beschrieben. Eine Lösung wird diskutiert. Das Projekt nimmt Gestalt an.
Erst später wird deutlich, dass eine wesentliche technische Voraussetzung nicht zuverlässig gegeben ist: Die notwendige Netzabdeckung steht nicht überall dort zur Verfügung, wo die Anwendung funktionieren müsste.
Das Problem ist damit nicht das Gerät.
Und auch nicht die ursprüngliche Idee.
Das Problem entstand früher: Technische Machbarkeit wurde behandelt, als wäre sie eine Eigenschaft der späteren Umsetzung, und nicht Bestandteil der Anforderung selbst.
Fachliche Anforderungen haben technische Voraussetzungen
„Informationen sollen mobil verfügbar sein“ klingt zunächst wie eine funktionale Anforderung.
Tatsächlich stecken darin zahlreiche weitere Fragen:
Ist das Netz verfügbar? Wie erfolgt die Authentisierung? Welche Berechtigungen gelten? Wie werden Geräte administriert? Welche Systeme müssen angebunden werden? Was passiert bei einem Ausfall?
Sobald personenbezogene Daten verarbeitet werden, kommen weitere Anforderungen hinzu.
Wer darf welche Informationen sehen? Welche Daten werden tatsächlich benötigt? Wie wird ein unbefugter Zugriff verhindert? Was passiert bei Verlust des Geräts? Welche Protokollierung ist erforderlich?
Datenschutz und Informationssicherheit sind damit keine zusätzlichen Prüfungen eines ansonsten fertigen Projekts.
Sie gehören zum Design.
Genau diesen Gedanken enthält auch Art. 25 DSGVO: Geeignete technische und organisatorische Maßnahmen sollen bereits bei der Festlegung der Mittel der Verarbeitung berücksichtigt werden. Art. 32 ergänzt die risikoorientierte Perspektive auf die Sicherheit der Verarbeitung.
IT ist keine Werkstatt am Ende des Projekts
In vielen Organisationen existiert noch immer ein lineares Bild:
- Der Fachbereich beschreibt, was er benötigt.
- Eine Lösung wird ausgewählt.
- Die IT setzt sie um.
Bei vernetzten digitalen Prozessen ist das zu kurz gedacht.
IT kennt nicht nur Server und Anwendungen. Sie kennt Abhängigkeiten, Schnittstellen, Betriebsmodelle, Grenzen der vorhandenen Architektur und vor allem technische Schulden.
Das gleiche gilt für Informationssicherheit und Datenschutz.
Wer diese Perspektiven erst hinzuholt, wenn wesentliche Entscheidungen bereits getroffen wurden, stellt am Ende häufig die falsche Frage:
„Könnt ihr das freigeben?“
Die bessere Frage wäre viel früher:
„Wie müssen wir es gestalten, damit es fachlich funktioniert, technisch tragfähig und regulatorisch belastbar ist?“
Datenschutz ist nicht gleich Datenschutzbeauftragter
Dabei bedeutet „Datenschutz frühzeitig einbinden“ nicht, jedes operative Detail beim Datenschutzbeauftragten abzuladen.
Sofern ein DSB bestellt ist, muss er nach Art. 38 DSGVO ordnungsgemäß und frühzeitig in datenschutzrelevante Fragen eingebunden werden. Seine Rolle besteht jedoch insbesondere in Beratung und Überwachung. Die Verantwortung für die Verarbeitung bleibt bei der Organisation.
Gerade in größeren Organisationen braucht es deshalb häufig zusätzlich eine operative Datenschutzfunktion.
Das kann ein zentrales Datenschutzmanagement sein, eine Datenschutzkoordination oder ein Netzwerk fachbereichsnaher Koordinatorinnen und Koordinatoren.
Diese Rollen ersetzen den DSB nicht.
Sie schaffen die operative Verbindung zwischen Anforderungen und Umsetzung.
Sie helfen beispielsweise dabei, Verarbeitungstätigkeiten früh zu identifizieren, Anforderungen in Projekte einzubringen, Dokumentation zu koordinieren, Maßnahmen nachzuverfolgen und Datenschutzwissen in Fachbereiche zu tragen.
Damit wird Datenschutz vom späteren Prüfschritt zu einem Bestandteil des Projektmodells.
Compliance by Design statt Abnahme am Ende
Das gleiche Prinzip lässt sich über Datenschutz hinaus anwenden.
Informationssicherheit, regulatorische Anforderungen, interne Standards oder Architekturvorgaben können ein Projekt wesentlich beeinflussen.
Wer sie erst am Ende prüft, produziert Konflikte.
Plötzlich heißt es:
„Die IT blockiert.“
„Der Datenschutz erlaubt es nicht.“
„Security hat noch Anforderungen.“
Manchmal liegt das eigentliche Governance-Problem jedoch darin, dass diese Perspektiven zu spät beteiligt wurden.
Eine perfekte Prüfung kurz vor dem Go-live hilft wenig, wenn die entscheidenden Weichen Monate zuvor gestellt wurden.
Vier Fragen vor der technischen Festlegung
Vor einer Beschaffung oder Architekturentscheidung sollten deshalb mindestens vier Dinge geklärt sein:
- Welche technische Infrastruktur setzt der gewünschte Prozess voraus?
- Welche Daten werden verarbeitet und welches Risiko entsteht daraus?
- Welche Rollen aus IT, Informationssicherheit, Datenschutz und Fachbereich müssen beteiligt werden?
- Unter welchen realen Bedingungen muss die Lösung zuverlässig funktionieren?
Gerade die letzte Frage entscheidet häufig darüber, ob eine theoretisch gute Lösung praktisch trägt.
Was Technical Governance daraus macht
Technical Governance bringt Fachlichkeit, Technik und Compliance zusammen, bevor aus einer Idee eine schwer veränderbare Festlegung wird.
Der Fachbereich kennt das Problem.
Die IT kennt die technische Realität.
Informationssicherheit bewertet Bedrohungen und Schutzmaßnahmen.
Datenschutz bringt Anforderungen an Verarbeitung und Schutz personenbezogener Daten ein.
Eine operative Datenschutz- und Governance-Funktion hilft dabei, diese Perspektiven in Anforderungen, Prozesse und Entscheidungen zu übersetzen.
Das Ziel ist nicht, Projekte durch zusätzliche Beteiligte langsamer zu machen.
Im Gegenteil.
Frühe Abstimmung ist meist deutlich günstiger als späte Korrektur.
Und genau deshalb ist technische und regulatorische Machbarkeit kein Abnahmekriterium.
Sie ist Teil der Anforderung.