NIS2 in der Praxis – Umsetzungsleitfaden für IT, Security und Management

Einleitung

Kaum hat sich die IT-Welt von der DSGVO erholt, klopft mit NIS2 das nächste EU-Regelwerk an die Tür – und plötzlich macht sich kollektive Nervosität breit. IT-Leiter wischen sich den Angstschweiß von der Stirn, Geschäftsleitungen fragen mit besorgter Miene: „Sind wir denn schon NIS2-konform?“. Was vor Kurzem nur Experten ein Begriff war, ist nun in aller Munde und treibt gestandenen Admins die Sorgenfalten auf die Stirn.

Warum all die Aufregung gerade jetzt? Nun, die NIS2-Richtlinie ist kein gemütlicher Empfehlungszettel, sondern ein verpflichtendes Cybersecurity-Maßnahmenpaket der EU. Nach ihrer Verabschiedung Anfang 2023 mussten alle EU-Staaten sie bis Oktober 2024 in nationales Recht gießen – und jetzt, da diese Frist verstrichen ist, wird es ernst. In Deutschland hat der Bundestag im November 2025 die Umsetzung beschlossen; das neue Gesetz tritt voraussichtlich Anfang 2026 in Kraft, und zwar ohne große Schonfrist. Mit anderen Worten: NIS2 wird vom trockenen EU-Amtsblatt zur konkreten Checkliste, an der sich Unternehmen hierzulande messen lassen müssen. Das sorgt verständlicherweise für Unruhe: Nach jahrelangem „Weiter so“ in Sachen IT-Sicherheit steht plötzlich eine gesetzliche Nagelprobe bevor. Ähnlich wie einst bei der DSGVO drohen nun hohe Bußgelder und formelle Pflichten, aber diesmal geht es nicht um Datenschutz, sondern um die Absicherung kritischer Systeme und Netzwerke.

In diesem Leitfaden schauen wir uns praxisnah an, was hinter NIS2 steckt und wie man den Anforderungen ohne Schnappatmung gerecht werden kann. Stellen Sie sich diesen Artikel als den Rat eines erfahrenen IT-Security-Beraters vor, der die Lage mit einem Augenzwinkern erläutert, aber kein Blatt vor den Mund nimmt. Wir gehen die Grundlagen durch, beleuchten den rechtlichen Rahmen in EU und Deutschland und – das Wichtigste – zeigen, was Unternehmen konkret tun müssen. Vom IT-Administrator bis zum CISO, vom CIO bis zum Compliance-Verantwortlichen: Alle bekommen handfeste Tipps, wie NIS2 in der Praxis umzusetzen ist.

Keine Sorge: Wir ersparen Ihnen juristische Paragrafenreiterei und konzentrieren uns auf die praktische Umsetzung. Bildhafte Beispiele aus dem IT-Alltag, ein paar humorvolle Vergleiche und ein klarer roter Faden sollen dabei helfen, das Thema greifbar zu machen. Dieser Artikel ist ausdrücklich keine Rechtsberatung, sondern eine fachliche Einordnung aus IT- und Umsetzungsperspektive. Also schnallen Sie sich an – NIS2 kommt, aber mit dem richtigen Ansatz müssen weder IT-Abteilung noch Management die Nerven verlieren.

Grundlagen von NIS2 – Was steckt dahinter?

Beginnen wir mit den Basics: Was ist NIS2 überhaupt? Die Abkürzung steht für die zweite EU-Richtlinie über die Sicherheit von Netz- und Informationssystemen (englisch Network and Information Security Directive). Es handelt sich um den Nachfolger der ersten NIS-Richtlinie von 2016. Damals legte NIS1 den Grundstein, indem sie erstmals EU-weit Mindeststandards für die Cybersecurity kritischer Sektoren vorschrieb. Doch die Bedrohungslage hat sich seitdem dramatisch weiterentwickelt – man denke an immer dreistere Ransomware-Angriffe, gehackte Krankenhäuser oder lahmgelegte Lieferketten. Die EU zog daraus die Konsequenz: NIS2 soll die Schrauben deutlich enger ziehen und die Resilienz (Widerstandsfähigkeit) von Unternehmen und staatlichen Stellen gegenüber Cyberangriffen auf ein neues Level heben.

Ziel und Inhalt: NIS2 strebt ein „hohes gemeinsames Cybersicherheitsniveau“ in Europa an. Hinter dieser Floskel steckt konkret: Alle relevanten Organisationen sollen bestimmte Sicherheitsmaßnahmen umsetzen und schwere IT-Sicherheitsvorfälle melden müssen. Die Richtlinie schafft einen einheitlichen Rechtsrahmen, damit nicht jedes EU-Land eigene, voneinander abweichende Cybersecurity-Regeln bastelt. Harmonisierung ist das Stichwort – schließlich machen Cyberattacken nicht an Ländergrenzen halt. Zudem hat man aus NIS1 gelernt, dass zu vage Vorgaben und nationale Spielräume oft zu laschen Umsetzungen geführt haben. NIS2 wird daher detaillierter und strenger: Es benennt klarere Pflichten und sanktioniert Verstöße spürbar.

Wen betrifft NIS2? Die Richtlinie richtet sich an eine breite Palette von Sektoren und Betrieben – weit über die klassischen „KRITIS“ (kritische Infrastrukturen) hinaus. Man unterscheidet grob zwischen wesentlichen (“essential”) und wichtigen (“important”) Einrichtungen. Dazu gehören zum Beispiel:

• Essential (wesentlich): Energieversorgung (Strom, Öl, Gas), Transport (Luft, Bahn, Schiff, Straße), Banken und Finanzmarkt-Infrastruktur, Gesundheitswesen (Krankenhäuser, Pharma-Hersteller, Medizinprodukte), Trinkwasser und Abwasser, Digitale Infrastruktur (Telekommunikation, Cloud-Services, Rechenzentren, DNS), öffentliche Verwaltung auf höherer Ebene, Raumfahrt-Infrastruktur.
• Important (wichtig): Post- und Kurierdienste, Abfallwirtschaft, Chemieindustrie, Lebensmittelversorgung und -produktion, Herstellung kritischer Güter (z.B. medizinische Geräte, Elektronik), weitere Digital-Dienste (Online-Marktplätze, Suchmaschinen, soziale Netzwerke), Forschungseinrichtungen und Teile des verarbeitenden Gewerbes.

Damit zeichnet sich ab: NIS2 erfasst deutlich mehr Unternehmen als sein Vorgänger. Ein mittelständischer Maschinenbauer oder ein IT-Dienstleister konnten NIS1 oft ignorieren – jetzt könnten sie unter NIS2 fallen, sofern sie eine gewisse Größe erreichen. Als Faustregel gilt EU-weit: Unternehmen mit mindestens 50 Mitarbeitern oder 10 Mio. Euro Jahresumsatz und tätig in einem der definierten Sektoren müssen sich mit NIS2 befassen. Einige besonders kritische Bereiche (etwa Telekommunikation oder Cloud-Anbieter) sind unabhängig von der Größe erfasst. Wer außerhalb der EU sitzt, aber in der EU Dienstleistungen in den betroffenen Branchen erbringt (z.B. ein US-Cloudanbieter in Europa), muss ebenfalls einen Vertreter in der EU benennen und die Regeln einhalten.

Was steckt inhaltlich dahinter? Im Kern verlangt NIS2 zwei große Dinge von den Unternehmen: erstens robuste Cybersicherheitsmaßnahmen im Alltag, und zweitens ein Meldesystem für Sicherheitsvorfälle an die Behörden. Hinzu kommen Anforderungen an die Organisation und Leitung: Die Geschäftsführung muss Verantwortung übernehmen, Risiken managen und Cybersecurity zur Chefsache machen. Die Richtlinie formuliert Grundprinzipien wie „Stand der Technik“ und risikobasierte Maßnahmen, ohne jedes technische Detail vorzuschreiben – es geht also nicht darum, ein bestimmtes Fabrikat von Firewall zu kaufen, sondern darum, ein angemessenes Schutzniveau zu erreichen.

Um ein Gefühl für NIS2 zu bekommen, kann man es so sehen: Die EU verordnet einen Cyber-Sicherheits-TÜV. So wie Autos regelmäßig zum TÜV müssen, sollen Unternehmen nun ihre IT-Sicherheit auf Vordermann bringen. Wer schludert, riskiert Unfälle – hier in Form von Datenpannen oder Systemausfällen – und muss mit empfindlichen Strafen rechnen. NIS2 schafft damit eine verbindliche Grundlage, auf die sich Aufsichtsbehörden berufen können, um bei Unternehmen nachzufragen: „Zeigen Sie uns, wie Sie Ihre digitale Schützausrüstung angelegt haben.“

Kurz gesagt: Hinter NIS2 steckt die Absicht, Europas Wirtschaft und Gesellschaft vor den realen Gefahren der digitalen Welt besser zu schützen. Vom einzelnen Mittelständler bis zum großen Energieversorger sollen alle ein Mindestmaß an Cybersecurity praktizieren. Das ist der große Bogen, den wir uns als Nächstes im rechtlichen Rahmen und den praktischen Pflichten genauer anschauen.

Rechtlicher Rahmen & Aufsicht in der EU und in Deutschland

EU-Richtlinie vs. nationales Gesetz: NIS2 ist als EU-Richtlinie konzipiert. Das bedeutet, sie gibt den Mitgliedstaaten einen inhaltlichen Rahmen vor, der dann in jedem Land durch nationale Gesetze umgesetzt werden muss. Im Gegensatz zu einer EU-Verordnung (die direkt gilt), musste also jedes EU-Land eigene NIS2-Gesetze erlassen – was naturgemäß etwas Zeit und Interpretationsspielraum ließ. Ziel war dennoch, die Regeln weitgehend zu vereinheitlichen: Definitionen von Sektoren, Schwellenwerte und Strafrahmen sind durch NIS2 überall ähnlich, damit kein Land deutlich hinterherhinkt. Auf EU-Ebene koordiniert die Agentur für Cybersicherheit ENISA viele Aspekte, und es wurden Gremien wie das EU-CyCLONe für den länderübergreifenden Krisenfall geschaffen. Übersetzt heißt das: Bei großen Vorfällen, die mehrere Länder betreffen, sollen die Behörden besser zusammenarbeiten können. Die EU will sozusagen eine „Allianz der Cyber-Feuerwehren“ schmieden, um im Ernstfall grenzübergreifend Löscheinsätze zu koordinieren.

Nationale Aufsicht: In jedem EU-Land wurde eine zuständige Behörde benannt, die die Einhaltung von NIS2 überwacht. In Deutschland ist dies wie erwartet das Bundesamt für Sicherheit in der Informationstechnik (BSI). Bislang war das BSI vor allem für klassische KRITIS-Unternehmen Aufsichtsorgan. Durch NIS2 kommen nun aber viele weitere Firmen unter BSI-Aufsicht, insbesondere mittelständische Unternehmen aus der Industrie und dem Digitalbereich, die zuvor wenig mit Behördenkontakt in Sachen Cybersecurity hatten. Ähnliche Entwicklungen gibt es in Österreich, wo eine Aktualisierung des Netz- und Informationssystemsicherheitsgesetzes (NISG) ansteht, und in der Schweiz beobachtet man die EU-Regeln aufmerksam – auch wenn die Schweiz als Nicht-EU-Land formal nicht darunter fällt, setzen viele Schweizer Unternehmen freiwillig auf vergleichbare Standards, vor allem wenn sie EU-Kunden haben.

Deutschland im Fokus: Deutschland hat die NIS2-Vorgaben Ende 2025 in nationales Recht gegossen. Kernstück ist das neue NIS2-Umsetzungsgesetz, das insbesondere das bestehende BSI-Gesetz (BSIG) grundlegend überarbeitet. Wichtig zu wissen: Es gibt keine längeren Übergangsfristen – sobald das Gesetz in Kraft tritt (erwartet Anfang 2026), gelten die Pflichten. Unternehmen müssen sich also zügig darauf einstellen. Das Gesetz erweitert den Adressatenkreis deutlich: Hatte das bisherige IT-Sicherheitsgesetz vor allem Betreiber „kritischer Infrastrukturen“ (KRITIS) im Visier, so erstreckt sich der Anwendungsbereich nun auf eine breite Liste von Sektoren, analog zu den NIS2-Annexen. Ein Unternehmen fällt darunter, wenn es in einem der genannten Sektoren tätig ist und mindestens als mittleres Unternehmen einzustufen ist (also über 50 Mitarbeiter oder über 10 Mio. € Umsatz/Bilanzsumme). Einige Sektoren (z.B. Telekommunikation, digitale Dienste) sind sogar größenunabhängig erfasst. Das deutsche Gesetz spricht von „wichtigen“ und „besonders wichtigen Einrichtungen“ – das entspricht den Important und Essential Entities aus NIS2. Erstere (wichtige) unterliegen einer etwas moderateren Aufsicht (in der Regel nur bei Vorfällen oder Hinweisen aktiv), während die „besonders wichtigen“ einer proaktiven Überwachung durch das BSI unterstehen (inklusive regelmäßiger Prüfungen).

Neu ist in Deutschland auch eine Registrierungspflicht: Wer in den Anwendungsbereich fällt, muss sich innerhalb von drei Monaten bei einer gemeinsamen Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) registrieren und eine offizielle Kontaktperson benennen. Mit dieser Registrierung meldet man sich quasi bei der Behörde „zum Dienst“ – sie sollte also nicht vorschnell erfolgen, solange man sich der Einstufung nicht sicher ist.

Aufsicht und Durchsetzung: Die Befugnisse der Behörden wurden deutlich ausgebaut. Das BSI und co. dürfen nun umfassend Anordnungen, Prüfungen und Nachweisanforderungen stellen. Im Klartext: Es kann passieren, dass das BSI von einem betroffenen Unternehmen Unterlagen einfordert – zum Beispiel Sicherheitskonzepte, Risikoanalysen, Nachweise über durchgeführte Audits – oder sogar Vor-Ort-Prüfungen und technische Tests (wie Schwachstellenscans) anordnet. Bei Mängeln können Verfügungen erlassen werden (à la „Beheben Sie binnen 3 Monaten diese Sicherheitslücke“). Im Extremfall darf die Behörde auch den Betrieb bestimmter IT-Systeme untersagen oder einschränken, bis Sicherheitsauflagen erfüllt sind. Diese Eingriffsrechte sind in etwa vergleichbar mit denen der Datenschutzaufsicht unter der DSGVO, nur eben für Cybersecurity.

Bußgelder und Haftung: Natürlich gibt es auch einen Sanktionsrahmen, der Unternehmen und Verantwortliche zum Einhalten motivieren soll. NIS2 gibt hier Obergrenzen vor, die Deutschland 1:1 übernommen hat: Besonders wichtige Einrichtungen riskieren Geldstrafen bis zu 10 Mio. € oder 2 % des weltweiten Jahresumsatzes, je nachdem was höher ist. Wichtige Einrichtungen können mit bis zu 7 Mio. € oder 1,4 % des weltweiten Jahresumsatzes belangt werden. Diese Summen ähneln dem, was man von der DSGVO kennt, und sind für viele Mittelständler ein starkes Druckmittel, das man nicht ignorieren kann. Doch damit nicht genug: Die deutsche Umsetzung betont, dass auch die Geschäftsleitung persönlich in die Pflicht genommen wird. Wenn ein Unternehmen die vorgeschriebenen Sicherheitsmaßnahmen grob vernachlässigt, können theoretisch Manager haftbar gemacht werden – in Deutschland ist sogar von Haftung mit Privatvermögen im Gespräch, zumindest bis zu gewissen Grenzen. Auch müssen Vorstände und Geschäftsführer in betroffenen Firmen künftig regelmäßig an Schulungen zur Cybersicherheit teilnehmen, um ihrer Sorgfaltspflicht gerecht zu werden. Diese klare Ansage – „Cybersecurity ist Chefsache“ – unterscheidet NIS2 deutlich vom früheren Regime.

Zusammengefasst: Der rechtliche Rahmen wandelt Cybersecurity vom freiwilligen Goodwill zur verpflichtenden Compliance-Aufgabe. Die EU gibt den Takt vor, nationale Gesetze wie in Deutschland konkretisieren die Marschroute, und Aufsichtsbehörden wie das BSI schauen nun genauer hin. Für Unternehmen heißt das einerseits mehr Aufwand und Formalität, andererseits aber auch die Chance, mit offizieller Rückendeckung endlich die nötigen Verbesserungen durchzusetzen (Stichwort Budget und Priorität für Security). Bevor wir dazu kommen, was genau getan werden muss, werfen wir einen Blick auf die Kernpflichten, die NIS2 den Unternehmen auferlegt.

Kernpflichten aus NIS2 – Was Unternehmen konkret tun müssen

Nach all dem „Was“ und „Wer“ kommen wir zum „Was tun“. Welche konkreten Aufgaben schreibt NIS2 den Unternehmen vor? Im Grunde fordert die Richtlinie einen Rundum-sorglos-Katalog an Sicherheitsvorkehrungen. Die wichtigsten Pflichten lassen sich wie folgt zusammenfassen:

• Risikomanagement etablieren: Jedes betroffene Unternehmen muss ein systematisches Informationssicherheits-Risikomanagement betreiben. Das heißt: regelmäßig Risiken analysieren, Bedrohungen und Schwachstellen der eigenen IT identifizieren und darauf basierend Schutzmaßnahmen planen. Es soll klar dokumentiert sein, welche Risiken man wie behandelt (Risikobewertung, Risikoregister). Ohne eine aktuelle Risikoanalyse tappt man im Dunkeln – NIS2 will, dass niemand blind durch den Cybersicherheits-Dschungel stolpert.
• Sicherheitsmaßnahmen nach „Stand der Technik“ umsetzen: Aus den Risiken abgeleitet sind technische und organisatorische Maßnahmen zu ergreifen, und zwar angemessen zum Risiko und Stand der Technik. Hierunter fällt das ganze Einmaleins der IT-Security: von Firewalls, Netzsegmentierung und aktuellen Anti-Malware-Lösungen über regelmäßige Software-Updates und Patch-Management bis hin zu physischer Sicherheit in Rechenzentren. NIS2 zählt in Artikel 21 beispielhaft einige Bereiche auf, u.a. Zugangskontrollen, Backup und Wiederherstellung, Sicherstellung der Netz- und Systemsicherheit bei Entwicklung und Betrieb, Umgang mit Sicherheitslücken und der Einsatz von Verschlüsselung und Mehr-Faktor-Authentifizierung. Jedes Unternehmen muss also prüfen: Habe ich für all diese Bereiche Vorkehrungen getroffen? Wichtig ist dabei die Verhältnismäßigkeit – ein kleines Regionalunternehmen muss keinen High-End-SOC aufbauen, aber die Basics müssen sitzen.
• Incident Response & Meldepflicht: Eine zentrale Neuerung ist die Pflicht zum Melden von Sicherheitsvorfällen. Unternehmen müssen erhebliche Cyber-Vorfälle (solche, die z.B. den Betrieb erheblich stören, großen finanziellen Schaden verursachen oder andere erheblich beeinträchtigen könnten) an die zuständige Behörde melden. Das läuft gestaffelt ab: innerhalb von 24 Stunden nach Entdeckung muss eine erste Warnmeldung raus, nach 72 Stunden ein detaillierter Incident-Report mit ersten Erkenntnissen, und spätestens nach einem Monat ein Abschlussbericht mit einer root-cause-Analyse und ergriffenen Maßnahmen. Damit einher geht die Pflicht, überhaupt intern Incident-Response-Prozesse zu haben: Also definierte Abläufe, wie man Sicherheitsvorfälle erkennt, eskaliert, analysiert und darauf reagiert. Es reicht nicht, einfach auf Hoffnung zu setzen, dass schon nichts passiert – NIS2 verlangt proaktives Störfallmanagement. Im Ernstfall müssen Unternehmen außerdem mit dem nationalen Computer-Notfallteam (in Deutschland das BSI/BSI-CSIRT) kooperieren und ggf. auch die Öffentlichkeit informieren, falls die Behörden dies anordnen.
• Business Continuity und Krisenvorsorge: Eng verwandt mit Incident Response ist die Forderung nach Betriebskontinuität. Firmen sollen Pläne parat haben, um im Falle eines IT-Desasters den Geschäftsbetrieb aufrechtzuerhalten oder schnell wiederherzustellen. Dazu gehören regelmäßige Backups kritischer Daten, Disaster-Recovery-Pläne, Ausweichlösungen für wichtige Dienste und eine geübte Notfallorganisation. NIS2 will sicherstellen, dass ein Cyberangriff nicht gleich alles lahmlegt – wer wichtige Dienste anbietet (sei es Stromversorgung oder eine große Cloud-Plattform), sollte einen Plan B haben, um Ausfälle zu minimieren. Praktisch heißt das: Notfallhandbücher schreiben, Verantwortlichkeiten klären, Szenarien durchspielen (z.B. mittels Notfallübungen) und Lessons Learned umsetzen.
• Lieferketten- und Partner-Sicherheit: Neu im Vergleich zu früheren Regeln ist der starke Fokus auf die Supply-Chain-Security. Unternehmen müssen ihre Dienstleister und Zulieferer in Sachen IT-Sicherheit mit ins Boot holen. Konkret verlangt NIS2, dass Sicherheitsanforderungen entlang der Lieferkette berücksichtigt werden – z.B. durch vertragliche Verpflichtungen der Anbieter, Nachweise über deren Sicherheitsmaßnahmen (Zertifikate, Auditberichte), und interne Prozesse, um Risiken durch Dritte zu bewerten. Wer also z.B. einen Cloud-Dienst nutzt oder IT-Outsourcing betreibt, bleibt trotzdem verantwortlich für die Sicherheit der ausgelagerten Funktionen. NIS2 verpflichtet dazu, im Zweifel auch den Dienstleister zu wechseln oder abzusichern, wenn dieser ein unvertretbares Risiko darstellt. Außerdem sollte es Prozesse geben, um Erkenntnisse über Lieferkettenrisiken zu sammeln und darauf zu reagieren (Stichwort: Wenn ein wichtiger Software-Lieferant gehackt wird, muss man es erfahren und handeln).
• Sichere Entwicklung & Schwachstellenmanagement: Unternehmen, die eigene Software entwickeln oder Systeme konfigurieren, müssen Security by Design beachten. Das bedeutet: schon bei der Entwicklung an Sicherheitsaspekte denken (z.B. Code Reviews, Penetrationstests, sichere Programmierstandards). Aber auch alle anderen müssen ein Schwachstellenmanagement betreiben – d.h. bekannte Sicherheitslücken zeitnah schließen (Patchen, Updates einspielen) und einen Prozess für den Umgang mit neuen Schwachstellen haben. NIS2 nennt explizit „Schwachstellenbehandlung und -offenlegung“: Firmen sollen also idealerweise einen Prozess haben, über den Sicherheitsexperten ihnen entdeckte Lücken melden können (Stichwort Coordinated Vulnerability Disclosure). Man darf sich nicht wegducken, wenn jemand eine Schwachstelle in der eigenen IT findet, sondern sollte diese koordiniert beheben.
• Zugangsverwaltung & Authentifizierung: Ein Dauerbrenner in der IT-Sicherheit ist die Kontrolle von Zugriffsrechten. NIS2 schreibt keine konkreten Produkte vor, aber erwartet, dass Prinzipien wie Least Privilege (so wenig Rechte wie möglich für jeden Benutzer) und Need-to-know konsequent umgesetzt werden. Praktisch bedeutet das: Benutzer- und Adminkonten nur mit den nötigen Berechtigungen ausstatten, regelmäßige Rechte-Reviews durchführen und überbordende Admin-Zugänge eindämmen. Besonders hervorgehoben wird die Nutzung von Multi-Faktor-Authentifizierung (MFA), wo immer angemessen. Einfaches Passwort allein ist in kritischen Bereichen nicht mehr akzeptabel – ein zweiter Faktor (z.B. App oder Token) sollte Standard sein, insbesondere für Zugriffe auf sensible Systeme oder aus dem Fernzugriff. Auch sichere Fernzugänge (VPN mit starker Authentifizierung, keine unsicheren Remote-Desktop-Offenbarungen ins Internet) fallen unter diese Pflicht. Unterm Strich: Zugangssicherheit hochfahren, damit Eindringlinge nicht leichtes Spiel haben, falls mal ein Passwort kompromittiert wird.
• Einsatz von Kryptografie: NIS2 erwartet den angemessenen Einsatz von Verschlüsselung zum Schutz sensibler Daten und Kommunikationswege. „Angemessen“ heißt: Vertrauliche Daten sollten verschlüsselt gespeichert werden (Stichwort Festplattenverschlüsselung, Datenbankverschlüsselung) und Datenübertragungen – etwa über öffentliche Netze – nur verschlüsselt erfolgen (TLS, VPN etc.). Auch die Verwaltung der Kryptoschlüssel selbst muss sicher sein (z.B. Nutzung von Hardware-Sicherheitsmodulen oder Cloud Key Management Services, wo angebracht). Zudem müssen Regeln bestehen, welche Algorithmen als sicher gelten und wann z.B. veraltete Protokolle abzustellen sind. Kryptografie ist eines der stärksten Werkzeuge der IT-Security – NIS2 will, dass es konsequent genutzt wird, um die Auswirkungen von Datenlecks oder Abhöraktionen zu minimieren.
• Governance, Organisation und Dokumentation: Nicht zuletzt fordert NIS2 auch organisatorische Maßnahmen auf der Management-Ebene. Jedes betroffene Unternehmen muss eine klare Zuständigkeit für Cybersecurity benennen – oft wird das ein CISO oder IT-Sicherheitsbeauftragter sein, zumindest aber eine verantwortliche Stelle. Die Geschäftsführung muss die Umsetzung der Sicherheitsmaßnahmen absegnen und überwachen. NIS2 macht Cybersecurity also zu einer Chefsache: Das Top-Management soll regelmäßig Berichte zum Cybersicherheitsstatus erhalten und an Schulungen teilnehmen. Zudem müssen Unternehmen Sicherheitsrichtlinien und -prozesse schriftlich festlegen (z.B. eine Informationssicherheits-Policy, Incident-Response-Plan, Richtlinie für Zugriffsverwaltung, Änderungsmanagement usw.). Diese Dokumente sind keine Selbstzweck-Deckchen für den Schrank, sondern sollen gelebt und regelmäßig geprüft werden. Apropos prüfen: Die Effektivität der Maßnahmen muss ebenfalls überwacht werden – sei es durch regelmäßige interne Audits, Tests (z.B. Penetrationstests, Notfallübungen) oder externe Prüfungen. Insbesondere „besonders wichtige Einrichtungen“ werden in Deutschland mit Pflicht zur regelmäßigen Berichterstattung an das BSI rechnen müssen. Aber auch alle anderen sollten Nachweise bereithalten (Protokolle, Berichte, Schulungsnachweise etc.), falls die Aufsicht anklopft. Kurzum: Eine solide Sicherheitsorganisation mit dokumentierten Regeln und kontinuierlicher Kontrolle ist Pflichtprogramm.

Das klingt nach einer Menge Holz – und das ist es auch. Viele dieser Punkte decken sich mit Best Practices, die man in gängigen Frameworks wie ISO/IEC 27001 oder dem BSI-Grundschutz findet. NIS2 zwingt Firmen nun, diese Practices nicht länger optional zu sehen, sondern verpflichtend umzusetzen, soweit es ihr Risiko erfordert. Die gute Nachricht: Wer hier bereits viel getan hat, wird weniger Lücken schließen müssen. Wer bisher wenig geregelt hatte, für den heißt es jetzt: ran an die Arbeit, aber der Reihe nach. Wie solche Maßnahmen in der IT- und Security-Praxis konkret aussehen, schauen wir uns im nächsten Abschnitt an.

NIS2 in der IT- und Security-Praxis

Theorie und Pflichten sind das eine – aber wie setzt man NIS2 praktisch um? Viele IT-Abteilungen fragen sich, was da konkret auf sie zukommt. Die gute Nachricht: In der Praxis bedeutet NIS2 vor allem, bewährte Sicherheitsmaßnahmen konsequent umzusetzen und organisatorisch zu verankern. Vieles davon dürfte keinem Administrator völlig neu vorkommen. Die Herausforderung liegt eher darin, das Ganze systematisch, lückenlos und nachweisbar zu betreiben. Schauen wir uns an, wie NIS2-Anforderungen im IT-Alltag gelebt werden können:

Technische Umsetzung im IT-Alltag

Auf technischer Ebene deckt sich NIS2 weitgehend mit dem, was man als “Security Best Practices” kennt. Ein paar Beispiele aus der Praxis:

• Patch-Management als Routine: Statt Updates monatelang aufzuschieben („never change a running system“ lässt grüßen), muss Patchen zur festen Gewohnheit werden. Das bedeutet: Regelmäßige Update-Zyklen für Betriebssysteme, Anwendungen und Firmware. In der Praxis richten viele Unternehmen einen monatlichen Patch-Day ein, tracken verfügbare Sicherheitsupdates und spielen diese – nach kurzen Funktionstests – zeitnah ein. Ein System, das sechs Monate ohne Updates läuft, wäre unter NIS2 ein No-Go. Administratoren sollten Tools nutzen wie WSUS, Windows Update for Business oder entsprechende Linux-Repositories, um den Prozess zu automatisieren. Wichtig: Auch “vergessene” Systeme im Eck (der eine alte Datenbankserver unterm Tisch) müssen in die Patch-Routine eingebunden werden.
• Härten und Konfiguration: Beyond patching, geht es um Systemhärtung. Praktisch heißt das: Standard-Passwörter ändern oder abschalten, unnötige Dienste deaktivieren, sichere Konfigurationseinstellungen wählen. Beispielsweise sollten auf Windows-Servern veraltete Protokolle wie SMBv1 oder unsichere TLS-Versionen abgeschaltet werden. Netzwerkgeräte bekommen ein Hardening nach BSI- oder CIS-Benchmarks. Was früher nice-to-have war, wird jetzt Pflicht: Kein “Out-of-the-box”-System bleibt ungehärtet im Netz hängen.
• Überwachung und Logging: Ein weiterer Aspekt der Praxis ist das Security Monitoring. NIS2 verlangt implizit, dass man Angriffe bemerkt – das geht nur mit guten Logs und deren Auswertung. Daher richten viele Firmen ein zentrales Log-Management oder gleich ein SIEM (Security Information and Event Management) ein. In der Praxis kann das z.B. Microsoft Sentinel in Azure sein, ein Splunk-Server oder die Open-Source-Lösung Elastic Stack, je nach Budget. Wichtiger als das Tool ist aber, was man loggt und wie man darauf reagiert: Kritische Systeme (Domänencontroller, Firewalls, Datenbanken, Cloud-Dienste) sollten so konfiguriert sein, dass sicherheitsrelevante Ereignisse erfasst werden – Login-Versuche, Änderungen an Benutzerrechten, Firewall-Blockierungen etc. – und diese Protokolle regelmäßig auf Auffälligkeiten geprüft werden. Das muss nicht gleich ein 24/7 Security Operations Center mit Großleinwand sein; es kann auch bedeuten, dass der Administrator täglich einen Blick auf die Alarmmeldungen im Dashboard wirft oder E-Mail-Warnungen bei bestimmten Ereignissen eingerichtet sind. Wichtig ist: Wenn es brennt, will NIS2, dass der Brand möglichst früh entdeckt wird.
• Incident Response üben: Ein Notfallplan ist nur so gut wie seine Erprobung. In der Praxis sollten IT-Teams daher Sicherheitsvorfälle durchspielen. Das kann ein “Tabletop Exercise” sein, bei dem man gedanklich ein Ransomware-Szenario durchexerziert: Wer zieht den Stecker? Wer informiert die Geschäftsführung? Welches Backup spielen wir zurück? Oder man führt tatsächliche technische Tests durch – etwa ein Red-Team, das versucht, in die Systeme einzudringen, um zu prüfen, ob die Blaulicht-Organisation funktioniert. Solche Übungen decken Lücken auf (z.B. “Ups, wir wissen das Datenbank-Admin-Passwort gar nicht, um aus dem Backup wiederherzustellen”) und sorgen dafür, dass im Ernstfall nicht alle kopflos sind. NIS2 in der Praxis heißt also auch: Plan machen, Plan testen, Plan verbessern.
• Backup-Strategie und Recovery: Viele Firmen haben Backups, aber haben sie auch schon einmal eine vollständige Wiederherstellung getestet? In der NIS2-Welt gehört das dazu. Praktisch sollte mindestens jährlich (besser öfter) ein Restore-Test wichtiger Systeme stattfinden – etwa man tut so, als wäre der Hauptdatenbank-Server ausgefallen und setzt ihn aus dem Backup neu auf. Nur so merkt man, ob die Backups wirklich taugen und wie lange eine Wiederherstellung dauert. Außerdem muss die Backup-Strategie an moderne Bedrohungen angepasst sein: Backups sollten offline oder unveränderbar (immutable) gespeichert werden, damit Ransomware nicht gleich das Backup mitverschlüsselt. Viele setzen auf die 3-2-1-Regel: Drei Kopien, auf zwei verschiedenen Medien, eine davon offsite/offline. Und natürlich: Wichtige Daten in Cloud-Diensten (Mails, Dokumente in Office 365, etc.) nicht vergessen – auch hierfür gibt es Lösungen, oder man nutzt die eingebauten Retention-Policies. NIS2 gibt zwar nicht die 3-2-1-Regel vor, aber implizit wird erwartet, dass Ausfallvorsorge ernst genommen wird.
• Zugriffskontrolle leben: In der Praxis bedeutet das z.B., dass das IT-Team regelmäßig einen Berechtigungsreview durchführt: Welche Nutzer haben Admin-Rechte? Welche Dienstkonten besitzen vielleicht zu hohe Privilegien? Gibt es ehemalige Mitarbeiter, deren Accounts noch schlummern? Unter NIS2 sollte es klare Prozesse geben, wie Benutzer angelegt, geändert und gelöscht werden (Joiner-Mover-Leaver Prinzip). Neue Mitarbeiter bekommen nur die Zugriffe, die sie brauchen – und wenn jemand die Abteilung wechselt, werden alte Rechte entfernt. Technisch lässt sich vieles unterstützen: z.B. über Gruppenrichtlinien nur autorisierte Personen als lokale Admins zulassen, in der Windows-Domäne mit gestaffelten Admin-Konten arbeiten (Tier-Modell), oder Privileged Access Management (PAM) Lösungen einsetzen, die Admin-Zugriffe temporär freigeben. Auch MFA einzuführen ist in der Praxis ein mittlerweile gut bewältigbarer Schritt: Für VPN-Zugänge, Cloud-Dienste oder das eigene Citrix-Portal lässt sich meist via App oder Token ein zweiter Faktor erzwingen. Der kleine Mehraufwand beim Login wiegt die drastisch erhöhte Sicherheit locker auf – und wenn man es den Mitarbeitern vernünftig erklärt, gibt es auch Akzeptanz (zur Not hilft der Hinweis: „Das verlangt das Gesetz jetzt so“, was ja sogar stimmt).
• Kryptografie und Datensicherheit implementieren: Praktisch umsetzen heißt hier: Festplattenverschlüsselung auf Laptops aktivieren (z.B. BitLocker bei Windows, FileVault bei macOS), sensible Datenbanken oder File Shares mit Verschlüsselung schützen, und bei der Übertragung nur sichere Protokolle verwenden. Beispielsweise sollte eine Unternehmenswebseite immer TLS (HTTPS) nutzen, interne Serverkommunikation möglichst verschlüsselt sein (Datenbankverbindungen, APIs etc.), und E-Mails idealerweise transportverschlüsselt (was heute Standard via TLS ist). Außerdem gilt es, alte unsichere Verfahren abzulösen – z.B. kein FTP ohne Encryption mehr, sondern SFTP oder HTTPS, keine schwachen Kryptographie-Algorithmen (adieu, DES und unsignierte MD5-Zertifikate). Die IT-Praxis muss hier vielleicht einige Altlasten modernisieren: Oft laufen in Unternehmen noch ältere Anwendungen, die nur unverschlüsselt kommunizieren – sowas muss entweder ein Update bekommen oder durch ein VPN bzw. Tunnel geschützt werden. NIS2 liefert den Hebel, diese Investitionen einzufordern.

Organisation, Prozesse und Kultur

Neben der Technik ist die Organisation der Schlüssel. NIS2 umzusetzen erfordert, dass Security nicht als Projekt der IT isoliert bleibt, sondern im ganzen Unternehmen verankert wird. Was heißt das praktisch?

• Verantwortlichkeiten klären: Es sollte eine klare Benennung geben, wer für die Informationssicherheit zuständig ist. In größeren Firmen gibt es einen CISO oder Informationssicherheitsbeauftragten. In kleineren übernimmt vielleicht der IT-Leiter diese Rolle nebenbei, aber auch dann sollte formal festgelegt sein: Person X koordiniert NIS2-Compliance. Wichtig ist auch ein internes Meldesystem: Mitarbeiter müssen wissen, an wen sie sich wenden, wenn ihnen ein Sicherheitsvorfall oder auch nur ein Verdacht auffällt (z.B. “Ich glaube, ich hab auf was Komisches geklickt”). Das kann eine Hotline, ein Ticketsystem oder schlicht die Ansage “Melde es sofort dem IT-Security-Verantwortlichen” sein. Kultur schafft man dadurch, dass niemand Angst haben darf, einen Vorfall zu melden – Fehler passieren, und lieber meldet der Nutzer den Phishing-Klick sofort, als dass er es vertuscht und der Trojaner sich entfaltet.
• Policies und Prozesse dokumentieren: In der Praxis heißt das: Ja, es wird etwas Papierkram geben. Aber sinnvoll genutzt, helfen klare Richtlinien den Mitarbeitern, richtig zu handeln. Beispielsweise eine Passwortrichtlinie (wie sollen Passwörter beschaffen sein und wie oft müssen sie geändert werden – wobei moderne Ansätze eher auf Länge statt regelmäßige Wechsel setzen), eine Acceptable Use Policy für IT (was ist erlaubt auf Firmengeräten, was nicht), oder ein Incident-Response-Plan als Ablaufplan im Notfall. Diese Dokumente sollten knapp und verständlich sein – keiner liest 100 Seiten IT-Handbuch. Lieber 5 Seiten knackige Anweisungen, die im Ernstfall wirklich genutzt werden. Und ganz wichtig: Prozesse auch wirklich so leben. Wenn die Policy sagt “Admin-Zugriff nur zu zweit” (Vier-Augen-Prinzip), dann sollte das im Alltag auch passieren und nicht aus Bequemlichkeit umgangen werden.
• Schulung und Awareness: Technik allein reicht nicht – der “Faktor Mensch” bleibt zentral. NIS2 fordert deswegen Schulungen, insbesondere auch für die Führungskräfte. In der Praxis sollte es regelmäßige Awareness-Trainings geben: z.B. E-Learning-Module zu Phishing, kurze Workshops zu IT-Sicherheitsrichtlinien, oder zumindest jährliche Unterweisungen für alle Mitarbeiter. Führungskräfte könnte man gezielt schulen, was ihre Pflichten sind und wie sie Security vorleben können. Einige Unternehmen führen Phishing-Simulationen durch: Dabei bekommen Mitarbeiter testweise Fake-Phishing-Mails, und wer klickt, bekommt im Anschluss eine freundliche Lektion, wie man es hätte erkennen können. Solche Maßnahmen fördern eine Sicherheitskultur, in der jeder im Unternehmen Sicherheit mitdenkt. Das ist letztlich das Ziel: Security soll so normal werden wie Arbeitssicherheit im Betrieb – niemand würde ohne Helm auf die Baustelle, also klickt idealerweise auch niemand blind auf unbekannte Anhänge.
• Integrierung in bestehende Prozesse: NIS2-Compliance sollte nicht als völlig getrenntes Neuprojekt laufen, sondern clever in vorhandene Strukturen eingebaut werden. Haben Sie schon ein Qualitätsmanagement oder eine ISO-Zertifizierung? Prima, nutzen Sie diese Strukturen, um Security-Prozesse mit abzubilden. Gibt es ein Risikomanagement im Unternehmen (z.B. für Finanzen oder Projekte)? Dann erweitern Sie es um Cyber-Risiken, statt ein paralleles Universum aufzubauen. Auch Change-Management-Prozesse in der IT (z.B. ITIL) können Security-Checks integrieren – etwa, dass jede Änderung an der Firewall eine kurze Risikoabwägung durchläuft. So wird NIS2 in den “normalen Betrieb” verwoben, was nachhaltiger ist, als einmalig Häkchen zu setzen.
• Externe Unterstützung und Austausch: Praktisch werden nicht alle Firmen alles selbst stemmen können. Es kann sinnvoll sein, externe Dienstleister oder Berater hinzuzeugen – beispielsweise einen Security-Spezialisten, der beim Aufbau eines ISMS hilft, oder einen Managed Security Service, der das 24/7 Monitoring übernimmt, wenn intern keine Ressourcen da sind. Wichtig ist, die Verantwortung bleibt im Haus – auslagern kann man Aufgaben, aber nicht die Verantwortung. Ebenso hilfreich: der Austausch in Branchenverbänden oder mit Peer-Unternehmen. In vielen Sektoren gibt es inzwischen Informationsplattformen (sogenannte ISACs – Information Sharing and Analysis Centers), wo anonymisiert über aktuelle Bedrohungen und Lösungen berichtet wird. Sich dort zu engagieren, kann enorm wertvoll sein. NIS2 fördert indirekt auch solche Kollaborationen, weil alle im selben Boot sitzen.
• “Kulturwandel” herbeiführen: Letztlich ist NIS2 nur so wirkungsvoll, wie es im Alltag gelebt wird. Die beste Policy nützt nichts, wenn Mitarbeiter und Führungskräfte sie ignorieren. Daher sollte das Thema positiv vermittelt werden: Nicht als bürokratische Last, sondern als Schutz für das Unternehmen. Wenn z.B. die Produktion wegen eines Cyberangriffs stillsteht, ist das auch für jeden Mitarbeiter schlecht – also haben alle ein Interesse, solche Situationen zu vermeiden. Diese Denkweise muss Teil der Firmenkultur werden. Eine Geschäftsführung, die regelmäßig nach dem Stand der IT-Sicherheit fragt und Erfolge anerkennt, motiviert das ganze Team. Ein Administrator, der offen kommuniziert, warum eine Maßnahme nötig ist (“Wir führen MFA ein, ja es ist lästig, aber damit schützen wir uns vor schlimmen Szenarien”) gewinnt eher die Mitwirkung der Kollegen. So wird NIS2-Compliance von einer lästigen Pflicht zum Teil des gemeinsamen Ziels, das Unternehmen sicher und erfolgreich zu halten.

In der Summe bedeutet NIS2 in der Praxis: Security als festen Bestandteil des Betriebs etablieren. Weg von “Feuerwehr-Spielchen” hin zu geplantem, vorbeugendem Handeln. Viele Unternehmen werden feststellen, dass sie etliche Puzzleteile schon haben – jetzt gilt es, diese zu einem schlüssigen Bild zusammenzusetzen, Lücken zu füllen und das Ganze kontinuierlich zu pflegen. Das mag anfangs Aufwand bedeuten, zahlt sich aber aus: durch weniger Vorfälle, weniger Stress im Krisenfall und letztlich auch durch Vertrauen von Kunden und Partnern in die Professionalität der Organisation.

Übersetzung auf typische Microsoft-Stacks

Viele Unternehmen in der DACH-Region setzen auf Microsoft-Technologien – von Windows-Servern über Active Directory bis hin zu Microsoft 365 und Azure-Cloud. Die gute Nachricht: Der Microsoft-Stack bietet bereits zahlreiche Werkzeuge, um die geforderten Sicherheitsmaßnahmen umzusetzen. Hier ein praxisnaher Blick darauf, wie NIS2-Anforderungen in einer typischen Microsoft-Umgebung angegangen werden können:

Identität und Zugriffsverwaltung mit Microsoft

Microsofts Verzeichnisdienste sind in vielen Firmen das Herzstück der Benutzerverwaltung. Active Directory (AD) on-premises und Azure Active Directory (Azure AD) in der Cloud bilden die Basis für Zugriffssteuerung. Zur Erfüllung von NIS2-Pflichten sollte man folgende Ansätze nutzen:

• Strikte Passwort- und Anmelderichtlinien: Im AD können über Gruppenrichtlinien komplexe Passwortregeln erzwungen werden (Mindestlänge, Historie, keine gängigen Wörter). Besser noch: Azure AD ermöglicht den Kennwortschutz gegen verbotene Passwörter (so dass niemand „Frühling2023!“ nutzen kann). Außerdem kann man in Azure AD Smart Lockout nutzen, um Brute-Force-Versuche zu vereiteln. Moderne Empfehlung ist auch, auf Passwortwechsel-Zwang zu verzichten, dafür aber sehr starke Anfangs-Passwörter zu nutzen und MFA einzusetzen – Microsoft selbst propagiert teils sogar eine kennwortlose Strategie (z.B. via Windows Hello oder FIDO2-Keys) für höhere Sicherheit.
• Multi-Faktor-Authentifizierung überall: Mit Azure AD lässt sich MFA sehr leicht einführen – entweder per bedingtem Zugriff (Conditional Access) Regel, die z.B. MFA für alle Benutzer außerhalb des Firmennetzes verlangt, oder pauschal für alle Benutzer (was Microsoft via Security Defaults bei neuen Tenants sogar standardmäßig aktiviert). Für On-Premises-Apps kann man Azure AD Application Proxy einsetzen oder Lösungen wie ADFS/LDAP mit MFA-Adapter, um selbst Legacy-Anwendungen MFA-fähig zu machen. Wichtig ist: Administratoren-Konten immer mit MFA schützen, was dank der Microsoft Authenticator App oder FIDO2-Token schnell umgesetzt ist.
• Privilegierte Konten absichern: Microsoft bietet mit Privileged Identity Management (PIM) in Azure AD die Möglichkeit, Admin-Rechte nur temporär zu vergeben (Just-in-Time Admin, inkl. Genehmigungs-Workflow). On-Premises kann man mit separaten Admin-Accounts und dem Tier-Modell arbeiten: Domain-Admins nutzen separate gehärtete Admin-Workstations, und sie haben keine Internetzugänge auf diesen Konten, um Phishing-Risiken zu minimieren. Zudem lassen sich mit Azure AD Role-Based Access Control (RBAC) fein granular Rechte für Azure Ressourcen steuern, sodass nicht jeder Global Admin sein muss. NIS2’s Forderung nach „Least Privilege“ lässt sich in Microsoft-Umgebungen also mit Bordmitteln umsetzen, es bedarf nur konsequenter Einrichtung.
• Zugriff überwachen und protokollieren: Azure AD erfasst Anmeldeprotokolle, Risky Sign-ins etc. – diese sollte man auswerten. Für On-Prem AD kann man die Security Eventlogs per Windows Event Forwarding zentral sammeln. Produkte wie Microsoft Defender for Identity (ehemals Azure ATP) überwachen verdächtiges Verhalten auf Domain Controllern (z.B. Pass-the-Hash Angriffe) und schlagen Alarm. Viele dieser Tools integrieren sich ins Microsoft 365 Defender Portal, was dem Security-Team einen zentralen Blick ermöglicht.

Endpunktsicherheit und Patch-Management in Windows-Umgebungen

Microsoft-Systeme bringen zahlreiche Funktionen mit, um Endgeräte abzusichern:

• Microsoft Defender Antivirus & Endpoint: Windows 10/11 und Windows Server haben mit Microsoft Defender bereits einen soliden Virenschutz an Bord, der in vielen unabhängigen Tests gut abschneidet. In Kombination mit Defender for Endpoint (der erweiterte EDR-Dienst in Microsoft 365 E5) erhält man Funktionen wie Verhaltensanalyse, automatisierte Untersuchung von Vorfällen und sogar aktive Abwehr (Isolation eines kompromittierten Clients per Klick). Für NIS2 praktisch: Diese Tools protokollieren Angriffe detailliert, was bei einer Meldepflicht hilft, und sie können Angriffe oft schon proaktiv blockieren.
• Gruppenrichtlinien und Security Baselines: Microsoft stellt Security Baseline Templates zur Verfügung (z.B. für Windows, Office, Edge), die hunderte empfohlene Sicherheitseinstellungen enthalten. Unternehmen sollten diese Baselines als Ausgangspunkt nehmen und via Group Policy oder Intune (für Azure AD-gebundene Geräte) ausrollen. Damit erreicht man z.B., dass Firewalls auf Clients immer aktiv sind, unsichere Dienste deaktiviert werden, Logging aktiviert ist usw. Das BSI-Grundschutz Kompendium hat hier viele Überschneidungen – viele der dort empfohlenen Einstellungen lassen sich 1:1 mit GPOs umsetzen.
• Patch-Verteilung mit WSUS/Intune: Wie erwähnt, Patch-Management ist essenziell. Microsoft bietet mit WSUS (Windows Server Update Services) ein kostenloses Tool, um Updates zentral zu verteilen und deren Status zu überwachen. In Cloud-affinen Umgebungen kann Intune (Microsoft Endpoint Manager) das Update-Management übernehmen, sowohl für Windows als auch für Drittanbieter-Apps (via Winget-Integration). Wichtig ist eine klare Policy: Updates zunächst in Testgruppe, dann zügig in Breite. Intune erlaubt es z.B., Update-Ringe zu definieren (erste Woche Pilotgruppe, zweite Woche breiter Rollout). So erfüllt man NIS2s Anforderungen an strukturiertes Schwachstellenmanagement mit Microsoft-Bordmitteln.
• Geräte- und Datensicherheit: Mit BitLocker kann man alle Windows-Notebooks und auch Server-Laufwerke verschlüsseln – der Schlüssel wird im TPM und idealerweise in Azure AD (bei Azure AD Join) oder im AD (bei klassischem Domänen-Join) gesichert. So ist bei Geräteverlust die Vertraulichkeit gewahrt. Über Intune lässt sich BitLocker bei allen Clients erzwingen und verwalten (inkl. Recovery-Key Management). Für mobile Geräte gibt es Analoges mit Mobile Device Management: Intune kann auch iOS/Android-Geräte verwalten, Compliance durchsetzen (z.B. PIN-Pflicht, Geräteverschlüsselung am Smartphone) und bei Verlust ein Remote-Wipe veranlassen. Das alles unterstützt NIS2s Ziel, dass auch Endgeräte robust geschützt und kontrolliert sind.

Monitoring und Vorfallsmanagement mit Microsoft-Tools

• SIEM und Security Monitoring: Microsofts Cloud bietet mit Azure Sentinel ein modernes SIEM/SOAR-System, das viele Datenquellen zusammenführt – von Office 365 Logs über Azure AD Sign-ins bis zu On-Premise Syslogs (via Log Collector). Sentinel kommt mit vorkonfigurierten Use Cases (z.B. Alarm, wenn ein ungewöhnliches Anmeldeverhalten erkannt wird oder wenn viele Dateien auf einmal verschlüsselt werden – Ransomware Indiz). Für NIS2 kann Sentinel wertvoll sein, um die geforderte durchgehende Überwachung und schnelle Erkennung umzusetzen. Wer Sentinel nicht nutzen will, kann zumindest die Microsoft 365 Defender Portale nutzen: Dort laufen Alarme von Defender für Endpoint, Defender für Office 365 (E-Mail-Schutz), Defender for Identity (AD-Monitoring) und Cloud App Security zusammen. Eine IT-Abteilung kann täglich diese Dashboards prüfen – quasi ein “Light-SOC” betreiben.
• Incident Response-Unterstützung: Kommt es zu einem Sicherheitsvorfall, liefern Microsoft-Lösungen viele Hilfen: Defender für Endpoint kann z.B. beim Fund von Malware automatisch Aktionen durchführen (Prozess killen, Datei in Quarantäne) und eine Timeline der Angriffskette anzeigen. Azure AD zeigt, ob ein Konto möglicherweise kompromittiert ist (Risky Users). Im Falle eines notwendig zu meldenden Vorfalls lassen sich aus den Portalen Berichte ziehen, die man dem BSI bereitstellen kann (z.B. CSV-Exporte von Logdaten, die den Vorfall dokumentieren). Zudem kann man mit Microsoft Teams schnell ein Krisenkommunikations-Team aufsetzen, um intern die Abstimmung im Notfall zu erleichtern (viele Firmen haben inzwischen einen “War Room” Chat für IT-Krisen in Teams vorbereitet).
• Automatisierung: Für repetitive Sicherheitsaufgaben kann man in der Microsoft-Welt auch Automatisierung nutzen – z.B. mit PowerShell-Skripten oder Playbooks in Azure Sentinel (die per Logic App z.B. automatisch einen Incident erstellen, ein Ticket auslösen oder einen User sperren, wenn bestimmte Events eintreten). Diese Orchestrierung hilft, schneller zu reagieren, was genau im Sinne von NIS2 ist (Stichwort “sofortige Reaktion innerhalb 24h”).

Cloud-Services und Microsoft 365 absichern

Viele Organisationen haben einen Teil ihrer Infrastruktur bei Microsoft gehostet – sei es Azure für eigene Anwendungen oder Microsoft 365 für E-Mail, Collaboration und Co. Hier einige praktische Schritte zur Absicherung dieser Dienste:

• Azure-Basisschutz: Nutzen Sie Azure Policy und Azure Blueprint: Damit kann man erzwingen, dass z.B. alle Azure-VMs mit Verschlüsselung laufen, kein Storage-Container öffentlich exponiert ist oder alle SQL-Datenbanken das neueste Patch-Level haben. Azure Defender (Teil von Defender for Cloud) überwacht laufend die Azure-Ressourcen und gibt Sicherheitsempfehlungen (CSPM – Cloud Security Posture Management). So sieht das Admin-Team sofort, wenn etwa eine VM keinen aktuellen Patch-Status hat oder eine wichtige Konfiguration fehlt. Diese Empfehlungen sollte man regelmäßig prüfen und umsetzen.
• Netzwerksicherheit in Azure: Azure ermöglicht segmentierte Netzwerke mittels Network Security Groups (NSGs) und Azure Firewall. Man sollte Cloud-Netze wie klassische Rechenzentrumsnetze behandeln: gezielte Freigaben, alles andere per Default deny. Für Webanwendungen kann man den Azure Application Gateway mit Web Application Firewall (WAF) nutzen, um OWASP Top 10 Angriffe abzufangen. Solche Cloud-native Controls erfüllen NIS2s Anforderungen an Schutzmaßnahmen in modernen Umgebungen.
• Microsoft 365 schützen: In Microsoft 365 gibt es eine Fülle an Security-Optionen. Aktivieren Sie unbedingt Defender for Office 365 (Plan 1 oder 2), der z.B. E-Mails auf Phishing-URLs oder Malware-Anhänge in Sandboxen prüft (Safe Links, Safe Attachments). Setzen Sie Mail-Authentifizierungsstandards wie DKIM, SPF und DMARC korrekt, um E-Mail-Betrug zu erschweren. Nutzen Sie Conditional Access in Azure AD auch für Office 365 – z.B. um den Zugriff auf Exchange Online zu reglementieren (niemand ohne MFA, oder Blockade für unsichere Apps). Im SharePoint und OneDrive Bereich kann man DLP (Data Loss Prevention) Regeln definieren, um z.B. zu verhindern, dass vertrauliche Daten versehentlich nach extern geteilt werden. Und mit Microsoft Purview Compliance Portal (ehemals Compliance Center) lässt sich die Einhaltung diverser Standards nachvollziehen – Purview enthält auch Vorlagen, um z.B. ISO27001 oder NIST abzugleichen; eine NIS2-Vorlage wird es perspektivisch geben, an der man den Fortschritt messen könnte.
• On-Premises weiter pflegen: Auch wer in die Cloud geht, hat oft noch Hybrid-Setups. Hier ist wichtig: Azure AD Connect (die Brücke zwischen lokalem AD und Azure AD) aktuell halten, Domänencontroller sichern wie Kronjuwelen, eventuell Read-Only DCs an unsicheren Standorten einsetzen. Microsofts Empfehlungen wie Enterprise Access Model oder neuere Zero-Trust-Ansätze sollten geprüft werden. Ein Stichwort ist “Zero Trust”: Microsoft verfolgt dieses Prinzip in allen Cloud-Diensten – man kann es vereinfacht so umsetzen: Verifiziere jeden Zugriff (MFA, Gerätestatus), vertraue keinem Netzwerk per se (auch intern Zero Trust erzwingen via Conditional Access “Compliant device required” für alles), und überwache kontinuierlich. Das mag ambitioniert klingen, aber Schritt für Schritt kann man diese Philosophie ausrollen und damit NIS2-Anforderungen an Zugriffssicherheit, Netzwerksegmentierung und Monitoring modern erfüllen.

Zusammengefasst lässt sich sagen: In einer Microsoft-zentrischen IT-Landschaft muss das Rad für NIS2 nicht neu erfunden werden. Viele Lösungen sind bereits vorhanden – oft sogar schon lizenziert und installiert, aber vielleicht noch nicht überall aktiviert. Der Schlüssel ist, die verfügbaren Security-Features konsistent zu nutzen. Ein typisches Beispiel: Office 365 liefert standardmäßig Unmengen an Logs, aber erst wenn ich einen Plan habe, wie ich diese auswerte (z.B. mit Sentinel oder zumindest den Defender-Dashboards), schöpfe ich den Nutzen voll aus. Genauso schützt MFA nur, wenn ich es auch einschalte. NIS2 kann hier als Anlass dienen, die Microsoft-Werkzeugkiste einmal gründlich zu durchforsten und überall dort, wo “Off” noch herrscht, auf “On” zu schalten – natürlich wohlüberlegt und gesteuert. So lässt sich die Compliance mit vergleichsweise wenig zusätzlichen Tools erreichen, indem man das Beste aus dem vorhandenen Microsoft-Stack herausholt.

Projektvorgehen: Von NIS2-Panik zu einem sauberen Umsetzungsprogramm

Angesichts der Vielzahl an To-dos ist es verlockend, in kopflose Panik zu verfallen. Doch wie bei jedem großen Vorhaben hilft ein strukturiertes Vorgehen, um Schritt für Schritt ans Ziel zu kommen. Hier ein möglicher Fahrplan, der sich in der Praxis bewährt, um aus der initialen NIS2-Panik ein geordnetes Compliance-Projekt zu machen:

1. Ruhe bewahren und Zuständigkeit klären: Als erstes gilt: Keine Panik. Statt Aktionismus sollte ein kleiner Kreis von Verantwortlichen definiert werden, der das Thema steuert. Setzen Sie intern ein Kickoff-Meeting auf mit allen relevanten Stakeholdern – typischerweise IT-Leitung, Informationssicherheitsbeauftragter (falls vorhanden), vielleicht jemand aus dem Risikomanagement oder Compliance, und idealerweise ein Mitglied der Geschäftsleitung als Sponsor. Ziel dieses Auftakts: Bewusstsein schaffen, dass NIS2 ein Projekt ist, kein Schnellschuss. Gleichzeitig sollte man prüfen, ob und wo das Unternehmen betroffen ist: Welche Geschäftsbereiche fallen unter NIS2 (Sektor-Zuordnung)? Sind alle Tochtergesellschaften betroffen oder nur bestimmte? Falls Unsicherheit besteht, kann man rechtliche Beratung hinzuziehen, um Klarheit zu bekommen. Sobald klar ist “Ja, wir gehören dazu”, sollte diese Entscheidung intern kommuniziert und von ganz oben unterstützt werden.
2. Scope und Geltungsbereich definieren: In dieser Phase legt man genau fest, welche Teile des Unternehmens unter die neuen Regeln fallen. Beispiel: Ein Konzern hat sowohl kritische Infrastruktur als auch unwesentliche Bereiche – dann fokussiert man zunächst auf die kritischen Teile. Auch geografisch: Wenn man Standorte außerhalb der EU hat, unterliegen die ggf. nicht direkt NIS2, es sei denn sie unterstützen die EU-Operation wesentlich. Diese Abgrenzung ist wichtig, um die Projektarbeit fokussiert zu halten. Ebenso sollte man festlegen, ob man das Projekt nur auf die NIS2-Mindestanforderungen ausrichtet oder gleich ein übergreifendes Sicherheitsprogramm daraus macht (oft sinnvoll, um nicht zwei getrennte Schienen zu fahren).
3. Ist-Analyse / Reifegradbewertung: Bevor man in blinden Aktionismus verfällt, ist ein klarer Blick auf den Status quo nötig. Führen Sie eine Gap-Analyse durch: Welche Sicherheitsmaßnahmen und Prozesse existieren bereits und wie stehen sie im Vergleich zu den NIS2-Anforderungen da? Am besten orientiert man sich an der Liste aus dem vorherigen Abschnitt (Risikomanagement, Incident Response, Business Continuity, Patch-Management, Zugriffssteuerung, Lieferkette, Schulungen etc.) und bewertet jeden Punkt. Viele Unternehmen nutzen hierfür Checklisten oder Maturity-Modelle. Das Ergebnis sollte sein: Eine Übersicht, wo man schon gut aufgestellt ist und wo erhebliche Lücken klaffen. Vielleicht stellt sich heraus, dass z.B. Backup/Recovery vorbildlich geregelt ist (super!), aber die Incident-Response-Planung fehlt komplett – solche Erkenntnisse helfen bei der Priorisierung. Wichtig: auch relevante Dokumente sichten (gibt es schon Policies?) und vergangene Sicherheitsvorfälle analysieren (was lief da gut/schlecht?).
4. Maßnahmenplan und Ressourcenplanung: Auf Basis der Lücken erstellt man einen Umsetzungsfahrplan. Nicht alles lässt sich gleichzeitig erledigen, daher priorisieren: Welche Baustellen sind kritisch (z.B. fehlende Meldestruktur – sofort angehen, weil im Ernstfall sonst Frist verpasst)? Welche Maßnahmen brauchen lange Vorlaufzeit (evtl. Beschaffung neuer Tools, die das nächste Budget erfordern)? Erstellen Sie eine Roadmap mit kurzfristigen, mittelfristigen und langfristigen Aktionen. Hier zahlt es sich aus, das Projekt in Arbeitspakete zu gliedern – zum Beispiel: “Erstellung Informationssicherheits-Leitlinie”, “Einführung SIEM-System”, “Durchführung Schulung Management”, “Notfallhandbuch aktualisieren” etc. Jedem Arbeitspaket sollten Verantwortliche, benötigte Ressourcen und ein realistischer Zeitrahmen zugewiesen werden. Es ist klug, auch Quick Wins einzuplanen: Dinge, die man schnell umsetzen kann, um erste Erfolge vorzuweisen (z.B. MFA einschalten – geht fix und bringt viel). Parallel muss geklärt werden, ob externe Hilfe notwendig ist: Möchte man Berater hinzuziehen (Budget einplanen) oder kann man vieles intern stemmen? Und man sollte nicht vergessen, die Rollen im Projektteam festzulegen – wer koordiniert (Projektleitung), wer kümmert sich um technische Maßnahmen, wer um Policies, wer um Schulungen etc. Ein guter Maßnahmenplan ist wie eine Landkarte, damit alle wissen, wo die Reise hingeht.
5. Umsetzung der Maßnahmen: Jetzt geht es ans Eingemachte – die geplanten Maßnahmen müssen realisiert werden. Hier ist gute Projektsteuerung gefragt: Regelmäßige Status-Meetings, Aufgaben-Tracking (z.B. über eine Projektmanagement-Software oder zumindest To-Do-Listen). Typischerweise wird man parallel an mehreren Fronten arbeiten: Die IT-Techniker richten neue Systeme oder Konfigurationen ein (z.B. Log-Management, Network Segmentation), während das Compliance-Team an Richtliniendokumenten schreibt und Schulungskonzepte entwickelt. Wichtig ist, die Abhängigkeiten zu beachten: Man kann z.B. eine neue Policy erst final verabschieden, wenn klar ist, welche technischen Lösungen implementiert werden – und umgekehrt sollten technische Lösungen die in Policies definierten Anforderungen erfüllen. Kommunikation im Team ist daher zentral. Feiern Sie auch Zwischen-Erfolge, um die Motivation hochzuhalten – jedes abgeschlossene Teilprojekt (z.B. “Backup-Konzept komplett überarbeitet und getestet”) ist ein Schritt zu mehr Sicherheit. Und scheuen Sie sich nicht, das Management bei Bedarf um Entscheidungen zu bitten (z.B. Freigabe von Budget für ein Tool oder Priorisierung eines Sicherheitsthemas über ein Feature-Update in der IT-Roadmap).
6. Testen, Überprüfen, Trockenlauf: Bevor man “fertig” meldet, sollte man die Umsetzung auf Herz und Nieren prüfen. Das bedeutet: interne Audits oder Peer-Reviews durchführen, Checklisten abhaken – wurde wirklich an alles gedacht? Einen Trockenlauf für den Ernstfall veranstalten: Beispiel – man simuliert einen Cyberangriff, um zu sehen, ob die Incident-Response-Kette funktioniert. Oder man lässt einen externen Pentest machen, um zu überprüfen, ob trotz aller Maßnahmen noch gravierende Lücken da sind. Auch ein Pre-Audit durch externe Experten kann hilfreich sein, um vor einer möglichen Behördenprüfung die Schwachstellen aufzudecken. Diese Tests sollten ergebnisoffen sein – lieber findet man jetzt selbst heraus, was noch nicht klappt, als dass es im Realfall oder bei einer offiziellen Prüfung schiefgeht. Identifizierte Mängel fließen wiederum als Lessons Learned in eine Nachbesserungs-Runde ein.
7. Go-Live und fortlaufender Betrieb: NIS2-Compliance ist kein einmaliges Projekt, das man mit einem Häkchen “abgeschlossen” versehen kann – es geht in den Regelbetrieb über. Das Projektteam sollte also früh überlegen, wie die Daueraufgaben verankert werden. Beispielsweise: Wer pflegt das Risikoregister kontinuierlich? Wie oft wird die Geschäftsführung über Cybersecurity informiert (z.B. quartalsweiser Bericht)? Wer aktualisiert Policies, wenn sich Technik oder Organisation ändern? All das muss in die Linienorganisation überführt werden. Gegebenenfalls etabliert man ein kontinuierliches ISMS (Informationssicherheits-Managementsystem), das ohnehin solche Wiederholungsprozesse vorsieht (ISO 27001 lässt grüßen). Wichtig ist, dass nach Projektende kein “NIS2-Müdigkeitseffekt” eintritt. Planen Sie regelmäßige Überprüfungen ein – etwa jährliche Management-Reviews der Security-Lage, jährliche Notfalltests, quartalsweise Drill-Übungen, etc. So bleibt das Thema präsent und entwickelt sich mit den Bedrohungen weiter.
8. Dokumentation für den Audit-Fall bereithalten: Parallel zu allen Schritten sollte eine saubere Projektdokumentation geführt werden. Am Ende will man ein Paket an Nachweisen haben: Aktuelle Policies, Berichte der durchgeführten Risikoanalysen, Protokolle von Übungen, Liste der umgesetzten technischen Maßnahmen, Schulungsnachweise, etc. Diese Dokumente sollte man geordnet und griffbereit haben, falls die Aufsichtsbehörde einen Nachweis verlangt. Im Grunde baut man einen “Compliance-Ordner” (physisch oder elektronisch), in dem alles Relevante abgelegt ist. Dies erleichtert nicht nur externe Prüfungen, sondern hilft auch intern, den Überblick zu behalten.

Mit diesem Fahrplan wandelt man die erste Aufregung in ein strukturiertes Programm um. Wichtig ist, dass das Top-Management hinter dem Plan steht und die notwendigen Ressourcen freigibt – dann lässt sich aus der NIS2-Pflicht ein Projekt machen, das am Ende die gesamte Organisation resilienter und sicherer macht. Und sobald man die ersten Schritte gemacht hat, schwindet die Panik und weicht dem Gefühl: “Wir haben das im Griff, wir arbeiten den Plan ab.” Genau das ist das Ziel – weg vom Chaosmodus, hin zu kontrollierter Sicherheit.

Typische Stolperfallen und Fehlannahmen

Bei der Umsetzung von NIS2 begegnet man in der Praxis oft bestimmten Irrtümern und Denkfehlern. Hier sind einige verbreitete Stolperfallen – und warum man ihnen nicht aufsitzen sollte:

• Irrtum: „Uns betrifft das nicht, wir sind doch kein Kraftwerk!“ – Viele Unternehmen wiegen sich in falscher Sicherheit, dass NIS2 nur „die Großen“ oder klassische Kritische Infrastrukturen treffe. Tatsache ist: Schon ein mittelständischer Hersteller mit 60 Mitarbeitern im Maschinenbau kann unter NIS2 fallen, ebenso ein IT-Dienstleister mit 12 Mio. € Umsatz. Die Branchenliste ist breit (inkl. Fertigung, Digitales, Forschung, etc.) und die Schwellenwerte sind niedrig angesetzt. Also nicht vorschnell abwinken – sorgfältig prüfen, ob man dazugehört. Und selbst wenn man formal knapp nicht darunter fällt: Kunden in der Lieferkette könnten Nachweise fordern, sodass man indirekt doch handeln muss.
• Irrtum: „Wir warten mal ab, ob die Behörde sich meldet.“ – Diese Vogel-Strauß-Taktik kann teuer enden. NIS2 verlangt proaktives Handeln, nicht erst zu reagieren, wenn ein Brief vom BSI kommt. Die Aufsichtsbehörden erwarten, dass Unternehmen selbstständig ihre Pflichten erfüllen. Wer abwartet, riskiert, in Zeitnot zu geraten oder im Ernstfall unvorbereitet dazustehen. Besser ist, frühzeitig die Weichen zu stellen – auch ohne persönliches Anschreiben. Wenn die Behörde sich meldet, dann lieber mit der Botschaft “Wir haben schon viel erledigt” statt “Ach echt, wir auch?”.
• Irrtum: „Das kann die IT-Abteilung im Alleingang erledigen.“ – Nein, NIS2 ist kein reines IT-Thema, das man an die Administratoren delegieren kann. Viele Anforderungen betreffen Management und Organisation (Policies, Schulungen, Meldestrukturen) und benötigen Entscheidungen von oben (z.B. Risikoappetit, Budget). Die IT kann und soll viel umsetzen, aber ohne Rückendeckung und aktive Mitwirkung der Führung wird es hapern – und genau das will NIS2 nicht mehr durchgehen lassen. Cybersecurity ist Teamarbeit, von der Geschäftsführung bis zum Azubi, nicht die Privatangelegenheit der IT.
• Irrtum: „Wir kaufen einfach ein Tool, dann sind wir compliant.“ – Es gibt keine einzelne “NIS2-Software”, die alle Pflichten erfüllt. Natürlich können Tools helfen (SIEM für Monitoring, GRC-Tools für Doku, etc.), aber letztlich sind Prozesse und Menschen genauso wichtig. Manche Anbieter werben mit “NIS2 Komplettlösungen” – hier sollte man kritisch bleiben. Compliance erreicht man durch eine Kombination aus Technologie, Richtlinien und gelebter Praxis. Ein neues Security-Tool nützt wenig, wenn niemand es richtig benutzt oder in die Prozesse einbettet.
• Irrtum: „Wir haben ISO 27001/TISAX/BSI-Grundschutz, damit sind wir fein raus.“ – Eine vorhandene Sicherheitszertifizierung ist ein hervorragender Ausgangspunkt, keine Frage. Viele der NIS2-Anforderungen decken sich mit ISO 27001 Controls oder Grundschutz-Bausteinen. Aber: NIS2 bringt ein paar Extras, z.B. die Meldepflicht an Behörden, die explizite Managementhaftung und ggf. branchenspezifische Nuancen. Man sollte also die Zertifizierung nutzen, um den Großteil abzuhaken, aber gezielt prüfen, was darüber hinaus getan werden muss (z.B. Behördenkontaktstelle einrichten, Reporting-Fristen intern verankern). Sich alleine auf ein Zertifikat zu verlassen, ohne die spezifischen Gesetzesforderungen zu prüfen, wäre riskant.
• Irrtum: „Lieber keine Vorfälle melden – dann bleiben wir unter dem Radar.“ – Der Impuls, Sicherheitsvorfälle totzuschweigen, um keine schlafenden Hunde zu wecken, ist verständlich, aber gefährlich. Erstens: Wenn etwas meldepflichtig ist und man es unterschlägt, begeht man einen Rechtsverstoß, der bei Auffliegen zu heftigen Bußgeldern führen kann (und erfahrungsgemäß kommt vieles doch irgendwann raus, sei es durch Presse oder Partner). Zweitens: Die Behörden wollen mit den Meldungen ja gerade unterstützen, nicht primär bestrafen. Wer kooperativ meldet, zeigt Bereitschaft zur Transparenz – das kann im Zweifel milder bewertet werden als Vertuschung. Also: Im Ernstfall Meldung machen, professionell und fristgerecht. “Under the radar” funktioniert in der heutigen vernetzten Welt selten lange.
• Irrtum: „Das schaffen wir nebenbei, ohne extra Ressourcen.“ – Die Einführung von NIS2-Maßnahmen erfordert Zeit, Know-how und oft auch Geld. Wer denkt, das könne der vorhandene IT-Betrieb mal nebenbei mitmachen, während er ohnehin die tägliche Arbeit stemmt, läuft Gefahr, wichtige Punkte zu übersehen oder auf halbem Wege stecken zu bleiben. Realistischer ist, für die Projektphase dedizierte Ressourcen einzuplanen – sei es interne Mitarbeiter, die temporär entlastet werden von anderen Aufgaben, oder externe Unterstützung. Auch Schulungen verursachen Aufwand (Mitarbeiter fehlen produktiv für ein paar Stunden). Kurz: Ohne Investition kein Ertrag. Dieses Bewusstsein muss gerade dem Management vermittelt werden, damit genug Mittel bereitgestellt werden.
• Irrtum: „Nach dem Stichtag ist alles fertig.“ – Ein trügerisches Licht am Ende des Tunnels: Sicherheit ist niemals “fertig”. NIS2 fordert explizit kontinuierliche Verbesserung, regelmäßige Reviews und Anpassungen. Die Bedrohungslage ändert sich, die Technik entwickelt sich weiter, das eigene Unternehmen wandelt sich – all das erfordert ständige Aufmerksamkeit. Es wäre fatal, nach initialer Umsetzung in den Schlummermodus zurückzufallen. Vielmehr muss man NIS2 als permanente Aufgabe verstehen, ähnlich wie Qualitätssicherung oder Finanzcontrolling. Das heißt nicht, dass man ständig im Alarmzustand leben muss, aber regelmäßige Checks und Aktualisierungen gehören einfach zum neuen Normal dazu.
• Irrtum: „Unser Outsourcing-Partner macht das schon.“ – Die Verantwortung kann man nicht komplett outsourcen. Auch wenn man Dienste auslagert, bleibt man als Unternehmen in der Pflicht zu prüfen und sicherzustellen, dass Dienstleister NIS2-konform handeln. Wenn etwa Ihre Systeme in der Cloud oder bei einem IT-Dienstleister laufen, müssen Sie trotzdem für angemessene Sicherheit sorgen – durch Auswahl seriöser Provider, vertragliche Vereinbarungen (z.B. zu Sicherheitsniveau, Audit-Rechten) und Kontrolle. NIS2 dehnt sich über die Lieferkette aus: “aus den Augen, aus dem Sinn” funktioniert nicht mehr. Also keine falsche Sicherheit: Lieferantenrisiken immer mitdenken.
• Irrtum: „NIS2 ist reine Bürokratie ohne Mehrwert.“ – Solche Einstellung führt zu halbherziger Umsetzung. Tatsächlich verbessert man durch NIS2 die eigene Abwehrfähigkeit. Die Bürokratie dahinter ist Mittel zum Zweck, nicht Selbstzweck. Dokumentation, Policies und Reporting sind Werkzeuge, um Sicherheit greifbar und überprüfbar zu machen. Wer nur lustlos Papier generiert, vergibt die Chance, wirklich sicherer zu werden. Besser: NIS2 als Chance begreifen, endlich Dinge zu tun, die man vielleicht lange aufgeschoben hat (z.B. umfassendes Rechtekonzept, Netzwerksegmentierung, Notfallübungen). So hat man am Ende echten Mehrwert – weniger Angriffsfläche, mehr Robustheit –, und nicht nur einen Ordner voller Vorschriften.

Wenn man diese Stolperfallen kennt, kann man ihnen bewusst entgegenwirken. Oft hilft Aufklärung und Kommunikation – intern wie extern – um falsche Vorstellungen zu korrigieren. NIS2 ist anspruchsvoll, aber machbar, solange man mit den richtigen Annahmen und einer Portion gesundem Menschenverstand an die Sache herangeht.

Management-Kommunikation

Eine oft unterschätzte Komponente der NIS2-Umsetzung ist die Kommunikation mit dem Management. Die besten technischen Maßnahmen nützen wenig, wenn Vorstand oder Geschäftsführung nicht richtig abgeholt werden – sei es, um Entscheidungen zu treffen, Budget freizugeben oder schlicht ihrer eigenen neuen Verantwortung gerecht zu werden. Hier einige Leitlinien, wie man das Top-Management ins Boot holt:

Aufklärung statt Fachchinesisch: Das oberste Gebot: Sprechen Sie die Sprache des Managements. Ein CEO oder Finanzvorstand möchte keine Firewall-Logfiles sehen und keine Abkürzungen wie SIEM, CVSS oder TLS 1.2 entschlüsseln müssen. Übersetzen Sie die technischen Risiken in geschäftliche Auswirkungen: Statt “Wir müssen MFA einführen, weil es sicherer ist” lieber “Wenn wir keinen zweiten Anmeldeschritt haben, kann ein gestohlenes Passwort unseren gesamten Betrieb lahmlegen – das würde Produktionsausfälle und Umsatzeinbußen bedeuten.” Klare, greifbare Beispiele funktionieren am besten. Z.B.: “Ein ungepatchter Server ist wie ein unverschlossenes Lagerhaus – früher oder später bemerkt es jemand Fremdes.” Solche Bilder bleiben hängen und vermitteln die Botschaft ohne Techniksprache.

Risiken quantifizieren und priorisieren: Management liebt Zahlen. Wenn möglich, unterlegen Sie Ihre Argumente mit quantifizierten Risiken: “Das jährliche Cyber-Risiko für uns wird auf X Euro geschätzt, dem stehen Y Euro Aufwandskosten für Sicherheitsmaßnahmen gegenüber.” oder “Die Wahrscheinlichkeit eines ernsthaften Sicherheitsvorfalls in unserer Branche liegt bei Z% pro Jahr.” Natürlich sind solche Zahlen mit Vorsicht zu genießen, aber sie geben der Führungsetage ein Gefühl für Größenordnungen. Priorisieren Sie zudem klar: welche “Baustellen” sind kritisch (Rot), welche mittelfristig anzugehen (Gelb) und welche laufen gut (Grün). Ein Ampelchart über den Status der Compliance kann Wunder wirken – es macht abstrakte Security-Themen für Entscheider verständlich. Niemand will rote Ampeln im Bericht sehen, also entsteht automatisch ein Anreiz, Ressourcen für “Rot-Themen” bereitzustellen.

Pflichten und Haftung transparent machen: Während man den Teufel nicht an die Wand malen sollte, darf doch ruhig erwähnt werden, dass NIS2 rechtlich bindend ist und die Geschäftsleitung in der Pflicht steht. Viele Manager realisieren erst dann die Ernsthaftigkeit, wenn Begriffe fallen wie “gesetzliche Pflicht”, “Haftung” oder “Bußgeld”. Ohne Panik zu schüren kann man z.B. sagen: “Die NIS2-Regularien schreiben uns das verbindlich vor – bei Verstößen drohen ähnlich hohe Strafen wie bei der DSGVO. Außerdem muss die Geschäftsführung persönlich gewisse Sorgfaltspflichten erfüllen, sonst könnten im Extremfall Haftungsfragen aufkommen.” Spätestens hier hat man die ungeteilte Aufmerksamkeit im Raum. Wichtig ist aber, gleich nachzuschieben: “Wir haben einen Plan, wie wir diese Pflichten erfüllen.” – also nicht in Schockstarre enden, sondern Lösungsweg präsentieren.

Lösungsorientiert kommunizieren: Chefs hören ungern nur von Problemen; sie wollen Optionen und Lösungen. Bereiten Sie daher für identifizierte Risiken oder Compliance-Lücken gleich Vorschläge vor: “Wir haben keine 24/7-Überwachung – meine Empfehlung: entweder einen Managed Service beauftragen oder zwei neue Stellen schaffen, um eine Rufbereitschaft aufzubauen.” Oder: “Uns fehlt eine Notfallkommunikationsstruktur, Vorschlag: Wir richten einen Notfall-Messenger ein und schulen das Krisenteam entsprechend.” So fühlt sich das Management nicht alleingelassen mit einem Problem, sondern sieht, dass Ihr Team proaktiv die Umsetzung gestaltet. Das steigert das Vertrauen und die Bereitschaft, Ihre Vorschläge zu unterstützen.

Regelmäßiges Reporting etablieren: NIS2 verlangt ohnehin, dass die Leitung regelmäßig informiert wird. Richten Sie also feste Kommunikationsroutinen ein: z.B. ein vierteljährliches Cybersecurity-Update im Management-Meeting oder als schriftlicher Bericht. In diesem Bericht kann stehen: aktueller Stand der NIS2-Umsetzung, kürzlich aufgetretene Vorfälle (ggf. anonymisiert oder interne), erreichte Meilensteine und offene Risiken. Halten Sie das Reporting knapp und auf den Punkt – ein zweiseitiges Dashboard mit Ampeln, Trends und kurzen Erläuterungen ist oft besser als 30 Seiten Fließtext. Dadurch bleibt das Thema präsent, und Führungskräfte sehen Fortschritte (oder werden bei Stillstand alarmiert). Zudem erzeugt es eine gewisse Verbindlichkeit: Wenn der Vorstand quartalsweise nachfragt “Wie stehen wir bei NIS2 da?”, sorgt das intern für den nötigen Druck, Aufgaben auch wirklich zu erledigen.

Den Spieß umdrehen – Management in die Pflicht nehmen: Kommunikation ist keine Einbahnstraße. Nutzen Sie Gelegenheiten, um die Verantwortung des Managements zu betonen – höflich, aber bestimmt. Zum Beispiel kann der CISO dem Geschäftsführer vorschlagen: “Es wäre gut, wenn Sie persönlich in der nächsten Betriebsversammlung ein paar Worte zur Wichtigkeit von Cybersecurity sagen – das würde allen zeigen, dass es Chefsache ist.” Oder bitten Sie um einen schriftlichen Management-Support-Brief an alle Mitarbeiter, der NIS2 erklärt und zur Mitwirkung aufruft. Wenn der Chef selbst predigt “Leute, Security ist uns wichtig, wir müssen das zusammen schultern”, hat das weit mehr Gewicht, als wenn es “nur die IT” sagt. Zudem sensibilisiert es die Führungskräfte selbst – sie sprechen es nicht nur aus, sondern verinnerlichen die Botschaft dabei.

Erfolge und Mehrwert aufzeigen: Last but not least: Zeigen Sie dem Management auch die positiven Seiten und Erfolge. Hat man z.B. durch neue Maßnahmen schon Angriffsversuche abgewehrt? Gab es eine Auditierung, die gut verlief? Ist die “Cyber-Versicherung” jetzt günstiger, weil man bessere Security vorweisen kann? Solche Success Stories sollten kommuniziert werden. Manager lieben es, wenn Investitionen sich bezahlt machen. Wenn Sie erklären können, dass durch NIS2-Compliance das Unternehmen vielleicht einen PR-GAU vermieden hat oder im Vergleich zur Konkurrenz besser aufgestellt ist, dann wird aus dem lästigen Pflichtprogramm plötzlich ein Wettbewerbsvorteil. Dieses Narrativ (“wir tun das nicht nur weil wir müssen, sondern weil wir dadurch sicherer und erfolgreicher werden”) sollte die Kommunikation durchziehen.

Insgesamt geht es darum, eine Brücke zwischen IT und Vorstandsetage zu schlagen. Der CIO/CISO wird zum Dolmetscher, der die komplexe Materie in strategische Bedeutung übersetzt. Gute Management-Kommunikation rund um NIS2 sorgt dafür, dass die Führung aktiv mitzieht statt nur widerwillig abzunicken. Und das ist entscheidend: Ohne echtes Commitment von oben läuft Security immer auf halber Flamme. Mit NIS2 hat man nun ein starkes Argument an der Hand, um dieses Commitment einzufordern und aufrechtzuerhalten.

Fazit

Die NIS2-Richtlinie sorgt zwar anfangs für Nervosität – zu Recht, denn sie bringt Pflichten und potentiellen Druck mit sich –, aber unterm Strich ist sie ein Anstoß in die richtige Richtung. Cybersicherheit wird zur Chefsache und zur Compliance-Pflicht: Das klingt im ersten Moment nach Mehrarbeit (und das ist es auch), doch am Ende profitieren die Unternehmen selbst davon. Wer die Vorgaben ernstnimmt, erhöht die Resilienz seiner IT-Landschaft und reduziert das Risiko, Opfer eines schweren Cyberangriffs zu werden. In Zeiten, in denen fast wöchentlich Firmen durch Ransomware in die Schlagzeilen geraten, kann das ein entscheidender Wettbewerbsvorteil sein.

Wichtig ist, NIS2 nicht als Panik-Thema oder rein bürokratische Übung zu behandeln, sondern als Projekt zur Verbesserung der eigenen Sicherheit. Mit einem planvollen Vorgehen, wie in diesem Leitfaden skizziert, lässt sich die große Aufgabe in machbare Etappen unterteilen. Viele Unternehmen werden feststellen: Man muss das Rad nicht neu erfinden. Bewährte Standards (ISO 27001, BSI-Grundschutz etc.) geben Orientierung, und viele technische Lösungen (gerade im Microsoft-Umfeld) sind bereits vorhanden und müssen “nur” konsequent eingesetzt werden. Der Schlüssel liegt in der Umsetzung und im Wandel der Gewohnheiten – vom gelegentlichen “Wir sollten mal” hin zum routinemäßigen “Wir machen”.

NIS2 zwingt uns, die Basics der IT-Sicherheit aufzuräumen und dauerhaft zu leben. Das kann unbequem sein, weil es vielleicht jahrelang aufgeschobene Hausaufgaben ans Licht bringt. Aber besser jetzt mit Rückenwind der Regulierung handeln, als später im Krisenmodus. Im besten Fall kann man intern argumentieren: “Wir tun das nicht nur, weil wir müssen, sondern weil wir unser Unternehmen schützen wollen. NIS2 gibt uns dabei nur den notwendigen Schubser.”

Für IT-Entscheider, CIOs und CISOs bedeutet NIS2: Endlich bekommt man die Chance (und den Hebel), Security-Themen durchzusetzen, die zuvor im Kampf um Ressourcen unterlagen. Für Administratoren bedeutet es: mehr Arbeit am Anfang, aber langfristig weniger Feuerwehreinsätze, weil ein stabiles Grundniveau geschaffen wird. Und für das Management bedeutet es: Verantwortung übernehmen, aber dadurch auch besser schlafen bei Nacht, weil man weiß, dass angemessen vorgesorgt ist.

Abschließend sei betont: NIS2-Compliance ist kein Zustand, sondern ein Prozess. Es wird anfangs holprig sein, man wird lernen und nachjustieren müssen. Aber mit jedem gemeisterten Schritt wächst die Sicherheit – und die Gelassenheit. In ein paar Jahren, so die Hoffnung, ist das, was heute “neue Vorschrift” ist, selbstverständlich in den Betriebsablauf integriert. Dann wird man zurückblicken und sich fragen, warum man eigentlich so nervös war. Bis dahin heißt es: anpacken, Schritt für Schritt, und aus der Pflicht das Beste machen – nämlich eine robuste, zukunftsfähige Cybersecurity im eigenen Haus.

FAQ (Häufige Fragen)

Frage: Wie finde ich heraus, ob NIS2 für unser Unternehmen gilt?
Antwort: Zunächst müssen Sie prüfen, ob Sie in einem der von NIS2 erfassten Sektoren tätig sind (z.B. Energie, Transport, Gesundheit, digitale Dienste, Herstellung bestimmter kritischer Güter usw.). Die vollständige Liste steht in den Anhängen der Richtlinie bzw. im neuen Gesetz. Wenn ja, kommt der zweite Schritt: erfüllen Sie die Größenkriterien? In der Regel gilt NIS2 für mittlere und große Unternehmen, also mehr als 50 Mitarbeiter oder über 10 Mio. € Umsatz/Jahresbilanz. Ist beides erfüllt – relevanter Sektor und ausreichend groß – dann fallen Sie unter NIS2. Beachten Sie aber Ausnahmen: Manche Sektoren (z.B. Telekommunikation, Cloud-Anbieter) sind unabhängig von der Größe dabei. Und umgekehrt: Sehr kleine Firmen (<50 Mitarbeiter) sind meistens ausgenommen, außer sie sind extrem sicherheitskritisch. Im Zweifel lohnt sich ein Blick in die Gesetzesbegründung oder eine Anfrage bei der zuständigen Behörde, um Klarheit zu bekommen.

Frage: Ab wann müssen wir NIS2-Compliance erfüllt haben? Gibt es eine Frist?
Antwort: Die EU-Richtlinie ist am 16. Januar 2023 in Kraft getreten und die EU-Länder hatten bis 17. Oktober 2024 Zeit, sie in nationales Recht zu übertragen. In Deutschland wurde das Umsetzungsgesetz im November 2025 verabschiedet und tritt voraussichtlich Anfang 2026 in Kraft – ab dann gelten die Pflichten hierzulande unmittelbar. Übergangsfristen sind (Stand jetzt) nicht vorgesehen, d.h. eigentlich müsste man ab Inkrafttreten compliant sein. Realistisch wird es aber eine Anlaufphase geben, in der die Behörden eher beratend als strafend auftreten, sofern erkennbar ist, dass man sich um Umsetzung bemüht. Dennoch: Je eher man die Vorgaben erfüllt, desto besser. In anderen Ländern der EU gelten ggf. schon ab Ende 2024 entsprechende Gesetze (z.B. in Frankreich, Niederlanden usw.). Für die DACH-Region kann man sagen: 2024/2025 war Vorbereitungszeit, ab 2026 wird es Ernst.

Frage: Wer überwacht die Einhaltung und wie läuft das ab?
Antwort: Die Aufsicht obliegt nationalen Behörden. In Deutschland ist das BSI (Bundesamt für Sicherheit in der Informationstechnik) zuständig. In Österreich wird es die nationale NIS-Koordinationsstelle (vermutlich im Innenministerium) sein, in der Schweiz fällt NIS2 formal nicht an, aber dort gibt es eigene Stellen für Kritische Infrastrukturen. Die Aufsichtsbehörde kann verschiedene Maßnahmen ergreifen: Sie kann Unternehmen auffordern, eine Selbstauskunft abzugeben, Audits anordnen (vor Ort oder remote), Schwachstellenscans durchführen, Dokumente anfordern etc. “Essential” (besonders wichtige) Unternehmen müssen mit proaktiven Prüfungen rechnen – d.h. das BSI könnte z.B. alle 2-3 Jahre vorbeischauen oder Prüfberichte verlangen. “Important” (wichtige) Unternehmen werden in der Regel reaktiv überwacht – das heißt, das BSI greift ein, wenn ein Vorfall gemeldet wurde oder ein Hinweis auf NIS2-Verstöße vorliegt. Unabhängig davon müssen aber alle Unternehmen im Fall eines erheblichen Sicherheitsvorfalls diesen melden (siehe nächste Frage), was ja auch eine Form der Aufsicht (über Meldungen) darstellt. Insgesamt wird die Kontrolle wohl ähnlich laufen wie bei Datenschutz oder alten KRITIS-Regeln: Man muss jederzeit mit einer Prüfung rechnen, daher ist es ratsam, sich gut vorzubereiten.

Frage: Was passiert, wenn wir gegen NIS2 verstoßen? Welche Strafen drohen?
Antwort: Bei Verstößen kann die Behörde Bußgelder verhängen – und die sind empfindlich. Für “besonders wichtige Einrichtungen” (vergleichbar mit größeren KRITIS-Betreibern) bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes (je nachdem, was höher ist). Für “wichtige Einrichtungen” bis zu 7 Mio. € oder 1,4 % vom Umsatz. Diese Obergrenzen ähneln denen der DSGVO und sollen Abschreckung bewirken. Zusätzlich können andere Maßnahmen folgen: Das BSI kann verbindliche Anordnungen erteilen (etwa bestimmte Sicherheitslücken zu schließen), im Extremfall sogar den Betrieb von IT-Systemen untersagen, bis Mängel behoben sind. Auch eine vorübergehende Suspendierung von Dienstleistungen ist als Sanktion theoretisch drin, wenn akute Gefahr besteht. Ein weiterer Aspekt ist die persönliche Haftung der Leitung: Sollte grobe Fahrlässigkeit im Spiel sein (Management komplett ignoriert seine Pflichten), könnten zivilrechtliche Haftungsfälle entstehen oder in einigen Ländern sogar die Abberufung von Vorständen erzwungen werden. Wichtig: Die Behörden werden vermutlich erst beratend und mahnend tätig, bevor sie maximal zuschlagen – außer bei krassen Missständen oder Vertuschung. Es liegt also im eigenen Interesse, frühzeitig zu kooperieren und Mängel selbst anzugehen, damit man gar nicht erst ins Visier für Bußgelder gerät.

Frage: Müssen wir uns bei irgendeiner Stelle melden oder registrieren, wenn wir unter NIS2 fallen?
Antwort: Ja, in Deutschland besteht eine Registrierungspflicht. Das neue Gesetz sieht vor, dass betroffene Unternehmen sich innerhalb von 3 Monaten nach Inkrafttreten (bzw. sobald sie feststellen, dass sie unter das Gesetz fallen) bei einer zentralen Meldestelle registrieren. Diese Meldestelle wird vom BSI gemeinsam mit dem Bundesamt für Bevölkerungsschutz (BBK) betrieben. Über ein Online-Portal muss man dort einige Basisdaten angeben – z.B. Firmendaten, Branche, vielleicht schon einen Sicherheitsverantwortlichen als Kontakt. Diese Registrierung dient dazu, dass die Behörden einen Überblick haben, wer alles reguliert ist. Wichtig: Mit der Registrierung “outet” man sich natürlich als betroffene Einrichtung, was aber ja ohnehin Pflicht ist. In Österreich und anderen EU-Ländern sind ähnliche Registrierungspflichten geplant oder teilweise schon umgesetzt. Wer bereits unter den alten KRITIS-Regeln registriert war, muss sich ggf. trotzdem neu/unterschiedlich registrieren, da der Adressatenkreis nun größer ist. Und keine Sorge: Registrieren heißt nicht automatisch, dass am nächsten Tag der Prüfer vor der Tür steht – aber es ist ein formaler Schritt, den man nicht vergessen darf.

Frage: Was genau zählt als erheblicher Sicherheitsvorfall, den man melden muss?
Antwort: Die Richtlinie spricht von “signifikanten Vorfällen” mit erheblichen Auswirkungen. Das ist teilweise qualitativ zu bewerten, aber es gibt auch Anhaltspunkte: Zum Beispiel wenn der Vorfall zu einer erheblichen Betriebsunterbrechung führt, viele Nutzer oder Kunden betroffen sind oder großer finanzieller Schaden entstanden ist (oder droht). Konkrete Schwellen können sein: ein Ausfall zentraler Dienste für mehr als 24 Stunden, ein finanzieller Schaden jenseits 500.000 €, oder der Diebstahl sensibler Daten in großem Umfang. Auch Vorfälle, die andere Unternehmen oder die öffentliche Sicherheit beeinträchtigen könnten (z.B. ein IT-Ausfall, der Lieferketten stört), wären meldepflichtig. In Deutschland wird vermutlich in einer Verordnung oder im BSI-Merkblatt präzisiert, was als “erheblich” gilt. Als Faustregel: Alles, was über den alltäglichen kleineren Sicherheitsvorfall (wie einen einzelnen Virenfund) hinausgeht und zu spürbaren Auswirkungen führt, sollte man mindestens intern als potentiell meldewürdig einstufen. Lieber ein Mal zu oft melden als zu wenig – im Zweifel kann man sich beim BSI auch beraten lassen, ob ein konkreter Vorfall meldepflichtig ist.

Frage: Wohin und wie müssen wir Vorfälle melden, und in welchem Zeitrahmen?
Antwort: In Deutschland werden Meldungen voraussichtlich über das BSI laufen. Bereits heute gibt es für KRITIS-Betreiber ein Meldeportal beim BSI (sogenanntes NIMES-Portal). Dieses wird man wohl für NIS2 erweitern. Die Meldung muss gestuft erfolgen: Innerhalb von 24 Stunden nach Bemerken des Vorfalls eine Erstmeldung (sozusagen “Alarm schlagen” – kurz umreißen, was passiert ist, ob es z.B. ein laufender Angriff ist). Dann innerhalb von 72 Stunden eine ausführlichere Meldung mit ersten Analyseergebnissen, betroffenem Umfang etc. Und schließlich binnen eines Monats ein Abschlussbericht, sobald man alles aufgearbeitet hat (inkl. Ursache, Schadenshöhe, ergriffene Maßnahmen etc.). Die Meldung erfolgt schriftlich/elektronisch; oft gibt es Formulare im Portal. Wichtig: Diese Fristen laufen ab dem Moment, wo Sie den Vorfall entdecken (nicht erst ab vollständiger Analyse). Also wenn man z.B. einen Ransomware-Angriff feststellt, sollte innerhalb 24h zumindest eine Kurzinfo ans BSI rausgehen, selbst wenn man noch nicht viel Details hat. Melden muss man an die nationale Behörde – bei grenzüberschreitenden Diensten ggf. auch an mehrere, aber in der Praxis kann man sich an seinen Sitz bzw. Hauptwirkungsland halten, die Behörden koordinieren sich dann untereinander und mit ENISA. Übrigens: So eine Meldung entbindet nicht davon, parallel auch andere Stellen zu informieren, falls relevant (z.B. Datenschutzbehörde bei personenbezogenen Datenverlust, oder Kunden bei Serviceausfällen, wenn vertraglich vorgesehen).

Frage: Wie verhält sich NIS2 zur DSGVO? Überschneiden sich die Pflichten (z.B. Meldung von Datenpannen)?
Antwort: NIS2 und DSGVO (Datenschutz-Grundverordnung) sind zwei getrennte Regelwerke – das eine für Cybersecurity, das andere für Datenschutz – aber es gibt Berührungspunkte. Zum Beispiel: Wenn ein Hackerangriff personenbezogene Daten abzieht, hat man sowohl eine DSGVO-Meldepflicht an die Datenschutzbehörde als auch eine NIS2-Meldung ans BSI, sofern es ein erheblicher Vorfall war. Das bedeutet, man muss unter Umständen zweigleisig berichten. Ideal ist, wenn man diese Prozesse abstimmt, damit z.B. Inhalte konsistent sind und man intern nicht doppelt Arbeit macht. In einigen Fällen kann die Meldung an eine Stelle auch die andere informieren – da gibt es aber noch keine etablierten Mechanismen. Am besten betrachtet man DSGVO und NIS2 als komplementär: DSGVO schützt Daten und die Rechte von Personen, NIS2 schützt die Infrastruktur und Kontinuität von Diensten. Ein Vorfall kann unter beide fallen (z.B. Ransomware auf Kundendatenbank: ist beides), oder nur unter eines (z.B. Ausfall einer Anlage ohne Datenabfluss: nur NIS2 relevant). In der Praxis lohnt es sich, bei der Incident-Planung beide Gesetze mitzudenken. Und nicht vergessen: DSGVO kennt streng genommen keine IT-Sicherheitsvorgaben, nur den Grundsatz “Stand der Technik” für Datenschutzmaßnahmen – NIS2 füllt diese Lücke, aber eben mit separater Zuständigkeit.

Frage: Wir sind ein Finanzunternehmen – gilt für uns nicht DORA anstelle von NIS2? Wie verhält sich das?
Antwort: DORA (Digital Operational Resilience Act) ist tatsächlich eine neue EU-Verordnung speziell für den Finanzsektor, die ab 2025 gilt. Sie enthält viele ähnliche Anforderungen wie NIS2 (IT-Risikomanagement, Incident Reporting, ICT Third-Party Risk). Wenn Sie z.B. eine Bank oder Versicherung sind, fallen Sie sowohl unter NIS2 (als Teil der Sektoren “Bankwesen” oder “Finanzmarkt-Infrastruktur”) als auch unter DORA. Das klingt nach Doppelregulierung, aber die EU hat versucht, die Vorgaben aufeinander abzustimmen. Im Idealfall können Sie mit einer integrierten Umsetzung beide erfüllen. DORA hat den Vorteil, dass es als Verordnung unmittelbar gilt und direkt sagt, was zu tun ist, während NIS2 über das nationale Gesetz kommt. Für die Praxis: Achten Sie darauf, beide Anforderungen parallel zu tracken. Oft deckt, wer DORA umsetzt, auch NIS2 damit ab und umgekehrt – aber prüfen Sie Feinheiten (z.B. Meldefristen sind leicht unterschiedlich; DORA verlangt 1 Monat und 1 Woche als finalen Bericht, NIS2 1 Monat). Möglicherweise werden die Finanzaufsichtsbehörden (BaFin in Deutschland) eng mit dem BSI kooperieren, um keine widersprüchlichen Auflagen zu geben. In jedem Fall: als Finanz-CISO sollte man ein kombiniertes Compliance-Projekt machen.

Frage: Brauchen wir jetzt eine ISO-27001-Zertifizierung, um NIS2 zu erfüllen?
Antwort: Eine ISO/IEC 27001 Zertifizierung ist nicht vorgeschrieben, kann aber sehr hilfreich sein. NIS2 verlangt kein bestimmtes Zertifikat oder Audit als Nachweis – man muss “nur” die Pflichten einhalten und im Zweifel der Behörde zeigen können, dass man das tut. Dennoch erwägen viele Unternehmen, ISO 27001 (ISMS) einzuführen, weil es einen strukturierten Rahmen bietet, der mit NIS2 fast vollständig deckungsgleich ist inhaltlich. Wer zertifiziert ist, kann bei einer Prüfung viele Dokumente und Prozesse vorweisen, die das NIS2-Compliance belegen. Man darf aber nicht dem Trugschluss erliegen: ISO-Zertifizierung = automatisch NIS2-konform. Man muss z.B. trotzdem sicherstellen, dass die speziellen NIS2-Sachen wie Behördenmeldungen, Registereintrag etc. beachtet wurden – das gibt ISO nicht vor. Umgekehrt ist auch ohne ISO-Zertifikat ein Unternehmen nicht automatisch schlecht aufgestellt. Viele KMUs werden kein ISO-Zert holen (weil aufwändig), aber dennoch die nötigen Maßnahmen umsetzen. Fazit: ISO 27001 ist ein sehr nützliches Werkzeug und ein starkes Signal an die Aufsicht (“wir machen nachweislich was”), aber es ist freiwillig. Ob man das Investment tätigt, hängt von der individuellen Lage ab. Manche Branchen (z.B. Automobilzulieferer mit TISAX) haben schon bestimmte Zertifikate, da sollte man Synergien nutzen.

Frage: Müssen wir einen eigenen IT-Sicherheitsbeauftragten oder CISO ernennen wegen NIS2?
Antwort: Die Richtlinie schreibt nicht wortwörtlich “Sie müssen einen CISO haben”, aber sie verlangt klare Zuständigkeiten und dass die Geschäftsleitung jemanden benennt bzw. selbst Verantwortung trägt. Praktisch wird es schwer, NIS2 umzusetzen, ohne eine definierte Rolle dafür. In größeren Unternehmen existiert meist schon ein CISO (Chief Information Security Officer) oder ein Informationssicherheits-Beauftragter (ISB). Falls nicht, sollte man diese Rolle schaffen – sei es intern (einen erfahrenen Mitarbeiter dafür abstellen) oder extern einkaufen (z.B. einen “Security Officer as a Service”). Wichtig ist, dass es eine Person gibt, die das Thema strategisch koordiniert und als Ansprechpartner für Management und Behörde fungiert. Bei kleineren Unternehmen wird es oft der IT-Leiter mit “Doppelhut” sein. Zudem fordert das Gesetz eine Kontaktstelle für die Behörde – das sollte auch jemand sein, der sich mit Security auskennt. Also kurz gesagt: Ja, man sollte jemanden offiziell zum Sicherheitsverantwortlichen ernennen, auch wenn es intern bleibt. Dieser braucht dann aber auch Rückendeckung und Weiterbildung, um die Aufgabe wahrnehmen zu können.

Frage: Wir haben keine eigene Security-Abteilung. Sollen wir externe Hilfe in Anspruch nehmen?
Antwort: Das hängt vom Einzelfall ab, aber viele Mittelständler werden sinnvollerweise externen Sachverstand hinzuziehen. Möglichkeiten: Man kann Berater engagieren für die Gap-Analyse und Projektplanung, man kann einen externen Informationssicherheitsbeauftragten bestellen, der ein paar Tage im Monat die Firma betreut, oder spezifische Dienste (z.B. ein Security Operations Center als Service für 24/7 Monitoring) zukaufen. NIS2 verlangt nicht, dass alles inhouse erledigt wird. Outsourcing von Security ist erlaubt, nur muss man es steuern und vertraglich absichern. Ein externer Partner kann Know-how liefern, das intern fehlt, und hilft, Best Practices schneller umzusetzen. Wichtig: Die Verantwortung bleibt trotzdem beim Unternehmen selbst. Man kann nicht im Ernstfall sagen “Mein Dienstleister hat’s verbockt” – das entbindet nicht von der Pflicht. Aber gerade initial, um die Compliance herzustellen, können Externe den Prozess beschleunigen. Oft macht eine Mischform Sinn: interne Ressourcen aufbauen und punktuell Externe nutzen. Das zeigt auch dem BSI, dass man das Thema ernstnimmt (z.B. “Wir haben uns Expertise eingekauft, um Schwachstellen zu identifizieren.”).

Frage: Müssen wir jetzt ein eigenes 24/7 Security Team (SOC) aufbauen?
Antwort: Nicht zwangsläufig mit eigenem Personal, aber die Anforderungen implizieren, dass Sie irgendwie sicherstellen, schwere Vorfälle möglichst rasch zu bemerken und zu handeln – und das theoretisch rund um die Uhr. Ein kleines Unternehmen wird kaum eine Nachtschicht Security-Analysten einstellen; hier kann man mit Alarmierungslösungen arbeiten (wichtige Ereignisse schicken SMS an Administratoren) oder einen externen Monitoring-Dienst beauftragen, der nachts auf die Konsole schaut. Größere Unternehmen ab einer gewissen Größe und Risikoprofil werden möglicherweise tatsächlich ein internes Security Operations Center (SOC) einrichten oder ausbauen, um den Anforderungen gerecht zu werden. Es gibt keine harte Vorgabe “Sie brauchen X Mitarbeiter, die 24/7 da sitzen”, aber wenn ein Vorfall nachts um 3 auftritt und man merkt es erst am nächsten Morgen um 8, könnte das kritisch sein – vor allem wenn dadurch die 24h-Meldefrist gerissen wird. Daher sollte man zumindest einen Bereitschaftsplan haben: Wer ist außerhalb der Geschäftszeiten erreichbar? Wie läuft die Alarmierung? Eventuell rotiert man einen On-Call-Dienst durch das Team. Bei ganz kleinen Firmen mag es der Chef selbst sein, der angerufen wird, wenn’s brennt. Das Entscheidende ist: Es muss überhaupt jemand reagieren können. Die Behörden erwarten nicht zwingend High-Tech Cyberabwehr rund um die Uhr bei jedem Mittelständler, aber eben auch keine komplette Funkstille an Wochenenden. Eine pragmatische Lösung für viele ist, dass man eine externe Alarmüberwachung nutzt – viele IT-Dienstleister bieten so etwas an.

Frage: Was machen wir, wenn wir bis zum Inkrafttreten nicht alles umsetzen können? Gibt es Nachsicht?
Antwort: Wahrscheinlich wird kein Unternehmen am Tag X zu 100% fertig sein – das wissen auch die Behörden. Wichtig ist, dass Sie nachweisen können, dass Sie dran sind. Wenn z.B. Ende 2025 ein Prüfbrief käme, und Sie können sagen: “Wir haben bereits Projekt gestartet, Budget allokiert, hier ist der Zeitplan, die größten Risiken sind schon adressiert, weitere Punkte folgen bis Datum Y.” – dann stehen Sie deutlich besser da, als wenn nichts passiert ist. Es ist davon auszugehen, dass gerade Anfangs die Aufsicht eher beratend unterstützt, sofern erkennbar ist, dass ein Unternehmen willens ist und Fortschritte macht. Natürlich sollte man Kernaspekte priorisieren (z.B. Meldefähigkeit sofort schaffen, Kontaktdaten ans BSI melden). Wenn man z.B. noch nicht alle Lieferantenverträge angepasst hat oder noch nicht jeden Mitarbeitenden geschult, ist das kein Weltuntergang – sollte aber bald nachgeholt werden. Offiziell gibt es keine “Schonfrist”, aber inoffiziell wird man wohl Anfang 2026 nicht gleich mit Bußgeldern überzogen, solange keine grobe Fahrlässigkeit vorliegt. Nichtsdestotrotz: Auf Zeit spielen ist gefährlich. Ein echter Vorfall kann jederzeit passieren, und dann wäre man froh, die Hausaufgaben schon gemacht zu haben. Deshalb lieber jetzt Gas geben, auch wenn man nicht jeden Punkt fristgerecht schafft – jeder umgesetzte Baustein reduziert das Risiko und zeigt im Zweifel guten Willen.

Frage: Gibt es Unterstützung von staatlicher Seite, z.B. Förderprogramme oder Hilfestellungen?
Antwort: In einigen Fällen ja. In Deutschland gab es z.B. das Förderprogramm “Digital Jetzt” (vom BMWi) oder Brancheninitiativen, die auch IT-Sicherheitsprojekte fördern – solche Töpfe ändern sich aber über die Zeit. Es lohnt sich, regional zu schauen: Manche Bundesländer bieten Mittelstandsförderungen für IT-Sicherheit an. Unabhängig von Geld gibt es auch viel inhaltliche Hilfestellung: Das BSI veröffentlicht bestimmt Handreichungen und branchenspezifische Empfehlungen zu NIS2. ENISA (die EU-Agentur) stellt bereits jetzt Leitfäden bereit (z.B. zu Supply Chain Security, zu Incident Reporting Best Practices). Diese kann man kostenlos nutzen. Branchenverbände (Bitkom, IHKs, Handwerkskammern etc.) organisieren Info-Veranstaltungen, Webinare oder stellen Checklisten zur Verfügung. Nutzen Sie diese Ressourcen – sie helfen, nicht alles selbst ausknobeln zu müssen. Und last but not least: Der Erfahrungsaustausch mit anderen Unternehmen (z.B. in Erfahrungskreisen oder auf Konferenzen) kann viel wert sein, um praktische Tipps zu bekommen, wie andere die Umsetzung stemmen.

Frage: Wie können wir der Geschäftsleitung am besten erklären, warum NIS2 wichtig ist?
Antwort: Wahrscheinlich ist diese Frage schon halb beantwortet, wenn man bis hierhin gelesen hat. Trotzdem: Am besten betonen Sie zwei Aspekte gegenüber der Führung: (1) die rechtliche Verbindlichkeit – sprich, wir müssen das tun, um keine Gesetzesverstöße zu riskieren (inkl. persönlicher Haftung, siehe oben), und (2) den business case dahinter – nämlich dass bessere Cybersecurity letztlich das Unternehmen schützt. Man kann konkrete Beispiele aus der eigenen Branche parat haben (“Wissen Sie noch, Firma XYZ, die wochenlang stillstand? So etwas soll uns nicht passieren – NIS2 hilft uns, Vorsorge zu treffen”). Auch der Hinweis, dass Kunden und Partner zunehmend auf Cybersecurity pochen, zieht oft: Ein Vorstand möchte nicht, dass die Firma schlecht dasteht oder Aufträge verliert, weil man Sicherheitsauflagen nicht erfüllt. Wichtig ist, nicht nur Angstkarten zu spielen, sondern auch Lösungswege und Vorteile zu schildern: “Wenn wir das ordentlich umsetzen, sind wir im Ernstfall handlungsfähig und können mit Behörden und Kunden offen umgehen, statt kopflos zu improvisieren.” Und: Übersetzen Sie es in die Sprache des Managements (Risiken, Kosten, Chancen – kein Tech-Slang). Dann wird die Einsicht wachsen, dass NIS2 nicht “noch so ein Bürokratiemonster” ist, sondern essentiell fürs Geschäft.

Glossar

• NIS2 (Network and Information Security Directive) – EU-Richtlinie 2022/2555 zur Cybersicherheit. Sie baut auf der ersten NIS-Richtlinie (2016) auf und erweitert sowie verschärft die Anforderungen. Ziel: Ein hohes, einheitliches Sicherheitsniveau für Netzwerke und Informationssysteme in der EU. In Kraft seit Jan 2023, umzusetzen in nationales Recht bis Okt 2024. In Deutschland oft als “NIS2-Umsetzungsgesetz” bezeichnet.
• BSI (Bundesamt für Sicherheit in der Informationstechnik) – Die nationale Cyber-Sicherheitsbehörde in Deutschland. Zuständig für den Schutz staatlicher IT und als Aufsichtsbehörde für die Wirtschaft im Rahmen von NIS2 (und zuvor KRITIS). Das BSI gibt auch Standards (IT-Grundschutz) heraus und unterstützt bei Prävention und Reaktion auf IT-Gefahren. In Österreich vergleichbar: das BMI/BSIG; in der Schweiz: MELANI bzw. das Nationale Zentrum für Cybersicherheit.
• KRITIS (Kritische Infrastrukturen) – Begriff aus dem deutschen IT-Sicherheitsgesetz. Bezeichnet Organisationen aus lebenswichtigen Sektoren (Energie, Wasser, Gesundheit etc.), deren Ausfall gravierende Folgen hätte. Diese unterlagen schon vor NIS2 besonderen Pflichten (BSI-KritisV). NIS2 greift dieses Konzept auf, erweitert es aber (um “wichtige Einrichtungen”). “KRITIS-Unternehmen” ist umgangssprachlich für besonders wichtige Einrichtungen.
• Wichtige vs. besonders wichtige Einrichtung – Neue Kategorien im NIS2-Kontext (deutsche Terminologie). “Besonders wichtig” entspricht “Essential Entities”: meist große und kritische Betreiber (z.B. Stromnetzbetreiber, große Kliniken, zentrale Regierungsstellen). “Wichtig” entspricht “Important Entities”: wichtige, aber etwas weniger kritische Unternehmen (z.B. mittelgroße Industriebetriebe, Anbieter digitaler Dienste). Unterschiede liegen vor allem im Aufsichtsregime (proaktiv vs. reaktiv) und Bußgeldrahmen, nicht so sehr in den Pflichten – die müssen beide erfüllen.
• ENISA (European Union Agency for Cybersecurity) – Die EU-Agentur für Cybersicherheit mit Sitz in Griechenland. ENISA unterstützt die Mitgliedstaaten, erarbeitet Leitfäden, führt Übungen durch und betreibt z.B. die geplante europäische Schwachstellendatenbank. Sie koordiniert auch das CSIRT-Netzwerk der EU. Im Rahmen von NIS2 hat ENISA eine verstärkte Rolle, etwa bei der Sammlung anonymisierter Vorfallsberichte und im Krisenmanagement (EU-CyCLONe).
• CSIRT/CERT – “Computer Security Incident Response Team” (bzw. Computer Emergency Response Team). Ein CSIRT ist ein spezialisiertes Team, das auf Sicherheitsvorfälle reagiert und Hilfe leistet. Es gibt firmeninterne CSIRTs (Incident Response Teams) und nationale CSIRTs (z.B. CERT-Bund beim BSI). NIS2 fordert, dass Staaten solche Stellen benennen, und Unternehmen im Ernstfall mit ihnen kooperieren. Firmen sollten zumindest intern eine Art “IRT” haben, also definierte Personen, die im Notfall handeln.
• Meldepflicht – Die Verpflichtung, bestimmte Sicherheitsvorfälle an die Behörde zu melden. Unter NIS2 gestaffelt (24h, 72h, 1 Monat für verschiedene Berichtstiefen). Ziel ist, Behörden einen Überblick zu geben und ggf. warnend eingreifen zu können (z.B. andere warnen, Hilfe leisten). Die Meldepflicht ist ähnlich der Datenschutz-Meldepflicht, aber bezieht sich auf die Aufrechterhaltung von Diensten und IT-Sicherheit, nicht nur auf personenbezogene Daten. Nicht jeder kleine Vorfall ist meldepflichtig – nur erhebliche, qualifizierte Incidents.
• Sicherheitsvorfall (Incident) – Ein Ereignis, das die Sicherheit von Informationen oder IT-Systemen beeinträchtigt. Das kann ein Cyberangriff sein (Hackerangriff, Malware, DDoS) oder auch ein technisches Versagen (Netzausfall, Servercrash) – wobei NIS2 vor allem absichtliche, bösartige Ereignisse im Blick hat. Wichtige Parameter: Vertraulichkeit, Integrität oder Verfügbarkeit von Infosystemen werden verletzt. NIS2 verlangt Incident-Handling-Prozesse: Vom Erkennen über Reaktion bis zur Wiederherstellung. “Security Incident” und “IT-Sicherheitsvorfall” werden oft synonym verwendet.
• ISMS (Informationssicherheits-Managementsystem) – Ein Managementsystem, das alle Prozesse und Maßnahmen zur Informationssicherheit planvoll steuert. Oft nach Normen wie ISO 27001 strukturiert. Ein ISMS umfasst Policies, Risikobeurteilung, Maßnahmen, Verantwortlichkeiten, Schulungen, Monitoring und kontinuierliche Verbesserung im PDCA-Zyklus. NIS2 fordert faktisch, dass Organisationen ein solches systematisches Vorgehen haben (auch wenn das Wort ISMS nicht explizit fällt). Ein etabliertes ISMS erleichtert die NIS2-Compliance erheblich.
• ISO/IEC 27001 – International anerkannter Standard für Informationssicherheits-Managementsysteme. Organisationen können sich danach zertifizieren lassen. Die Norm gibt einen Rahmen vor (Anforderungen an das Managementsystem) und enthält einen Anhang mit Kontrollmaßnahmen (ISO 27002) wie Zugangskontrolle, Kryptographie, physische Sicherheit etc. ISO 27001 deckt viele NIS2-Themen ab. Ein Unterschied: ISO-Zertifizierung ist freiwillig und wird von Auditoren geprüft, während NIS2 gesetzlich verpflichtend ist und von Behörden überwacht wird.
• IT-Grundschutz – Ein vom BSI entwickelter Ansatz zur Informationssicherheit. Enthält ein Kompendium mit Best Practices (“Bausteine”) für unterschiedliche Bereiche (Netzwerke, Server, Personal, Notfallmanagement usw.). Unternehmen können sich nach Grundschutz zertifizieren lassen (ähnlich ISO, aber speziell auf BSI-Methodik). Grundschutz ist insbesondere im deutschen Behörden- und KRITIS-Umfeld verbreitet. Auch er deckt die wesentlichen Anforderungen von NIS2 ab – teilweise noch konkreter für den deutschen Kontext. Viele Mittelständler nutzen Grundschutz-Standards als praktische Anleitung.
• Stand der Technik – Ein juristischer Begriff, der das Niveau bezeichnet, das in Wissenschaft und Technik als fortschrittlich und angemessen anerkannt ist. In Sachen IT-Sicherheit bedeutet es: die gängigen, erprobten Maßnahmen, die aktuell als notwendig gelten, sollte man umgesetzt haben. Was “Stand der Technik” genau ist, ändert sich über die Zeit (z.B. vor 10 Jahren war MFA kein Standard, heute schon). NIS2 fordert Maßnahmen nach Stand der Technik – das heißt, Unternehmen dürfen sich nicht auf veralteten Schutz verlassen, sondern müssen mit der Entwicklung Schritt halten. Orientieren kann man sich an Normen, BSI-Empfehlungen und dem, was in der Branche üblich ist.
• Lieferkettensicherheit (Supply Chain Security) – Maßnahmen, um die IT-Sicherheit entlang der gesamten Wertschöpfungs- und Lieferkette zu gewährleisten. Dazu gehört, Risiken durch Dienstleister und Zulieferer zu identifizieren und zu minimieren. Praktisch: Sicherheitsanforderungen in Verträge schreiben, Nachweise von Partnern verlangen (z.B. Zertifikate, Prüfberichte), wichtige Drittanbieter regelmäßig beurteilen (Risiko-Assessment) und Notfallpläne haben, falls ein kritischer Zulieferer ausfällt oder gehackt wird. NIS2 betont Lieferkettensicherheit, weil Angreifer häufig über schwächere Partner ins Zielnetz gelangen.
• Resilienz (Cyber-Resilience) – Widerstandsfähigkeit gegenüber Störungen und Angriffen. In der IT meint es die Fähigkeit, trotz Attacken oder Ausfällen kritische Dienstleistungen weiterzuführen bzw. schnell wiederherzustellen. Ein resilienter Betrieb hat also nicht nur starke Abwehr (Prävention), sondern auch robuste Reaktions- und Wiederanlaufkonzepte. NIS2 hat ausdrücklich das Ziel, die Cyber-Resilienz in Europa zu steigern – daher die Anforderungen an Business Continuity, Incident Response, Redundanzen etc.
• Multi-Faktor-Authentifizierung (MFA) – Ein Anmeldeverfahren, das mehr als einen Nachweis der Identität erfordert. Typischerweise etwas, das man weiß (Passwort) + etwas, das man hat (Smartphone-App/Token) oder ist (Fingerabdruck). Beispiele: SMS-TAN, Authenticator-App, FIDO2-Token. MFA erschwert Kontoübernahmen enorm, weil ein Passwort allein nicht genügt. NIS2 fordert den Einsatz von MFA “wo angemessen” – insbesondere bei administrativen Zugängen oder Fernzugriffen. In der Praxis gilt MFA mittlerweile als unverzichtbarer Sicherheitsstandard.
• Penetrationstest (Pentest) – Ein simulierter Angriff auf die eigene IT, durchgeführt von Sicherheitsexperten (intern oder extern), um Schwachstellen aufzudecken. Die “Penetration Tester” nutzen Hacker-Methoden, bleiben aber legal im Auftrag der Firma. Ergebnis ist ein Bericht, welche Lücken gefunden wurden und wie schwerwiegend diese sind. NIS2 erwähnt Tests und Audits als Teil der Wirksamkeitsprüfung von Sicherheitsmaßnahmen. Regelmäßige Pentests (z.B. jährlich) sind sinnvoll, vor allem bei internet-exponierten Systemen, um sicherzustellen, dass keine kritischen Schwachstellen unentdeckt bleiben.

Die wichtigsten Do’s und Don’ts

Do’s – Was man tun sollte:
– Frühzeitig loslegen: Beginnen Sie so früh wie möglich mit der Vorbereitung auf NIS2. Zeit ist knapp – wer jetzt proaktiv startet, vermeidet Hektik kurz vor Torschluss.
– Geltungsbereich klären: Analysieren Sie gründlich, ob und welche Teile Ihres Unternehmens betroffen sind. Klarheit darüber spart später Fehlalarm oder böse Überraschungen.
– Risiken priorisieren: Konzentrieren Sie sich auf die größten Baustellen zuerst. Adressieren Sie kritischste Schwachstellen und Risiken mit höchster Priorität, statt sich in Kleinigkeiten zu verlieren.
– Management einbeziehen: Machen Sie Cybersecurity zur Chefsache – informieren und involvieren Sie die Geschäftsleitung regelmäßig. Top-Down-Unterstützung ist entscheidend für Ressourcen und Durchsetzung.
– Mitarbeiter sensibilisieren: Setzen Sie auf regelmäßige Schulungen und Awareness-Maßnahmen für alle Beschäftigten. Ein aufgeklärter Mitarbeiter ist die beste Firewall gegen Phishing & Co.
– Dokumentieren & Nachweise sichern: Halten Sie alle relevanten Policies, Prozesse, Berichte und Ereignisse schriftlich fest. Gute Dokumentation ist Gold wert – intern zur Orientierung und extern als “Proof” bei Audits.
– Security in Prozesse integrieren: Verankern Sie Sicherheitschecks in bestehende Abläufe (Change Management, Beschaffung, Entwicklung). So wird Sicherheit Teil des Alltags und nicht etwas, das man extra oben drauf packt.
– Standards & Hilfe nutzen: Orientieren Sie sich an etablierten Standards (ISO 27001, BSI-Grundschutz) und Hilfsmitteln (Leitfäden, Checklisten). Man muss das Rad nicht neu erfinden – lernen Sie von Best Practices.
– Notfall üben: Testen Sie Ihre Incident Response und Notfallpläne in Drillübungen. Nur wer geprobt hat, bleibt im Ernstfall ruhig und weiß, was zu tun ist.
– Offen kooperieren: Suchen Sie den Dialog mit Behörden und Branchenkollegen. Bei Unklarheiten lieber beim BSI nachfragen oder Rat einholen – das wird positiv gewertet und verbessert die Umsetzung.

Don’ts – Was man vermeiden sollte:
– Nicht in Panik verfallen: Überstürzte Aktion oder Lähmung vor Angst sind gleichermaßen schlecht. Behalten Sie einen kühlen Kopf und gehen Sie das Thema strukturiert an.
– NIS2 nicht ignorieren: Wegducken oder hoffen, “das betrifft uns schon nicht”, ist gefährlich. Das Gesetz gilt – Nichtstun könnte teuer werden.
– Kein IT-Silo draus machen: Schieben Sie NIS2 nicht allein der IT zu, während der Rest der Firma weitermacht wie bisher. Security ist Teamaufgabe – bereichsübergreifend.
– Keine Papiertiger produzieren: Vermeiden Sie es, nur auf dem Papier Compliance zu markieren (z.B. Policies erstellen und dann im Schrank verschwinden lassen). Maßnahmen müssen gelebt werden, sonst nützen sie nichts.
– Nicht nur einmal abhaken: Sehen Sie NIS2 nicht als einmaliges Projekt, das erledigt ist und dann ad acta gelegt wird. Kontinuität ist gefragt – planen Sie dauerhaftes Sicherheitsmanagement ein.
– Gefahren nicht bagatellisieren: Unterschätzen Sie nicht das Risiko von Cyberangriffen (“uns hackt doch keiner”). Diese Attitüde führt zu Nachlässigkeit – genau die Lücke, die Angreifer suchen.
– Vorfälle nicht vertuschen: Wenn etwas passiert, schämen Sie sich nicht, es zu melden. Der Versuch, einen ernsten Vorfall unter den Teppich zu kehren, ist riskanter als Offenheit – technisch wie juristisch.
– Nicht blind auf Tools vertrauen: Kaufen Sie nicht wahllos Sicherheitsprodukte in der Hoffnung, damit sei alles erledigt. Technik ist nur so gut wie ihre Konfiguration und die Menschen, die sie bedienen. Konzepte und Prozesse müssen drumherum stimmen.
– Lieferanten nicht vergessen: Vernachlässigen Sie nicht die Sicherheit Ihrer Dienstleister und Zulieferer. Deren Probleme können schnell zu Ihren werden – man denke an Attacken über Software-Updates etc.
– One-size-fits-all vermeiden: Kopieren Sie keine Lösung 1:1 von woanders, ohne zu prüfen, ob sie für Ihr Unternehmen passt. Jedes Unternehmen hat andere Risiken – setzen Sie Maßnahmen gezielt und angepasst ein, statt Checkboxen abzuhaken ohne Sinn und Verstand.