DSGVO und revDSG in der IT-Praxis: TOMs, VVT und Meldepflichten

Warum Datenschutz IT-Alltag ist, nicht Recht-Abteilung

Wenn im Betrieb “Datenschutz” fällt, denken viele an Anwälte und Datenschutzerklärungen auf der Webseite. In Wahrheit landet der grösste Teil der Umsetzungsarbeit bei dir: Wer darf auf welche Daten zugreifen, wie werden Backups verschlüsselt, wie lange bleiben Logfiles liegen, und was tust du technisch, wenn ein Mitarbeitender seine Daten löschen will. Die DSGVO (EU) und das revidierte Schweizer Datenschutzgesetz revDSG (in Kraft seit 1. September 2023, oft auch nDSG genannt) sind juristische Rahmenwerke – aber ihre Kernpflichten sind IT-Architektur-Entscheidungen: Zugriffskontrolle, Verschlüsselung, Protokollierung, Löschkonzepte.

Für ein Schweizer KMU ist die Ausgangslage meist doppelt: Wer mit EU-Kunden, EU-Mitarbeitenden oder EU-Auftragsverarbeitern (z. B. Cloud-Diensten mit Sitz in der EU) arbeitet, unterliegt der DSGVO über deren Marktortprinzip (Art. 3 DSGVO) zusätzlich zum revDSG. Dieser Artikel zeigt dir, was du als IT-Verantwortlicher konkret bauen, dokumentieren und betreiben musst – mit lauffähigen Beispielen für Windows-/M365-Umgebungen, wie sie in Schweizer KMU üblich sind.

1. DSGVO vs. revDSG: Die wichtigsten Unterschiede für die IT

Das revDSG orientiert sich stark an der DSGVO, ist aber an mehreren Stellen schlanker und pragmatischer. Für die IT-Praxis sind folgende Unterschiede relevant:

Ein Zürcher KMU mit einem Onlineshop, der auch an Kunden in Deutschland verkauft, unterliegt gleichzeitig dem revDSG (Schweizer Firma) und der DSGVO (EU-Marktortprinzip, Art. 3 Abs. 2 DSGVO). In der Praxis orientierst du dich am strengeren Massstab – meist die DSGVO – und deckst damit beide Regelwerke ab.

Wichtig für die Terminologie: Die DSGVO spricht von “personenbezogenen Daten” und “Verarbeitung”, das revDSG von “Personendaten” und “Bearbeitung”. Inhaltlich meinen beide Gesetze dasselbe. Ein bestehendes DSGVO-Verzeichnis von Verarbeitungstätigkeiten (VVT) erfüllt in der Regel auch die Anforderungen des revDSG an das Verzeichnis von Bearbeitungstätigkeiten (VBT) – du musst also keine zwei separaten Register führen.

2. Das Verzeichnis von Verarbeitungstätigkeiten (VVT) aufbauen

Das VVT (Art. 30 DSGVO, Art. 12 revDSG) ist das zentrale Inventar deiner Datenverarbeitung. Es beantwortet: Welche Daten verarbeitest du, wofür, wo liegen sie, wer hat Zugriff, wie lange bleiben sie.

Aufbau eines praxistauglichen VVT

Jeder Prozess (z. B. “Lohnbuchhaltung”, “Bewerbermanagement”, “Kundensupport-Ticketsystem”) wird als eigener Eintrag geführt mit mindestens folgenden Feldern:

• Bezeichnung der Verarbeitungstätigkeit und Zweck
• Kategorien betroffener Personen (Mitarbeitende, Kunden, Bewerber)
• Kategorien der Personendaten (Stammdaten, Gesundheitsdaten, Finanzdaten)
• Empfänger/Auftragsverarbeiter (intern und extern)
• Übermittlung in Drittländer (inkl. Rechtsgrundlage, z. B. Standardvertragsklauseln)
• Aufbewahrungsdauer / Löschfrist
• TOM-Verweis (siehe Kapitel 3)

Beispiel-Eintrag als strukturierte Vorlage

prozess: "Kundensupport-Ticketsystem"
zweck: "Bearbeitung von Support-Anfragen und Störungsmeldungen"
verantwortlicher: "IT-Abteilung, Musterfirma AG"
betroffene_personen:
  - Kunden
  - externe Dienstleister
datenkategorien:
  - Name, Firma, Kontaktdaten
  - Ticketinhalt (kann sensible Infos enthalten, z. B. bei HR-Tickets)
system: "Ticketsystem (self-hosted, Rechenzentrum Zürich)"
empfaenger_extern:
  - "E-Mail-Provider (Versand von Benachrichtigungen)"
drittlandtransfer: false
aufbewahrungsfrist: "3 Jahre nach Ticketabschluss, danach automatische Löschung"
tom_verweis: "TOM-Katalog v3, Abschnitt Zugriffskontrolle + Verschlüsselung"
risikoeinstufung: "gering"

Für die Pflege eignet sich eine zentrale Excel-/SharePoint-Liste für kleine KMU, ab mittlerer Grösse lohnt sich ein dediziertes GRC-Tool (z. B. Microsoft Purview Compliance Manager, siehe M365 Purview Compliance). Wichtig ist ein fester Review-Zyklus – mindestens jährlich, sowie bei jeder Einführung eines neuen Systems.

3. TOM-Katalog: Technische und organisatorische Massnahmen

Art. 32 DSGVO und Art. 8 revDSG verlangen ein dem Risiko angemessenes Schutzniveau. Es gibt keine gesetzlich fixierte Checkliste – du musst begründen, warum deine Massnahmen ausreichend sind. Ein bewährter TOM-Katalog gliedert sich in folgende Kategorien.

3.1 Zutrittskontrolle (physisch)

• Serverraum mit Zutrittskontrollsystem (Badge/PIN), Zutrittsprotokoll mit Zeitstempel
• Besucherregelung: Protokollierung, Begleitpflicht
• Videoüberwachung an kritischen Zugängen (unter Beachtung der Verhältnismässigkeit – nicht flächendeckend im Grossraumbüro)

3.2 Zugangskontrolle (logisch)

Multi-Faktor-Authentifizierung ist heute Mindeststandard, nicht mehr “nice to have”:

# Conditional Access Policy: MFA für alle Nutzer erzwingen (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
    displayName = "Require MFA - Alle Benutzer"
    state = "enabled"
    conditions = @{
        users = @{ includeUsers = @("All") }
        applications = @{ includeApplications = @("All") }
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("mfa")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Ergänzend gehört ins Zugangskontrollkonzept:

• Passwortrichtlinie nach aktuellem BSI-/NIST-Standard (lange Passphrasen statt erzwungener Komplexität, siehe Passwort-Management)
• Automatische Sperrung inaktiver Konten nach definierter Frist (siehe IT-Onboarding und Offboarding)
• Kontosperrung nach Fehlversuchen (Account Lockout Policy)

3.3 Zugriffskontrolle (Berechtigungen)

Least-Privilege-Prinzip und Tiering sind zentral. In Active Directory heisst das: rollenbasierte Gruppen statt Einzelrechte, und ein Tier-Modell für administrative Konten (siehe AD Security Hardening Tier Model).

# Regelmässiger Access Review: Mitglieder einer sensiblen Gruppe exportieren
Get-ADGroupMember -Identity "HR-Personaldaten-Zugriff" -Recursive |
    Select-Object Name, SamAccountName |
    Export-Csv -Path "C:\Reports\AccessReview_HR_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

Mit Microsoft Entra ID Governance (Entra PIM) lassen sich periodische Zugriffsüberprüfungen automatisiert einplanen und die Ergebnisse revisionssicher dokumentieren – siehe Entra PIM Governance. Das ist ein starkes Argument gegenüber Auditoren, weil es Kontrollnachweise statt manueller Stichproben liefert.

3.4 Verschlüsselung

# BitLocker-Status auf allen Domain-Rechnern zentral abfragen (Beispiel mit PS-Remoting)
$computers = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $computers -ScriptBlock {
    Get-BitLockerVolume -MountPoint "C:" | Select-Object MountPoint, VolumeStatus, EncryptionPercentage
} -ErrorAction SilentlyContinue | Format-Table -AutoSize

3.5 Pseudonymisierung und Anonymisierung

Pseudonymisierung (Art. 4 Nr. 5 DSGVO) ersetzt direkte Identifikatoren durch Kennungen, sodass eine Zuordnung nur mit zusätzlichem, separat gespeichertem Wissen möglich ist. Das ist keine Anonymisierung (die ist unumkehrbar), zählt aber als anerkannte TOM und reduziert das Risiko bei einem Datenabfluss deutlich.

Praxisbeispiel für Testumgebungen – ein häufig übersehener Fall: Produktivdaten mit echten Kundennamen landen in Test- oder Entwicklungssystemen, die schlechter abgesichert sind.

-- Pseudonymisierung von Kundendaten für eine Testdatenbank (SQL Server)
UPDATE dbo.Kunden
SET
    Name = 'Kunde_' + CAST(KundenID AS VARCHAR(10)),
    Email = 'kunde' + CAST(KundenID AS VARCHAR(10)) + '@test.invalid',
    Telefon = '0000000000'
WHERE 1 = 1;

3.6 Verfügbarkeit und Belastbarkeit

Art. 32 Abs. 1 lit. b DSGVO verlangt explizit die Fähigkeit, Verfügbarkeit und Zugriff auf Daten nach einem physischen oder technischen Zwischenfall rasch wiederherzustellen. Das ist der direkte Bezug zur 3-2-1-Backup-Regel (siehe Backup-Strategie 3-2-1-Regel) und zur Notfallplanung (siehe IT-Notfallplanung und Disaster Recovery).

3.7 Protokollierung und Nachweisbarkeit

// Microsoft Sentinel/Log Analytics: Zugriffe auf sensible SharePoint-Bibliothek auswerten
OfficeActivity
| where RecordType == "SharePointFileOperation"
| where SiteUrl has "HR-Personaldaten"
| where Operation in ("FileAccessed", "FileDownloaded", "FileDeleted")
| project TimeGenerated, UserId, Operation, SourceFileName, ClientIP
| order by TimeGenerated desc

Protokolle sind selbst wieder personenbezogene Daten (sie enthalten Benutzernamen und IP-Adressen) und unterliegen daher ebenfalls Löschfristen – üblich sind 90 Tage bis 6 Monate für Sicherheitsprotokolle, sofern kein längeres gesetzliches Aufbewahrungserfordernis besteht.

4. Auftragsverarbeitungsverträge (AVV) richtig aufsetzen

Sobald ein externer Dienstleister Personendaten in deinem Auftrag verarbeitet (Cloud-Hoster, Backup-Provider, Payroll-Dienstleister, Managed-Service-Provider mit Fernzugriff), brauchst du einen Auftragsverarbeitungsvertrag (AVV, engl. Data Processing Agreement/DPA) nach Art. 28 DSGVO bzw. Art. 9 revDSG.

Pflichtinhalte eines AVV

• Gegenstand, Dauer und Zweck der Verarbeitung
• Art der Personendaten und Kategorien betroffener Personen
• Pflichten und Rechte des Verantwortlichen
• Weisungsgebundenheit des Auftragsverarbeiters
• Vertraulichkeitsverpflichtung der eingesetzten Mitarbeitenden
• Nachweis geeigneter TOMs (oft als Anhang mit konkretem TOM-Katalog des Anbieters)
• Regelung zu Subunternehmern (Unterauftragsverarbeitern) inkl. Informationspflicht bei Wechsel
• Unterstützungspflicht bei Betroffenenanfragen und Data Breaches
• Löschung/Rückgabe der Daten nach Vertragsende
• Auditrechte des Verantwortlichen

Praxisfall: Cloud-Anbieter aus den USA

Nutzt du einen US-Cloud-Dienst (z. B. bestimmte SaaS-Tools ausserhalb von Microsoft 365/Azure EU-Rechenzentren), brauchst du zusätzlich eine Grundlage für die Datenübermittlung in ein Drittland:

• EU-US Data Privacy Framework: Für zertifizierte US-Anbieter die einfachste Lösung
• Standardvertragsklauseln (SCC): Von der EU-Kommission vorgegebene Klauseln, in der Schweiz vom EDÖB anerkannt (mit Schweizer Anhang)
• Transfer Impact Assessment: Bewertung, ob im Zielland ein angemessenes Schutzniveau faktisch gegeben ist

Entscheidungsablauf: Brauche ich einen AVV?

Verarbeitet der Dienstleister Personendaten in meinem Auftrag?
  │
  ├─ Nein (er verarbeitet nur eigene/andere Daten) ──► Kein AVV nötig
  │
  └─ Ja
       │
       ├─ Reine Weisungsgebundenheit (Auftragsverarbeitung)?
       │     └─ Ja ──► AVV nach Art. 28 DSGVO / Art. 9 revDSG abschliessen
       │
       └─ Entscheidet der Dienstleister selbst über Zweck/Mittel?
             └─ Ja ──► Gemeinsame Verantwortlichkeit (Art. 26 DSGVO) prüfen,
                        eigene Vereinbarung nötig

5. Data Breach Notification: Fristen und Ablauf

Die Behandlung eines Datensicherheitsvorfalls ist der Ernstfall, bei dem TOM-Dokumentation und Meldeprozess zusammenlaufen.

Fristenvergleich

Technischer Ablauf im Incident-Fall

1. Erkennung: SIEM-Alert, Meldung durch Mitarbeitende oder externen Dienstleister (siehe SIEM/SOC-Grundlagen)
2. Eindämmung: Betroffene Systeme isolieren, gemäss Incident Response Plan
3. Risikoanalyse: Welche Datenkategorien sind betroffen? Wie viele Personen? Ist eine Pseudonymisierung wirksam gewesen (reduziert Risiko)?
4. Meldeentscheid: Anhand VVT feststellen, welche Verarbeitungstätigkeit betroffen ist und wer meldepflichtig ist (Verantwortlicher vs. Auftragsverarbeiter – Auftragsverarbeiter muss den Verantwortlichen unverzüglich informieren, nicht direkt die Behörde)
5. Meldung: An EDÖB (Schweiz, über dessen Meldeportal) und/oder zuständige EU-Behörde
6. Betroffenenkommunikation: Bei hohem Risiko direkte Information, sonst öffentliche Mitteilung als Alternative bei unverhältnismässigem Aufwand
7. Nachbereitung: Lessons Learned, TOM-Anpassung, VVT-Update, siehe Problem Management/Root Cause

Art der Verletzung, betroffene Kategorien und ungefähre Anzahl Personen, wahrscheinliche Folgen, ergriffene und geplante Massnahmen sowie Kontaktstelle für Rückfragen gehören in jede Meldung. Ein Vorlagen-Template dafür gehört in jeden Incident-Response-Ordner, damit im Ernstfall nicht bei null gestartet werden muss.

6. Betroffenenrechte technisch umsetzen

Betroffenenrechte (Auskunft, Berichtigung, Löschung, Datenübertragbarkeit, Widerspruch) sind in Art. 15–22 DSGVO und Art. 25–28 revDSG geregelt. Die grösste Herausforderung ist meist nicht das “Ob”, sondern das “Wie” – speziell wenn Daten über viele Systeme verteilt sind.

Auskunftsersuchen (Art. 15 DSGVO / Art. 25 revDSG)

Ein Auskunftsersuchen verlangt eine vollständige Kopie aller gespeicherten Personendaten. In einer typischen KMU-Landschaft heisst das: AD/Entra ID, Exchange-Postfach, HR-System, Ticketsystem, ERP, Fileserver-Freigaben, Backups.

# Beispiel: Alle Objekte eines Benutzers in Active Directory für ein Auskunftsersuchen exportieren
$user = "m.mueller"
Get-ADUser -Identity $user -Properties * |
    Select-Object Name, EmailAddress, Department, whenCreated, LastLogonDate, MemberOf |
    Export-Csv -Path "C:\DSGVO\Auskunft_$user_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

# Exchange Online: Content Search für alle Mails, die den Namen enthalten (eDiscovery)
Connect-IPPSSession
New-ComplianceSearch -Name "Auskunft_MMueller" -ContentMatchQuery "Max Müller" -ExchangeLocation "All"
Start-ComplianceSearch -Identity "Auskunft_MMueller"

Löschung (Recht auf Vergessenwerden, Art. 17 DSGVO / Art. 32 revDSG)

Löschung ist technisch anspruchsvoller als Auskunft, weil Backups, Archive und replizierte Systeme betroffen sind. Bewährte Praxis:

Datenübertragbarkeit (Art. 20 DSGVO / Art. 28 revDSG)

Gilt nur für Daten, die die betroffene Person selbst bereitgestellt hat, und nur bei Verarbeitung auf Basis Einwilligung oder Vertrag. Technisch bedeutet das: Export in einem strukturierten, gängigen, maschinenlesbaren Format (JSON, CSV, XML) – kein PDF-Ausdruck.

# Export von Nutzerdaten aus einer Anwendungsdatenbank als portables JSON
$data = Invoke-Sqlcmd -ServerInstance "SQL01" -Database "CRM" `
    -Query "SELECT * FROM dbo.Kontakte WHERE KundenID = 4711" 
$data | ConvertTo-Json -Depth 5 | Out-File "C:\DSGVO\Export_4711.json" -Encoding utf8

Entscheidungstabelle: Welcher Prozess für welches Recht

Erfasse jede Betroffenenanfrage als Ticket mit fixer SLA-Kategorie im Ticketsystem (siehe Ticketsystem-Grundlagen). Das liefert im Auditfall den Nachweis, dass Anfragen fristgerecht bearbeitet wurden – ein Punkt, der bei Prüfungen regelmässig explizit abgefragt wird.

7. Typische Fallstricke im KMU-Alltag

• Backup-Retention länger als Löschfrist: Wenn die Backup-Policy 7 Jahre vorsieht, aber das VVT eine Löschfrist von 2 Jahren nennt, entsteht ein Widerspruch, den jeder Auditor findet. Retention-Zeiten müssen zwischen Backup-Konzept und VVT synchronisiert sein.
• Admin-Zugriff ohne Protokollierung: Domain-Admins und Cloud-Global-Admins haben faktisch Zugriff auf alle Personendaten. Ohne Privileged Access Management (PAM/PIM) und Protokollierung ist das ein ungelöstes Risiko, unabhängig davon wie gut die restlichen TOMs sind.
• Schatten-Excel-Listen: HR- oder Vertriebsteams pflegen oft eigene Excel-Listen mit Kundendaten ausserhalb der offiziellen Systeme. Diese tauchen im VVT nicht auf und sind selten verschlüsselt.
• Fehlende Löschautomatisierung: Löschfristen, die nur “auf dem Papier” existieren, aber nie technisch durchgesetzt werden, sind bei einer Prüfung wertlos. Nutze Retention-Policies in M365 Purview oder Aufbewahrungsjobs in der Datenbank statt manueller Prozesse.
• Kein Prozess für Auftragsverarbeiter-Wechsel: Wechselt ein Cloud-Anbieter den Standort oder Unterauftragsverarbeiter, ohne dass jemand die Benachrichtigung liest, bleibt die Drittlandübermittlung unbemerkt unrechtmässig.

Weiterlernen

• EDÖB – Leitfaden zur Meldung von Datensicherheitsverletzungen – offizielle Vorgaben zur Meldepflicht nach Art. 24 revDSG
• Fedlex – Bundesgesetz über den Datenschutz (DSG) – der vollständige Gesetzestext des revDSG
• EUR-Lex – Verordnung (EU) 2016/679 (DSGVO) – vollständiger DSGVO-Text
• Microsoft Purview Compliance Manager Dokumentation – Umsetzung von Compliance-Kontrollen in M365
• KMU.admin.ch – Neues Datenschutzgesetz – praxisnahe Übersicht für Schweizer Unternehmen
• European Data Protection Board – Guidelines – vertiefende Leitlinien zu einzelnen DSGVO-Artikeln

Videos

YouTube