DSG und ITIL: Was das Datenschutzgesetz für IT-Prozesse heisst

Seit dem 1. September 2023 gilt das revidierte Schweizer Datenschutzgesetz (DSG). Viele IT-Organisationen haben die rechtliche Seite abgehakt: Bearbeitungsverzeichnis erstellt, Datenkategorien erfasst, Zuständigkeiten definiert.

Was dabei oft fehlt, ist die Verankerung im operativen IT-Betrieb. Ein Gesetz schützt niemanden, wenn es nicht in den täglichen Prozessen ankommt. Genau hier setzt ITIL an. Wir zeigen, wo das DSG konkrete IT-Serviceprozesse berührt – und was ohne diese Struktur fehlt.

Was fordert das DSG von IT-Organisationen?

Das DSG ist kein reines Rechtsdokument. Es stellt operative Anforderungen, die im IT-Betrieb umgesetzt werden müssen.

Meldepflicht bei Datenpannen  Verletzungen der Datensicherheit, die voraussichtlich zu einem hohen Risiko für betroffene Personen führen, müssen dem Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) gemeldet werden – «so rasch als möglich» (Art. 24 DSG).

Datenschutz durch Technik und Voreinstellung  Privacy by Design und Privacy by Default sind laut Art. 7 DSG keine Empfehlungen, sondern Pflichten.

Auskunftsrechte  Betroffene Personen können jederzeit Auskunft über ihre Daten verlangen (Art. 25 DSG). IT-Systeme müssen diese Anfragen schnell und vollständig beantworten können.

Rechenschaftspflicht  Unternehmen müssen nachweisen können, dass sie die Anforderungen einhalten. Dafür braucht es Dokumentation, nicht nur Absicht.

Wo berührt das DSG die ITIL-Praxis konkret?

Incident Management  Ein Datenschutzvorfall ist ein Security Incident und muss als solcher behandelt werden. Ohne strukturiertes Incident Management lassen sich die gesetzlichen Fristen für die Meldung an den EDÖB im Ernstfall nicht einhalten. ITIL orientiertes Incident Management klassifiziert, eskaliert und dokumentiert Vorfälle systematisch. Das ist keine Kür, das ist die Grundlage für DSG-Compliance.

Problem Management  Datenpannen sind selten Einzelfälle. Problem Management nach ITIL untersucht die Ursache und verhindert Wiederholungen. Wer belegen kann, dass ein Vorfall analysiert und die Ursache behoben wurde, steht gegenüber dem EDÖB deutlich besser da.

Change Management  Jede Änderung an Systemen, die Personendaten verarbeiten, kann datenschutzrechtliche Folgen haben. Ein strukturierter Change-Prozess stellt sicher, dass eine Datenschutz-Folgenabschätzung (DSFA) ausgelöst wird, wenn sie nötig ist – nicht erst im Nachhinein.

Service Catalogue Management  Wer weiss, welche Services existieren und welche Daten sie verarbeiten, kann Auskunftsanfragen effizient beantworten. Ein gepflegter Servicekatalog ist Voraussetzung für operative Datenschutz-Compliance, kein Nice-to-have.

Continual Improvement  Das DSG verlangt keine einmalige Massnahme, sondern laufende Anpassung. Neue Services, neue Datenflüsse, neue Risiken entstehen kontinuierlich. Wer Continual Improvement fest im IT-Betrieb verankert hat, passt Datenschutzmassnahmen automatisch mit an.

Was fehlt ohne ITIL-Fundament?

Ohne strukturierte Serviceprozesse zeigt sich in der Praxis immer dasselbe Muster:

• Ein Datenschutzvorfall wird zu spät erkannt oder zu spät gemeldet.

• Auskunftsanfragen landen in Postfächern, die niemand systematisch abarbeitet.

• Änderungen an Systemen mit Personendaten werden umgesetzt, ohne die Datenschutzfolgen zu prüfen.

• Im Audit lassen sich Massnahmen nicht belegen, weil die Dokumentation fehlt.

Das ist kein juristisches Problem. Das ist ein operatives Risiko – und es lässt sich mit den richtigen Prozessen vermeiden.

Wie startest du die Umsetzung?

Ein vollständiges ITIL-Set-up braucht Zeit. DSG-Compliance im IT-Betrieb kann trotzdem schrittweise beginnen.

• Incident-Prozess auf Meldefristen prüfen. Kann dein Team einen Datenschutzvorfall innert Stunden klassifizieren und eskalieren – nicht erst nach Tagen?

• Change-Prozess um eine DSFA-Triggerfrage ergänzen. Eine einzige Pflichtfrage im Change-Antrag («Verarbeitet diese Änderung Personendaten neu oder anders?») reicht oft schon aus.

• Servicekatalog auf Datenflüsse durchsehen. Welche Services verarbeiten welche Personendaten? Ohne diese Übersicht bleibt jede Auskunftsanfrage ein Suchspiel.

Klein anfangen schlägt lange planen. Jeder dieser Schritte lässt sich unabhängig von den anderen umsetzen.

Was wir in der Praxis sehen

In der Arbeit mit Schweizer IT-Organisationen sehen wir ein wiederkehrendes Bild: Das DSG ist bekannt, die rechtlichen Grundlagen sind meist vorhanden. Was fehlt, ist die operative Umsetzung im IT-Betrieb.

ITIL ist kein Allheilmittel. Aber ITIL-Prozesse geben IT-Teams die Struktur, um Datenschutzanforderungen im Alltag zu verankern, statt sie als reine Rechtsaufgabe an die Rechtsabteilung auszulagern.

Fazit

Das DSG verlangt mehr als ein Bearbeitungsverzeichnis. Es verlangt Prozesse, die im Ernstfall funktionieren. Incident Management sorgt für fristgerechte Meldungen, Problem Management für nachweisbare Ursachenbehebung, Change Management für rechtzeitige DSFAs, der Servicekatalog für schnelle Auskunft, Continual Improvement für laufende Anpassung.

Wer diese fünf ITIL-Prozesse sauber aufgesetzt hat, erfüllt die Anforderungen des DSG nicht nebenbei – sondern strukturell.

FAQ

Gilt das DSG auch für IT-interne Prozesse?

Ja. Das DSG gilt überall dort, wo Personendaten verarbeitet werden – auch in internen HR-Systemen, Ticket-Tools oder Monitoring-Lösungen, die Mitarbeitendendaten enthalten.

Muss jede Datenpanne dem EDÖB gemeldet werden?

Nein. Meldepflichtig sind nur Verletzungen, die voraussichtlich zu einem hohen Risiko für die betroffenen Personen führen. Eine Risikobewertung ist deshalb zwingend Teil des Incident-Prozesses.

Was ist eine Datenschutz-Folgenabschätzung (DSFA), und wann braucht es sie?

Eine DSFA prüft, ob ein Vorhaben – etwa ein neues System oder eine Datenintegration – ein hohes Risiko für Personendaten birgt. Sie ist bei Hochrisiko-Verarbeitungen Pflicht. Ein funktionierendes Change Management stellt sicher, dass die DSFA automatisch ausgelöst wird, wenn sie nötig ist.

Braucht unser Unternehmen eine:n Datenschutzbeauftragte:n?

Das DSG schreibt anders als die EU-DSGVO keine:n verpflichtende:n Datenschutzbeauftragte:n vor. Empfohlen ist die Rolle trotzdem, insbesondere für Unternehmen, die regelmässig sensible Daten verarbeiten.

Hinweis: Dieser Beitrag ersetzt keine Rechtsberatung. Für die rechtliche Einordnung im Einzelfall empfehlen wir den Beizug einer Fachperson.