Newsletter Anmeldung

Bleiben Sie mit dem Newsletter immer up to date.

Anfrage
arrow-to-top

Gilt der Cyber Resilience Act auch für Schweizer Unternehmen?

03/2026 – Fachartikel Swiss Infosec AG

Was Schweizer Hersteller und Softwareanbieter jetzt tun müssen

Schweizer Hersteller digitaler Produkte und Softwareentwicklungsunternehmen, die ihre Lösungen im EU-Markt anbieten, stehen ab 2026 vor handfesten Pflichten. Die kritischste operative Deadline ist der 11. September 2026: Ab dann gelten verbindliche Meldepflichten für Schwachstellen und Sicherheitsvorfälle. Wer nicht vorbereitet ist, riskiert Bussgelder bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes und im schlimmsten Fall den Verlust des EU-Marktzugangs.

Dieser Artikel gibt einen praxisnahen Überblick über den CRA, erklärt die wichtigsten Fristen und zeigt auf, was Schweizer Anbieter von Software oder digitalen Produkten jetzt konkret unternehmen müssen.

Die Swiss Infosec AG unterstützt Unternehmen auf diesem Weg, von der ersten Gap-Analyse bis hin zur fortlaufenden Begleitung eines CRA-konformen Betriebs.

Was ist der Cyber Resilience Act?

Der CRA (Verordnung (EU) 2024/2847) ist das erste horizontale EU-Gesetz, das verbindliche Cybersicherheitsanforderungen für sämtliche Produkte mit digitalen Elementen festlegt. Er ergänzt bestehende Regulierungen wie die NIS-2-Richtlinie und die DSGVO, geht aber in einem entscheidenden Punkt weiter: Er richtet sich direkt an Produkthersteller und greift entlang der gesamten Lieferkette.

Konkret umfasst der CRA:

  • Hardware und Software, die direkt oder indirekt mit einem Netzwerk oder Gerät verbunden werden können
  • IoT-Geräte wie Smart-Home-Produkte, Wearables und industrielle Steuerungssysteme
  • Standalone-Software wie Betriebssysteme, Buchhaltungslösungen, mobile Apps und Sicherheitswerkzeuge
  • Eingebettete Systeme in Maschinen, Fahrzeugen und Infrastruktur

Ausgenommen sind Produkte unter sektorspezifischen EU-Verordnungen (Medizinprodukte, zivile Luftfahrt, nationale Sicherheit) sowie nicht-kommerzielle Open-Source-Software ohne Gewinnerzielungsabsicht.

Gilt der CRA auch für Schweizer Unternehmen?

Kurz gesagt: Ja. Der CRA ist eine EU-Marktregulierung. Wer Produkte mit digitalen Elementen in der EU in Verkehr bringt, muss die Anforderungen des CRA erfüllen, unabhängig vom Firmensitz. Das betrifft insbesondere:

  • Hersteller digitaler Software- oder Hardwareprodukte, die in der EU vertrieben werden
  • Exporteure in die EU, die für die Konformität der Produkte geradestehen müssen
  • Händler, die sicherstellen müssen, dass nur CRA-konforme Produkte in den EU-Markt gelangen
  • Schweizer Cloud-Dienstleister, deren Cloud Services unter bestimmten Bedingungen ebenfalls in den Anwendungsbereich fallen können

EU-Vertreter

Schweizer Unternehmen ohne EU-Niederlassung sind zusätzlich verpflichtet, bis zum 11. Dezember 2027 einen bevollmächtigten Vertreter in der EU (Authorised Representative) zu benennen. Diese Stelle übernimmt die Kommunikation mit Marktüberwachungsbehörden, hält die technische Dokumentation bereit und stellt sicher, dass Behördenanfragen fristgerecht beantwortet werden. Schon heute übernimmt die Swiss Infosec AG EU-Vertretermandate gemäss EU-DSGVO im Auftrag für ihre Kundinnen und wird dies künftig auch für die EU-Vertretung nach CRA tun.

CRA-Pendant in der Schweiz

Der Bundesrat hat eine Aussprache geführt und das Bundesamt für Cybersicherheit (BACS) beauftragt, in Zusammenarbeit mit dem Bundesamt für Kommunikation (BAKOM) und dem Staatsekretariat für Wirtschaft (SECO) bis Herbst 2026 eine Vernehmlassungsvorlage zur «Schaffung einer Gesetzgebung zur Cyberresilienz von digitalen Produkten» zu erarbeiten. Die neuen gesetzlichen Grundlagen sollen die Vorschriften zur Cybersicherheit bei der Entwicklung und dem Inverkehrbringen von Produkten mit digitalen Elementen festlegen, die Umsetzung der Marktüberwachung dieser Produkte definieren sowie Grundlagen für ein Verbot des Imports und Vertriebs unsicherer Geräte schaffen.

Abgestimmt auf den internationalen Kontext
Bei der Erarbeitung der gesetzlichen Grundlagen soll der internationale Kontext beachtet werden – darunter das europäische Cyberresilienzgesetz («Cyber Resilience Act», CRA). Ziel ist es, eine auf den Wirtschaftsstandort Schweiz angepasste Gesetzgebung zu entwickeln. Dabei soll sichergestellt werden, dass die administrative Belastung der Unternehmen möglichst tief gehalten und dass international tätige Unternehmen aus der Schweiz nicht durch voneinander abweichende Vorgaben zusätzlich belastet werden.  

Der Cyber Resilience Act unterscheidet vier Produktkategorien:

  • Standardkategorie (ca. 90 % aller Produkte): Gewöhnliche Geschäftssoftware, Consumer-Elektronik und Standard-IoT-Geräte. Für diese Kategorie genügt eine Selbstdeklaration des Herstellers (Modul A).
  • Klasse I – Wichtige Produkte: Erhöhtes Risiko, z. B. Passwortmanager, Antivirensoftware, VPNs, Firewalls, Browser. Strengere Konformitätsbewertung erforderlich.
  • Klasse II – Kritische Produkte: Netzwerkmanagementsysteme, industrielle Steuerungen, Smart-Meter-Gateways. Zertifizierung durch notifizierte Stelle zwingend.
  • Kritische Kernprodukte: Besonders kleine Gruppe mit strengsten Anforderungen und verpflichtender externer Bewertung.

Die technischen Kernpflichten

Security by Design und Security by Default

Cybersicherheit muss von Beginn an in die Produktentwicklung integriert sein, nicht als nachträglicher Patch. Das bedeutet: sichere Standardeinstellungen, keine voreingestellten Universalpasswörter, minimale Angriffsflächen und Verschlüsselung sensibler Daten.

Schwachstellenmanagement über den gesamten Produktlebenszyklus

Hersteller sind verpflichtet, einerseits ein wirksames Schwachstellenmanagement zu betreiben, andererseits mit Sicherheitsupdates für ein Produkt über eine Dauer von mindestens fünf Jahren für ein Produkt mit digitalen Elementen bereitzustellen.

Software Bill of Materials (SBOM)

Für jedes Produkt ist eine vollständige Dokumentation aller Softwarekomponenten (SBOM) zu führen – inklusive Drittanbieterkomponenten und Open-Source-Bibliotheken.

Technische Dokumentation und CE-Kennzeichnung

Bis Ende 2027 müssen betroffene Produkte mit einer EU-Konformitätserklärung und der CE-Kennzeichnung versehen werden. Ohne diese Kennzeichnung ist der Export in die EU nicht mehr zulässig. Der CRA führt detailliert die Anforderungen an die zu erstellende Dokumentation auf.

Resilienz und Incident Containment

Produkte müssen widerstandsfähig gegen Cyberangriffe sein. Sicherheitsfunktionen dürfen bei einem Angriff nicht vollständig ausfallen. Hersteller müssen Vorfälle schnell eindämmen und betroffene Nutzer informieren können.

Fristen 2026

11. Juni 2026 – Notifizierte Stellen (relevant vor allem für höhere Risikoklassen)

Ab diesem Datum müssen EU-Mitgliedstaaten akkreditierte Konformitätsbewertungsstellen (Notified Bodies) benennen. Für die grosse Mehrheit der Schweizer Softwareentwickler, deren Produkte in die Standardkategorie fallen, ist diese Frist kein unmittelbares Handlungserfordernis: Die Selbstdeklaration erfordert keine notifizierte Stelle. Relevant ist der Termin vor allem für Hersteller von Produkten der Klassen I und II, die frühzeitig Kontakt zu Bewertungsstellen aufnehmen sollten, um Kapazitätsengpässen zuvorzukommen.

11. September 2026 – Meldepflichten (gilt für alle Hersteller)

Dies ist die zentrale und unmittelbarste Pflicht, sie gilt für alle Produktkategorien. Ab diesem Datum sind aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle innerhalb strikter Fristen zu melden:

  • Innerhalb von 24 Stunden: Frühwarnung an die zuständige nationale CSIRT-Behörde und ENISA
  • Innerhalb von 72 Stunden: Detailliertere Folgemeldung mit allen verfügbaren Informationen
  • Innerhalb von 14 Tagen: Abschlussbericht nach Sicherheitsupdate oder Workaround
  • Innerhalb von 30 Tagen: Abschlussbericht bei schwerwiegenden Sicherheitsvorfällen

ENISA richtet dafür eine zentrale Single Reporting Platform ein. Schweizer Hersteller ohne EU-Niederlassung melden über ihren bevollmächtigten EU-Vertreter.

Die Swiss Infosec AG begleitet Unternehmen beim strukturierten Aufbau dieser Prozesse.

Zeitplan im Überblick

DatumMeilenstein
10. Dez. 2024CRA trat in Kraft
11. Juni 2026Notifizierte Stellen aktiv
11. Sep. 2026Meldepflichten für Schwachstellen und Vorfälle
11. Dez. 2026Ausreichend notifizierte Stellen in der EU
11. Dez. 2027Vollständige Anwendung aller CRA-Anforderungen

Was zu tun ist

Die verbleibenden Monate bis September 2026 sind knapp. Die wesentlichen Todo’s umfassen:

Sofort (Q1/Q2 2026):  Produktportfolio analysieren, Risikoklassen bestimmen. Bevollmächtigten EU-Vertreter benennen und Meldeprozesse planen.

Bis Juni 2026:  Technische Dokumentation und Risikoanalyse erstellen. SBOM für alle relevanten Produkte aufbauen. Security by Design in Entwicklungsprozesse integrieren. Für Klasse-I- und Klasse-II-Produkte Kontakt mit Konformitätsbewertungsstellen aufnehmen.

Bis September 2026:  CSIRT-Prozesse aufbauen und kommunizieren. Meldewege zu CSIRT und ENISA einrichten und testen. Patch- und Update-Management sicherstellen. Meldeprozess mit EU-Vertreter koordinieren.

Bis Dezember 2027:  CE-Kennzeichnung und EU-Konformitätserklärung fertigstellen. Lieferkette auf CRA-Compliance prüfen und Zulieferer einbinden.

Spezialfall Open Source

Nicht-kommerzielle Open-Source-Projekte ohne Gewinnerzielungsabsicht sind vom CRA ausgenommen, wobei die Grenze jedoch schmal ist. Sobald Open-Source-Komponenten in kommerzielle Produkte für den EU-Markt einfliessen, trägt der Hersteller die volle CRA-Verantwortung, auch für die verwendeten Drittbibliotheken. Das SBOM-Gebot wird hier zur zentralen Herausforderung.

Sanktionen

Bei schwerwiegenden Verstössen können Marktüberwachungsbehörden Bussgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes verhängen, je nachdem, welcher Betrag höher ist. Bei weniger schwerwiegenden Verstössen liegt die Obergrenze bei 10 Millionen Euro oder 2 % des Umsatzes. Darüber hinaus können Behörden den Verkauf untersagen, Rückrufe anordnen oder Produkte vom Markt nehmen.

Für Schweizer KMU ohne EU-Niederlassung gilt: Wer keinen bevollmächtigten EU-Vertreter benennt, kann seine Produkte ab Dezember 2027 nicht mehr legal in der EU vertreiben. Die Swiss Infosec AG berät bei der Planung und Einrichtung dieses Mandats.

Leistungsangebot Swiss Infosec AG

Der Cyber Resilience Act ist kein fernes Regulierungsprojekt mehr. Mit dem 11. September 2026 greifen die ersten echten Pflichten, und die Zeit zur Vorbereitung wird knapper. Für Schweizer Softwareentwickler und Hersteller, die im EU-Markt aktiv sind oder es bleiben wollen, gibt es keine Alternative zum proaktiven Handeln.

Die Swiss Infosec AG steht als ganzheitlicher CRA-Partner an Ihrer Seite – von der ersten Bestandsaufnahme bis zur laufenden Compliance-Begleitung. Nehmen Sie frühzeitig Kontakt auf: +41 41 984 12 12  |  infosec@infosec.ch

CRA Gap-Analyse und Scoping

Strukturierte Bestandsaufnahme: Welche Produkte fallen unter den CRA? In welche Risikoklasse sind sie einzuordnen? Wo besteht Handlungsbedarf? Ergebnis ist ein priorisierter Massnahmenplan mit klaren Verantwortlichkeiten und Zeitplan.

Aufbau technischer Dokumentation und SBOM

Erstellung und Pflege der CRA-konformen technischen Dokumentation inkl. Risikoanalyse sowie Aufbau einer Software Bill of Materials (SBOM) für alle relevanten Produktkomponenten – strukturiert, nachvollziehbar und behördengerecht.

Schwachstellenmanagement

Konzeption und Implementierung eines CRA-konformen Schwachstellenmanagements inkl. Meldewege zu nationalen CSIRTs und ENISA, Eskalationslogik, Verantwortlichkeiten und Patch-Management.

Security by Design-Beratung

Integration von CRA-konformen Sicherheitsanforderungen in bestehende Entwicklungsprozesse (SDLC): Anforderungsengineering, Threat Modelling, Secure Coding Guidelines und sicherheitsbezogene Reviews.

CRA-Awareness und Schulungen

Massgeschneiderte Schulungen und Workshops für Entwicklungsteams, Produktverantwortliche und Management – als Firmentraining, offenes Seminar oder eLearning.

Legal Compliance Officer as a Service

Übergreifende regulatorische Begleitung im Zusammenspiel von CRA, NIS-2, DSGVO, KI-Gesetz und weiteren EU-Digitalregulierungen – für ein kohärentes Compliance-Gesamtbild ohne blinde Flecken.

CRA-Vertreter-Mandat

Schweizer Hersteller ohne EU-Niederlassung sind per 11. Dezember 2027 gesetzlich verpflichtet, einen bevollmächtigten Vertreter in der EU zu benennen. Dieses Mandat kann durch die Swiss Infosec AG im Auftragsverhältnis wahrgenommen werden. Sie fungiert als Ansprechpartner gegenüber EU-Marktüberwachungsbehörden, koordiniert Meldungen über die ENISA Single Reporting Platform und stellt die erforderliche technische Dokumentation bereit.

Gerne beantworten wir Ihre Fragen rund um den Cyber Resilience Act sowie alle generellen Fragen zu Cyber- und IT-Sicherheit.

Swiss Infosec AG; 24.03.2026
Fachteam IT-Sicherheit, +41 41 984 12 12, infosec@infosec.ch


«Wenn die IT stillsteht, steht oft das ganze Unternehmen still»

03/2026 – Fachartikel Swiss Infosec AG

Ist Ihr IT-Notfallmanagement wirklich bereit?

Die Anzahl als auch die Komplexität von Cyberangriffen und technischen Störungen steigen weiter. Gleichzeitig sind alle kritischen Geschäftsprozesse durchgängig von IT-Services abhängig. In einer vernetzten und digitalisierten Welt sind Unternehmen deshalb gefordert, ihre Widerstandsfähigkeit gegen IT-Notfälle systematisch zu stärken.

Technische und organisatorische Massnahmen zur Abwehr von Cyberangriffen oder technischen IT-Störungen sind zentral und unverzichtbar. Doch sie allein reichen längst nicht mehr aus. Entscheidend ist heute auch, wie schnell und strukturiert eine Organisation im Ernstfall reagiert.

Die Bedeutung eines strukturierten IT-Notfallmanagements wird auch in internationalen Standards und regulatorischen Vorgaben deutlich verankert. Die Norm ISO/IEC 27001 fordert im Kontext der Informationssicherheit unter anderem Massnahmen zur Sicherstellung der Verfügbarkeit von Informationssystemen und zur Planung der Informationssicherheitskontinuität. Auch das NIST Cybersecurity Framework 2.0 adressiert die Vorbereitung auf Störungen und Cybervorfälle. Innerhalb der Funktionen Respond und Recover beschreibt das Framework Prozesse für Incident Response, Wiederherstellung nach Sicherheitsvorfällen sowie die kontinuierliche Verbesserung dieser Massnahmen. Auf Seiten der regulatorischen Behörden fordert etwa das FINMA-Rundschreiben 2023/1 «Operationelle Risiken und Resilienz» explizit das Testen von Business Continuity Plans (BCP) und Disaster Recovery Plans (DRP). Auch auf europäischer Ebene setzt der Digital Operational Resilience Act (DORA) klare Anforderungen an das ICT-Risikomanagement und verlangt regelmässige Tests der operationellen Resilienz.

Vor diesem Hintergrund gewinnt ein strukturiertes IT-Notfallmanagement zunehmend an Bedeutung. Ziel ist es, die Auswirkungen eines IT-Notfalls zu begrenzen und die Handlungsfähigkeit der Organisation auch in Notfällen aufrechtzuerhalten. Ein zentraler Bestandteil eines wirksamen IT-Notfallmanagements ist dessen regelmässige Überprüfung. Hier setzen IT-Notfallübungen an.

Zentrale Bestandteile eines IT-Notfallmanagements

  • Organisatorische Strukturen für die Bewältigung von IT-Notfällen
  • Identifikation kritischer IT-Systeme und -Services
  • Definierte Wiederanlaufverfahren für Systeme und Applikationen
  • Klare Eskalations- und Kommunikationswege
  • Tests, Übungen und Schulungen
  • Kontinuierlicher Verbesserungsprozess (KVP)

Zusammenspiel mit Business Continuity Management (BCM) und Krisenmanagement (KM)

Für eine wirksame Resilienz bei IT-Notfällen ist ein abgestimmtes Zusammenspiel verschiedener Disziplinen erforderlich. Das Business Continuity Management (BCM) fokussiert auf die Aufrechterhaltung und Wiederaufnahme von kritischen Geschäftsprozessen und liefert durch die Business Impact Analysis (BIA) Kennzahlen wie Recovery Time Objective (RTO) und Recovery Point Objective (RPO). Diese Vorgaben fliessen direkt in das IT-Notfallmanagement ein, das sich auf die Wiederherstellung der notwendigen IT-Systeme, Services und Anwendungen konzentriert. Kommt es zu einem schwerwiegenden Ereignis mit organisatorischen oder strategischen Auswirkungen, übernimmt das Krisenmanagement (KM) die übergeordnete Koordination sowie die interne und externe Kommunikation.

IT-Notfallhandbuch als zentrale Dokumentation

Das IT-Notfallhandbuch enthält alle relevanten Informationen, Prozesse und Verantwortlichkeiten im Zusammenhang mit IT-Notfällen. Es stellt sicher, dass im Ernstfall alle Beteiligten auf klar strukturierte und verständliche Handlungsweisen zurückgreifen können.

Das IT-Notfallhandbuch enthält unter anderem…

… eine Beschreibung der Notfallorganisation (Rollen inkl. Aufgaben, Kompetenzen und Verantwortlichkeiten (AKV)

… definierte Eskalationswege und Eskalationsstufen

… Kontaktlisten wichtiger interner und externer Ansprechpartner

… Verweise auf Wiederanlaufpläne und Wiederherstellungspläne

Das IT-Notfallhandbuch muss leicht zugänglich sein, sprich auch bei eingeschränkter Verfügbarkeit der IT-Systeme genutzt werden können. Deshalb sollte sichergestellt werden, dass die relevanten Informationen auch über alternative oder offline verfügbare Quellen abrufbar sind.

Szenarien und Sofortmassnahmen

Neben organisatorischen Abläufen und Wiederanlaufplänen enthält ein IT-Notfallhandbuch in der Regel auch vordefinierte Notfallszenarien mit entsprechenden Sofortmassnahmen. Diese Szenarien beschreiben typische Ereignisse wie etwa einen Ransomware-Angriff, den Ausfall eines zentralen IT-Services, eine Netzwerkstörung oder einen Ausfall eines Cloud-Dienstes. Ziel ist es, den Verantwortlichen im Ereignisfall eine schnelle Orientierung zu geben und erste stabilisierende Massnahmen einzuleiten.

Zu den Sofortmassnahmen können beispielsweise das Isolieren betroffener Systeme, das Aktivieren der Notfallorganisation, die Sicherstellung von Logdaten oder die Information relevanter Stellen gehören. Solche vorbereiteten Handlungsschritte helfen, wertvolle Zeit zu gewinnen und die Situation zu stabilisieren, bevor detaillierte Wiederanlaufpläne zur Wiederherstellung der Systeme umgesetzt werden.

Wiederanlaufpläne

Während das IT-Notfallhandbuch den organisatorischen Rahmen vorgibt, beschreiben Wiederanlaufpläne die konkreten technischen Schritte zur Wiederinbetriebnahme der definierten IT-Services. Diese Pläne orientieren sich häufig an den oben erwähnten Zielwerten wie RTO und RPO und sollten klar strukturiert, ausreichend detailliert und ohne Interpretationsspielraum beschrieben werden, damit sie auch unter Stress und Zeitdruck umsetzbar sind.

Ausgangspunkt ist dabei der kritische Geschäftsprozess, aus dem abgeleitet wird, welche IT-Services für dessen Betrieb erforderlich sind. Anschliessend werden die technischen Komponenten identifiziert, welche diese Services unterstützen, beispielsweise Applikationen, Datenbanken, Server, Netzwerke oder Cloud-Dienste. Dieses strukturierte Mapping ermöglicht es, Abhängigkeiten zu verstehen und im Notfall die Wiederherstellung in der richtigen Reihenfolge zu priorisieren.

Kommunikation im Notfall

Neben technischen Wiederherstellungsprozessen spielt auch die Kommunikation im Notfall eine zentrale Rolle. Unklare oder verzögerte Kommunikation kann die Bewältigung eines Vorfalls erheblich erschweren und zusätzliche Risiken für die Organisation schaffen.

Der Kommunikationsplan beantwortet folgende Fragen:

  • Wer muss im Ereignisfall informiert werden?
  • Welche Eskalationsstufen gelten?
  • Wie werden Informationen zwischen IT, Management und Fachbereichen ausgetauscht?
  • Welche Kommunikationskanäle werden im Notfall genutzt?

Im Rahmen eines IT-Notfalls erfolgt die operative Kommunikation in der Regel durch das IT-Notfallmanagement, beispielsweise gegenüber betroffenen Fachbereichen, IT-Teams oder internen Stakeholdern. Weitet sich ein Ereignis zu einer organisatorischen Krise aus, übernimmt das Krisenmanagement die übergeordnete Koordination der internen und externen Kommunikation. Das IT-Notfallmanagement bleibt in diesem Fall weiterhin für die fachliche und operative Kommunikation im Zusammenhang mit der Wiederherstellung der IT-Services verantwortlich.

IT-Notfallübungen

Ein strukturiertes IT-Notfallmanagement definiert, wie Organisationen auf schwerwiegende IT-Störungen reagieren sollen. Doch Pläne allein garantieren noch keine Handlungsfähigkeit im Ernstfall.

Erst durch regelmässige IT-Notfallübungen wird überprüft, ob Prozesse, Rollen und technische Wiederherstellungsverfahren tatsächlich funktionieren.

Ziele von IT-Notfallübungen

  • Überprüfen der Wirksamkeit von Notfall- und Wiederanlaufplänen.
    Funktionieren die vorhandenen Prozesse und Massnahmen wie geplant?
  • Verbesserung der Zusammenarbeit und Kommunikation im Notfall.
    Rollen, Eskalationswege und Entscheidungsbefugnisse werden geübt und abgestimmt.
  • Identifikation von Schwachstellen in Technik, Organisation und Prozessen.
    Übungen decken Lücken auf, welche im Notfall Verzögerungen verursachen und teuer werden können.
  • Sensibilisierung und Training der Mitarbeitenden.
    Alle Beteiligten lernen, wie sie im Notfall reagieren müssen. Geübte Abläufe funktionieren unter Druck verlässlich.
  • Erfüllung von regulatorischen und auditrelevanten Anforderungen.
    Nachweise gegenüber Behörden und Auditoren durch dokumentierte Übungen und Lessons Learned.

Definition von Scope, Szenario und Kennzahlen

Das Warum sollte geklärt sein und dem Management ist der Mehrwert dieser Übungen bewusst. Dann stellt sich nun die Frage: Was genau wollen wir wie testen?

Der Scope kann sich auf einzelne Systeme oder Applikationen beschränken, einen bestimmten Geschäftsprozess umfassen oder auch mehrere Organisationseinheiten einbeziehen. Besonders effektiv sind Übungen, die sich an kritischen Geschäftsprozessen orientieren. Ebenso kann entschieden werden, ob ausschliesslich interne Beteiligte einbezogen werden oder ob auch externe Stellen wie IT-Dienstleister oder Behörden simuliert werden sollen.

Das Szenario sollte realistisch, nachvollziehbar und dem jeweiligen Risiko- und Bedrohungsbild des Unternehmens angepasst sein. Die Spannbreite reicht von einem klassischen Ransomware-Angriff über den Ausfall eines Cloud-Dienstes bis hin zu gezielten Insider-Attacken oder einem weitreichenden Kommunikationsausfall. Ein realistisches Szenario fördert die Akzeptanz der Beteiligten und trägt damit wesentlich zum Erfolg der Übung bei.

Mögliche Lageentwicklungen sind im Vorfeld der Übung zu definieren und können dann während der Übung gezielt eingespielt werden. Hier gilt die Prämisse, die Teilnehmenden nicht zu überfordern, aber auch nicht zu unterfordern. Entsprechend braucht es ein wenig Fingerspitzengefühl und Kreativität beim Erarbeiten und Einspielen von möglichen Lageentwicklungen.

Um den Erfolg der Übung messen zu können, braucht es definierte Kennzahlen (KPIs). Beispiele für solche KPIs sind etwa die Einhaltung bestimmter Reaktions- und Wiederherstellungszeiten, die korrekte Eskalation gemäss Notfallplan, oder die interne und externe Kommunikation innerhalb eines bestimmten Zeitfensters. Je klarer diese Ziele im Vorfeld formuliert sind, desto einfacher ist später die Auswertung und Ableitung von Verbesserungsmassnahmen.

Methodik

Für die Durchführung von IT-Notfallübungen stehen verschiedene Methoden zur Auswahl. Diese unterscheiden, wie realistisch, effektiv und effizient eine IT-Notfallübung durchgeführt werden kann.

Methode Beschreibung Komplexität Vorteile Nachteile
Icon Walkthrough
Walkthrough
Gemeinsames Durchgehen eines Notfallprozesses in kleiner Runde, meist ohne konkretes Szenario. Fokus auf Verständnis, Rollenklärung und Dokumentation. Tief
  • Sehr niedrigschwellig
  • Gut für erste Tests
  • Ideal zur Schulung neuer Mitarbeitender
  • Keine Dynamik
  • Keine echte Stresssituation
  • Keine Reaktion auf Ereignisse
Icon Tabletop
Tabletop
Szenariobasiertes Planspiel mit fiktiver Lage. Mittel
  • Fördert Kommunikation
  • Unterstützt Eskalation und Entscheidungsfindung
  • Geeignet für Management und Krisenstab
  • Kein Technikbezug
  • Erkenntnisse bleiben theoretisch
Icon Technische Tests einzelner Systeme
Technische Tests einzelner Systeme
Isolierte Tests von Backups, Failover, Logging oder Wiederherstellungsverfahren in einzelnen Systemen oder Umgebungen. Mittel
  • Prüft konkrete technische Massnahmen realistisch
  • Einfach planbar
  • Kein Gesamtüberblick
  • Organisatorische Abläufe bleiben ungetestet
Icon Integraler Prozesstest
Integraler Prozesstest
Übung eines gesamten Incident- oder Notfallprozesses über mehrere Stationen hinweg. Hoch
  • Ganzheitlicher Ansatz
  • Sehr praxisnah
  • Deckt Schwachstellen im Zusammenspiel auf
  • Hoher Aufwand
  • Bedarf an Koordination
  • Kann das Tagesgeschäft beeinträchtigen
Icon DR-Test
DR-Test
Test der Wiederherstellung nach einem Ausfall, z. B. durch Umschalten auf Backup-Systeme oder Wiederanlauf im Ersatzrechenzentrum. Sehr hoch
  • Prüft Business Continuity realitätsnah
  • Technische Resilienz wird sichtbar
  • Riskant bei mangelnder Vorbereitung
  • Erfordert Testumgebung oder klare Abgrenzung zur Produktion

KVP

Der grösste Mehrwert der IT-Notfallübung entsteht im Nachgang. Durch eine strukturierte Auswertung und dem Ableiten von konkreten Verbesserungsmassnahmen (und natürlich auch deren konsequenter Umsetzung) kann die Maturität der Notfallpläne deutlich gesteigert werden. Weiter sollten die Erkenntnisse auch in verwandte Bereiche wie ISMS und BCM einfliessen.

Gerne beantworten wir Ihre Fragen rund um ihr IT-Notfallmanagement sowie alle generellen Fragen zu Cyber- und IT-Sicherheit.

Swiss Infosec AG; 12.03.2026
Fachteam IT-Sicherheit, +41 41 984 12 12, infosec@infosec.ch


© Swiss Infosec AG 2026