Datenschutz & Red Teaming
nDSG-Compliance testen: Warum ein Red Team mehr findet als jeder Auditor
Ein nDSG-Audit gibt dir ein gutes Gefühl. Ein Red Team gibt dir die Wahrheit.
Seit September 2023 gilt das neue Schweizer Datenschutzgesetz. Viele Unternehmen haben reagiert: Datenschutzerklärungen aktualisiert, Verarbeitungsverzeichnisse erstellt, Cookie-Banner installiert. Auf dem Papier sieht die Compliance sauber aus. Aber Papier hält keinen Angreifer auf.
Die Frage, die sich kaum ein Unternehmen stellt: Funktionieren die technischen Schutzmassnahmen, die das nDSG verlangt, tatsächlich unter Druck? Oder zerbrechen sie beim ersten gezielten Angriff?
Genau das testet ein Red Team. Nicht mit Checklisten und Interviews, sondern mit den gleichen Werkzeugen und Methoden, die ein realer Angreifer einsetzen würde. Der Unterschied: Ein Auditor fragt «Haben Sie eine Firewall?». Ein Red Team fragt «Kann ich trotz Ihrer Firewall an die Personendaten kommen?»
Was das nDSG technisch verlangt
Das nDSG spricht in drei Artikeln direkt über Sicherheitsanforderungen, die nur durch praktische Tests sinnvoll überprüfbar sind:
Art. 7 nDSG – Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen
Der Verantwortliche muss die Datenbearbeitung technisch so gestalten, dass die Datenschutzvorschriften eingehalten werden («Privacy by Design»). Voreinstellungen müssen sicherstellen, dass die Bearbeitung auf das für den Verwendungszweck nötige Mindestmass beschränkt ist («Privacy by Default»).
Red-Team-Relevanz: Wir testen, ob die technische Gestaltung hält. Sind Standardkonfigurationen tatsächlich restriktiv? Oder liefern Systeme bei der erstbesten API-Anfrage mehr Daten als vorgesehen?
Art. 8 nDSG – Datensicherheit
Verantwortlicher und Auftragsbearbeiter müssen durch geeignete technische und organisatorische Massnahmen eine dem Risiko angemessene Datensicherheit gewährleisten. Die Massnahmen müssen es ermöglichen, Verletzungen der Datensicherheit zu vermeiden.
Red-Team-Relevanz: «Angemessen» ist relativ. Ein Auditor prüft, ob Massnahmen dokumentiert sind. Ein Red Team prüft, ob sie funktionieren. In 89 % unserer Engagements finden wir Wege, die dokumentierten Massnahmen zu umgehen.
Art. 24 nDSG – Meldung von Verletzungen der Datensicherheit
Bei einer Verletzung der Datensicherheit, die voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte der betroffenen Person führt, muss der Verantwortliche dem EDÖB so rasch wie möglich Meldung erstatten.
Red-Team-Relevanz: Wir simulieren den Ernstfall und testen dabei auch den Incident-Response-Prozess. Erkennt das Unternehmen den Angriff? Wie schnell wird eskaliert? Wer informiert den EDÖB? Bei 60 % der getesteten KMU existiert kein dokumentierter Meldeprozess.
Audit vs. Red Teaming: Was den Unterschied macht
Ein Compliance-Audit und ein Red-Teaming-Engagement haben unterschiedliche Ziele und liefern unterschiedliche Ergebnisse. Beides hat seine Berechtigung. Aber nur eines zeigt, was bei einem echten Angriff passiert.
| Dimension | Compliance-Audit | Red Teaming |
|---|---|---|
| Methodik | Interviews, Dokumentenprüfung, Checklisten | Simulierter Angriff mit realen Techniken |
| Perspektive | Interne Sicht («Was haben wir implementiert?») | Angreifer-Sicht («Was kann ich trotzdem?») |
| Ergebnis | Konformitätsbericht | Nachgewiesene Angriffspfade zu Personendaten |
| Dauer | 2-5 Tage | 2-4 Wochen |
| Blindspots | Shadow IT, Fehlkonfigurationen, Social Engineering | Regulatorische Detailanalyse, Vertragswerk |
| Kosten (typisches KMU) | CHF 5'000-15'000 | CHF 20'000-60'000 |
Die Frage ist nicht «Audit oder Red Team?». Die Frage ist: Reicht dir die Theorie, oder willst du wissen, was in der Praxis passiert?
Drei reale Szenarien aus unserer Praxis
Diese Beispiele stammen aus Red-Teaming-Engagements, die wir für Schweizer Unternehmen durchgeführt haben. Details sind anonymisiert, aber die Angriffspfade sind real.
Szenario 1: Der Export-Button
Ein Dienstleistungsunternehmen im Raum Bern hatte sein CRM korrekt abgesichert: rollenbasierte Zugriffssteuerung, verschlüsselte Verbindungen, regelmässige Patches. Der letzte Audit hatte keine Beanstandungen. Unser Red Team fand einen CSV-Export-Endpunkt, der keine Autorisierungsprüfung hatte. Ein authentifizierter Benutzer mit Basis-Rechten konnte den gesamten Kundenstamm exportieren: 23'000 Datensätze mit Name, Adresse, Geburtsdatum und Vertragsdaten. Kein Audit hatte diesen Endpunkt geprüft, weil er nicht in der Dokumentation stand.
nDSG-Relevanz: Verstoss gegen Art. 7 (Privacy by Default) und Art. 8 (Datensicherheit). Eine Meldung nach Art. 24 wäre im Ernstfall erforderlich gewesen.
Szenario 2: Die vergessene Testumgebung
Ein Gesundheitsdienstleister in der Deutschschweiz hatte eine vorbildliche Produktionsumgebung. Verschlüsselung, Zugriffskontrollen, Logging. Unser Red Team entdeckte über eine Subdomain-Enumeration eine Testumgebung, die mit einer Kopie der Produktionsdatenbank lief. Patientendaten aus dem Jahr 2024, unverschlüsselt, erreichbar mit Standard-Credentials (admin/admin). Der Datenschutzbeauftragte wusste nichts von dieser Umgebung. Sie war drei Jahre zuvor von einem Entwickler aufgesetzt und nie abgebaut worden.
nDSG-Relevanz: Verstoss gegen Art. 8 (Datensicherheit) und Art. 7 Abs. 3 (Verhältnismässigkeit der Datenbearbeitung). Besonders schützenswerter Personendaten nach Art. 5 lit. c nDSG.
Szenario 3: Der Drucker als Einfallstor
Ein Finanzberater im Kanton Zug hatte in seine IT-Sicherheit investiert: Endpoint Detection, segmentiertes Netzwerk, starke Passwort-Policy. Unser Team kompromittierte einen vernetzten Multifunktionsdrucker, der mit Werkseinstellungen lief und LDAP-Credentials im Klartext speicherte. Über diese Credentials konnten wir uns am Active Directory authentifizieren und von dort auf den File-Server mit Kundendossiers zugreifen. Der Drucker war im letzten Audit als «nicht relevant» eingestuft worden.
nDSG-Relevanz: Die technischen Massnahmen nach Art. 8 waren für die Kern-IT angemessen, aber das Gesamtsystem hatte eine Schwachstelle. Genau diese Lücken findet nur ein Angriffstest.
Welche nDSG-Anforderungen ein Red Team konkret prüft
Nicht jeder Red-Teaming-Auftrag muss ein Full-Scope-Engagement sein. Für nDSG-fokussiertes Red Teaming definieren wir gemeinsam mit dem Auftraggeber spezifische Ziele, die sich an den Schutzzielen des Gesetzes orientieren:
- Zugang zu Personendaten: Können wir von aussen oder als Low-Privilege-Benutzer auf Systeme zugreifen, die Personendaten verarbeiten? (Art. 8 nDSG, Vertraulichkeit)
- Datenexfiltration: Können wir Personendaten unbemerkt aus dem Unternehmen schleusen? Werden Data Loss Prevention (DLP) und Monitoring die Exfiltration erkennen? (Art. 8, Nachvollziehbarkeit)
- Privacy-by-Default-Validierung: Liefern APIs und Anwendungen in der Standardkonfiguration nur die minimal nötigen Daten? Oder werden bei Anfragen unnötig viele Felder zurückgegeben? (Art. 7 nDSG)
- Incident-Response-Test: Erkennt das Unternehmen den Angriff? Wie lange dauert die Eskalation? Wird der Vorfall korrekt dokumentiert? Ist ein Meldeprozess an den EDÖB vorhanden? (Art. 24 nDSG)
- Auftragsbearbeiter-Sicherheit: Können wir über Schnittstellen zu Drittanbietern (Cloud-Provider, SaaS, Outsourcing-Partner) auf Personendaten zugreifen? (Art. 9 nDSG)
Was nach dem Red Teaming passiert
Der Bericht eines nDSG-fokussierten Red-Teaming-Engagements liefert mehr als eine Schwachstellenliste. Er ist ein Compliance-Dokument, das die tatsächliche Wirksamkeit der technischen Massnahmen nachweist. Die Struktur:
- Executive Summary: Für die Geschäftsleitung. Welche Personendaten waren erreichbar, welche nicht. Gesamtrisikobewertung bezogen auf nDSG-Schutzziele.
- Technische Findings: Jeder Angriffspfad dokumentiert mit Evidenz. Mapping auf die relevanten nDSG-Artikel (Art. 7, 8, 24).
- Incident-Response-Bewertung: Wurde der Angriff erkannt? Wann? Von wem? Wie wurde eskaliert?
- Handlungsempfehlungen: Priorisiert nach Risiko. Mit konkreten Umsetzungsschritten und geschätztem Aufwand.
- Compliance-Statement: Formale Einschätzung, inwieweit die geprüften Systeme die Anforderungen nach Art. 7 und Art. 8 nDSG erfüllen.
Dieser Bericht dient als Nachweis gegenüber dem EDÖB. Art. 1 Abs. 5 der Datenschutzverordnung (DSV) verlangt, dass die Sicherheitsmassnahmen «während der gesamten Bearbeitungsdauer überprüft» werden. Ein Red-Teaming-Bericht ist der stärkste Beleg dafür, dass diese Überprüfung stattgefunden hat.
Die persönliche Haftung nach nDSG
Ein Detail, das in vielen Compliance-Diskussionen untergeht: Das nDSG bestraft nicht das Unternehmen, sondern die verantwortliche natürliche Person. Art. 60 bis 63 nDSG sehen Bussen von bis zu CHF 250'000 vor, und diese treffen den Geschäftsführer, den IT-Leiter oder den Datenschutzverantwortlichen persönlich. Die subsidiäre Unternehmenshaftung nach Art. 64 nDSG greift nur, wenn die fehlbare Person nicht identifizierbar ist, und ist auf CHF 50'000 begrenzt.
Was bedeutet das konkret? Wenn ein Angreifer über eine vermeidbare Schwachstelle an Personendaten gelangt und das Unternehmen keinen Nachweis erbringen kann, dass angemessene Schutzmassnahmen implementiert und überprüft wurden, steht die verantwortliche Person persönlich in der Haftung. Ein Red-Teaming-Bericht dokumentiert, dass die Überprüfung stattgefunden hat, welche Schwachstellen gefunden wurden und welche Massnahmen zur Behebung ergriffen wurden. Das ist ein deutlich stärkeres Schutzschild als ein reiner Audit-Bericht, der bestätigt, dass Policies existieren.
Bei FINMA-regulierten Instituten kommt noch eine weitere Ebene hinzu: Die FINMA erwartet eigene Sicherheitstests und kann bei unzureichender IT-Sicherheit aufsichtsrechtliche Massnahmen ergreifen. Ein Red-Teaming-Engagement erfüllt sowohl die nDSG- als auch die FINMA-Anforderungen.
Häufig gestellte Fragen
Ist Red Teaming für nDSG-Compliance nötig oder reicht ein Pentest?
Ein Penetrationstest prüft die technische Sicherheit einzelner Systeme. Red Teaming geht weiter: Es simuliert einen realen Angreifer, der alle Vektoren nutzt, auch Social Engineering und physischen Zugang. Für die nDSG-Compliance nach Art. 8 reicht ein Penetrationstest in den meisten Fällen aus. Wer zusätzlich wissen will, ob das Gesamtsystem und die organisatorischen Prozesse (Art. 24 Meldepflicht) funktionieren, braucht ein Red Team.
Wie oft sollte ein nDSG-fokussiertes Red Teaming durchgeführt werden?
Mindestens alle zwei Jahre für Unternehmen, die besonders schützenswerte Personendaten verarbeiten (Gesundheitsdaten, Finanzdaten, biometrische Daten). Für andere Unternehmen alle drei Jahre, ergänzt durch jährliche Penetrationstests. Nach wesentlichen Systemänderungen oder Sicherheitsvorfällen ist ein zusätzliches Engagement empfehlenswert.
Verursacht Red Teaming Betriebsunterbrechungen?
Nein. Ein professionelles Red-Teaming-Engagement wird so durchgeführt, dass der laufende Betrieb nicht beeinträchtigt wird. Destruktive Aktionen (Datenlöschung, Verschlüsselung) werden nie durchgeführt. Die meisten Engagements laufen ab, ohne dass die Belegschaft etwas bemerkt. Genau das ist der Punkt: Es wird getestet, ob der Angriff erkannt wird.
Kann ein Red Team auch die Meldepflicht nach Art. 24 nDSG testen?
Ja, das ist einer der wertvollsten Aspekte. Im Rahmen eines Red-Teaming-Engagements wird geprüft, ob und wann der Angriff erkannt wird, ob eine Eskalation stattfindet und ob der Meldeprozess an den EDÖB funktioniert. Bei vielen KMU stellen wir fest, dass zwar eine Datenschutzerklärung existiert, aber kein operativer Incident-Response-Prozess. Der Unterschied zeigt sich erst unter Druck.
Was kostet nDSG-fokussiertes Red Teaming?
Ein nDSG-fokussiertes Red-Teaming-Engagement kostet für ein typisches Schweizer KMU zwischen CHF 25'000 und CHF 60'000, abhängig von Scope und Dauer (typisch: 2 bis 4 Wochen aktive Testphase). Das ist eine Investition, die sich rechnet: Die persönliche Busse nach Art. 60 nDSG beträgt bis zu CHF 250'000, und der Reputationsschaden nach einem Datenschutzvorfall mit Personendaten ist schwer zu beziffern, aber real. Details zu den Cyber-Security-Kosten für KMU finden sich in unserem Budget-Guide.
Wer sein nDSG-Compliance-Programm auf ein solides Fundament stellen will, der ergänzt den Audit um einen Red-Teaming-Test. Nicht weil der Auditor schlecht arbeitet, sondern weil ein Auditor eine andere Frage beantwortet. Der Auditor sagt: «Die Policy existiert.» Das Red Team sagt: «Die Policy hält.» Oder eben nicht. Und dann weisst du, wo du stehst, bevor es der EDÖB oder ein Angreifer für dich herausfindet. Lass uns darüber reden.