Zürich hat sich zu einem der dynamischsten Technologie-Ökosysteme Europas entwickelt: ETH Zürich, ein dichtes Netz an Spin-offs, Deep-Tech- und Fintech-Gründungen, internationale Investoren und die Nähe zu regulierten Kunden aus Finanz-, Gesundheits- und Industriesektor. Viele dieser Startups liefern von Anfang an in die EU – und holen sich damit Pflichten ins Haus, die sie am Schweizer Firmensitz nicht erwartet hätten.
Dieser Beitrag zeigt, welche Sicherheits- und Compliance-Anforderungen für Züri-Tech-Startups tatsächlich gelten, wo die typischen Lücken liegen und wie sich die Anforderungen in einem statt in drei Projekten abdecken lassen.
Der blinde Fleck: Wachstum vor Governance
Die Stärke des Standorts ist unbestritten. Der strukturelle blinde Fleck ist ebenso typisch: Junge Unternehmen priorisieren Produkt und Wachstum, Informationssicherheit und Governance gelten als Thema für die Phase nach der nächsten Finanzierungsrunde.
Das ist verständlich – und riskant. Die Rechnung kommt nicht erst beim Sicherheitsvorfall, sondern früher: beim Lieferantenfragebogen des ersten Enterprise-Kunden, bei der NIS-2-Vertragsklausel eines deutschen Abnehmers oder in der Due Diligence der Series A. Wer dann keinen strukturierten Nachweis vorlegen kann, verliert Zeit, Bewertung oder den Auftrag. Mehr dazu, warum ein angekreuzter Fragebogen nichts beweist: Lieferantenfragebögen als Scheinsicherheit.
Die Bedrohungslage: Identitäten, Code und Lieferkette statt Perimeter
Das Sicherheitsmodell mit einer klar definierten Netzwerkgrenze trägt für Cloud-native Startups nicht. Angriffsziele sind Identitäten, Daten und der Code selbst. Drei Punkte sind für Zürcher Tech-Startups besonders relevant:
- Non-Human Identities. API-Keys, Service Accounts, CI/CD-Tokens und Deployment-Pipelines erzeugen eine Vielzahl maschineller Identitäten, die selten denselben Regeln unterliegen wie Benutzerkonten. Ein kompromittierter API-Key mit weitreichenden Rechten richtet denselben Schaden an wie ein Admin-Konto – wird aber oft weder rotiert noch überwacht.
- Lieferkette. Startups bauen auf Open-Source-Komponenten, SaaS-Dienste und wenige Cloud-Anbieter. Eine Schwachstelle in einer Abhängigkeit trifft sie direkt – und ohne Asset- und Softwareinventar wissen sie im Ernstfall nicht einmal, ob sie betroffen sind. Wie das in der Praxis aussieht, zeigt PHP2Shell.
- Abhängigkeit von Schlüsselpersonen und Einzelsystemen. Ein Datenbankausfall, ein gesperrter Cloud-Account oder der Ausfall des einzigen Entwicklers, der die Infrastruktur kennt, kann den Betrieb tagelang stoppen.
Angreifer unterscheiden nicht zwischen einem Zürcher Startup mit zehn Mitarbeitenden und einem Konzern. Der Schweizer Standort schützt vor keinem dieser Risiken.
NIS-2: Wie die EU-Richtlinie Schweizer Startups erreicht
Der häufigste Irrtum im Züri-Tech-Umfeld: „Wir sind nicht in der EU, NIS-2 betrifft uns nicht.“ Die Schweiz setzt die Richtlinie tatsächlich nicht um. Praktisch erreicht sie Schweizer Unternehmen trotzdem – auf drei Wegen:
- EU-Tochtergesellschaften. Eine GmbH in Deutschland oder Österreich unterliegt dem jeweiligen nationalen NIS-2-Gesetz, wenn sie Sektor- und Größenschwellen erfüllt – unabhängig von der Schweizer Mutter.
- Lieferkette. Regulierte EU-Einrichtungen müssen nach Art. 21 Abs. 2 lit. d NIS-2 die Sicherheit ihrer Lieferkette managen. Sie reichen die Anforderungen per Vertrag weiter: Sicherheitsmaßnahmen, Auditrechte, Meldepflichten bei Vorfällen. Wer als Zürcher SaaS-Anbieter an eine deutsche Bank, einen Energieversorger oder ein Klinikum liefert, bekommt diese Klauseln vorgelegt. Was Zulieferer erwartet: NIS-2 in der Lieferkette.
- EU-Vertreter für digitale Dienste. Anbieter bestimmter digitaler Dienste – DNS, Cloud-Computing, Rechenzentren, Content Delivery, Managed Services, Online-Marktplätze, Suchmaschinen, soziale Netzwerke – fallen nach Art. 26 NIS-2 unter die Richtlinie, wenn sie Dienste in der EU anbieten, und müssen dort einen Vertreter benennen.
Der Geltungsbereich wird damit durch Kunden und Dienste bestimmt, nicht durch Geographie. Welche Pflichten konkret folgen, zeigt NIS-2 für Unternehmen.
Datenschutz: Schweizer Recht und DSGVO nebeneinander
Zürcher Startups mit Kunden oder Nutzern in der EU bewegen sich im Datenschutz in der Regel in zwei Rechtsordnungen: dem Schweizer Datenschutzrecht und – wegen des Marktortprinzips der DSGVO – zusätzlich dem europäischen. Die Details, insbesondere Meldewege, Fristen und Sanktionen nach Schweizer Recht, gehören in die Hand einer auf Schweizer Datenschutzrecht spezialisierten Kanzlei; wir geben dazu keine Rechtsberatung.
Aus Sicht der Informationssicherheit ist die gute Nachricht: Die technischen und organisatorischen Maßnahmen, die beide Rechtsordnungen voraussetzen – Zugriffskontrolle, Verschlüsselung, Protokollierung, Backup, Umgang mit Vorfällen –, sind dieselben. Wer sie einmal in einem ISMS umsetzt und nachweist, hat die Grundlage für beide Regime gelegt und muss nur noch die rechtliche Dokumentation ergänzen.
ISO 27001 als gemeinsamer Nenner
Drei Regelwerke, drei Projekte? Nicht nötig. Ein Informationssicherheits-Managementsystem (ISMS) nach ISO/IEC 27001:2022 deckt den Kern aller drei Anforderungen gleichzeitig ab:
- die NIS-2-Maßnahmen aus Art. 21 (Risikoanalyse, Incident-Handling, Business Continuity, Lieferkettensicherheit, Zugriffskontrolle, Kryptografie, Schulung) – als Controls im Anhang A;
- die technischen und organisatorischen Maßnahmen, die Datenschutzrecht und Kunden verlangen – über dieselben Controls, ergänzt um die datenschutzrechtliche Dokumentation;
- die Sicherheitsanforderungen aus Kundenverträgen – weil ein Zertifikat genau der Nachweis ist, den Einkauf und Auditoren der Kunden akzeptieren.
Vollständig deckungsgleich sind die Regelwerke nicht. NIS-2 bringt Pflichten mit, die ISO 27001 nicht kennt: das gestufte Melden an die Behörde (24 Stunden Erstmeldung, 72 Stunden Update, Abschlussbericht nach einem Monat), die Registrierung und die persönliche Verantwortung der Geschäftsleitung.Diese Deltas lassen sich aber als Erweiterung des ISMS abbilden – nicht als eigenes Projekt.
Die praktische Empfehlung: eine integrierte Gap-Analyse, die NIS-2, Datenschutz- und Kundenanforderungen und ISO 27001 in einer Matrix abbildet. Überschneidungen werden einmal umgesetzt, echte Deltas gezielt ergänzt. Wer an deutsche Behörden liefert, kann den BSI IT-Grundschutz als zusätzliche Anforderung einplanen; er lässt sich mit ISO 27001 kombinieren, ohne Parallelstrukturen aufzubauen.
Business Continuity: kein Konzernthema
Business Continuity Management gilt in Startup-Teams als etwas für große Organisationen mit eigener IT-Abteilung. Das Gegenteil ist richtig: Schlanke Teams ohne Redundanz und mit wenigen kritischen Systemen sind bei Ausfällen besonders exponiert. NIS-2 verlangt von betroffenen Einrichtungen ausdrücklich Backup-Management, Wiederherstellung und Krisenmanagement – und EU-Kunden reichen genau diese Punkte in ihren Fragebögen weiter.
Ein proportionaler Einstieg für Teams unter zwanzig Personen ist überschaubar: die drei bis fünf kritischsten Abhängigkeiten benennen (Cloud-Anbieter, Datenbank, Identity Provider, Schlüsselpersonen), für jede Wiederanlaufzeit und Verantwortliche festlegen, Backups tatsächlich testen und einen Notfallplan auf wenigen Seiten schreiben – und einmal im Jahr durchspielen. Als Teil des ISMS entsteht das ohne zusätzlichen Dokumentationsapparat. Warum Notfallpläne allein nicht reichen: BCM-Grundlagen.
Was Investoren und Käufer in der Due Diligence prüfen
Sicherheitsreife ist in Finanzierungsrunden und bei Übernahmen zum Prüfgegenstand geworden. Erwerber und Investoren wollen keine Überraschungen nach dem Closing – und Sicherheitsvorfälle, offene Datenschutzrisiken oder fehlende Nachweise gegenüber Kunden gehören zu den teuersten. Typische Prüfpunkte einer Security Due Diligence:
- Existiert ein ISMS, idealerweise zertifiziert, mit definiertem Geltungsbereich?
- Wie werden Zugriffe, Secrets und maschinelle Identitäten verwaltet und überprüft?
- Gibt es einen Incident-Response-Plan – und wurde er geübt?
- Sind Backup und Wiederherstellung dokumentiert und getestet?
- Welche vertraglichen Sicherheitszusagen gegenüber Kunden bestehen, und werden sie eingehalten?
- Welche Datenschutzrisiken bestehen – nach Schweizer Recht und, bei EU-Kunden, nach DSGVO?
Entscheidend sind in jedem Punkt Nachweise aus dem Betrieb – Protokolle, Berichte, Testergebnisse –, nicht Richtlinien auf Papier. Startups, die früh in ein auditierbares Sicherheitsframework investieren, verkürzen Due-Diligence-Phasen, vermeiden Bewertungsabschläge und verhandeln aus einer stärkeren Position. Was ein unabhängiger Blick auf das eigene System leistet, beschreibt Internes Audit nach ISO 27001.
Externer CISO: Sicherheitsreife ohne Vollzeitstelle
Ein interner CISO ist für die meisten Startups weder wirtschaftlich noch zeitlich realistisch – Rekrutierung und Einarbeitung dauern Monate, und Investorenkapital gehört ins Produkt. Ein externes Mandat beginnt sofort, kostet einen Bruchteil und skaliert mit dem Reifegrad:
- als externer Informationssicherheitsbeauftragter mit festem Pensum, der an die Geschäftsleitung berichtet;
- als Projektleitung einer ISO-27001-Zertifizierung vom Geltungsbereich bis zum Stage-2-Audit;
- als operativer Umsetzer eines NIS-2- oder Kundenanforderungs-Maßnahmenpakets;
- als unabhängiger interner Auditor, sobald das ISMS steht.
Die Verantwortung bleibt bei der Geschäftsleitung; die Vorbereitung und Umsetzung werden delegiert. Wie das Modell funktioniert: Externer ISB und DSB.
Fazit: In dieser Reihenfolge handeln
- Betroffenheit klären. Welche Kunden, Dienste und Tochtergesellschaften bringen NIS-2 ins Haus? Welche Datenschutz- und Kundenanforderungen gelten? Eine Gap-Analyse liefert in wenigen Wochen ein klares Bild.
- Ein ISMS statt drei Projekte. ISO 27001 als Rahmen, NIS-2-, Datenschutz- und Kundendeltas als Erweiterung.
- BCM von Anfang an einbauen. Kritische Abhängigkeiten, Wiederanlaufzeiten, getestete Backups – proportional zur Größe.
- Nachweise sammeln, bevor jemand fragt. Due Diligence, Lieferantenaudit und Zertifizierung verlangen dieselben Belege.
- Verantwortung besetzen. Intern oder als externes Mandat – aber benannt, mit Pensum und Berichtsweg.
Cybersecurity ist für Züri-Tech-Startups keine Kostenstelle, sondern Eintrittsbedingung für Enterprise-Kunden, EU-Märkte und die nächste Finanzierungsrunde. Wer früh strukturiert vorgeht, zahlt einmal – wer wartet, zahlt im Deal.
