ISMS nach NIS2 aufbauen: 10-Wochen-Plan für KMU

1. Rechtsbasis: NIS2 vs. ISO 27001

NIS2 verlangt kein zertifiziertes ISMS, sondern ein Ergebnis: § 30 Abs. 1 BSIG verpflichtet besonders wichtige und wichtige Einrichtungen zu geeigneten, verhältnismäßigen und wirksamen technischen und organisatorischen Maßnahmen, um Störungen von Verfügbarkeit, Integrität und Vertraulichkeit ihrer IT-Systeme zu vermeiden und die Auswirkungen von Sicherheitsvorfällen gering zu halten — und die Einhaltung ist zu dokumentieren. § 30 Abs. 2 Satz 1 BSIG ergänzt den Maßstab: Die Maßnahmen sollen den Stand der Technik einhalten, die einschlägigen europäischen und internationalen Normen berücksichtigen und müssen auf einem gefahrenübergreifenden Ansatz beruhen. Ein ISMS ist der etablierte Weg, dieses Ergebnis nachvollziehbar und prüfbar zu erzeugen.

Wie weit trägt ein bestehendes Zertifikat? ISO 27001 greift die Anforderungen des § 30 BSIG strukturell in allen zehn Bereichen auf, deckungsgleich ist die Norm aber in keinem. Die typischen Lücken liegen an drei Stellen: bei den NIS2-Meldepflichten 24 Stunden / 72 Stunden / ein Monat (§ 32 BSIG), bei der Lieferketten-Sorgfalt (§ 30 Abs. 2 Nr. 4 BSIG) und bei den Geschäftsleitungspflichten (§ 38 BSIG); hinzu kommen sektorale Spezifika. Wer zertifiziert ist, baut also kein neues ISMS auf, sondern ergänzt gezielt — wer nicht zertifiziert ist, baut die Struktur nach den zehn Bereichen des § 30 Abs. 2 BSIG auf und entscheidet über die Zertifizierung später. Praxis-Empfehlung: ISO 27001-konformes ISMS aufbauen, Zertifizierung optional.

Wen die ISMS-Pflicht trifft

§ 28 BSIG knüpft im Regelfall an zwei Dinge zugleich an: an die Einrichtungsart nach Anlage 1 oder Anlage 2 und an die Größe — daneben erfasst die Norm bestimmte Einrichtungsarten größenunabhängig (erste und vierte Zeile der Tabelle). Zwei Punkte werden dabei regelmäßig übersehen. Erstens genügt der Umsatz allein nicht: Die Umsatzschwelle wirkt nur zusammen mit der Bilanzsumme, eigenständiges Kriterium ist allein die Mitarbeiterzahl. Zweitens gibt es bei den wichtigen Einrichtungen keine Mitarbeiter-Obergrenze — ein Großunternehmen, das nur einer Einrichtungsart der Anlage 2 zuzuordnen ist, bleibt wichtige Einrichtung und fällt sehr wohl in den Anwendungsbereich. Für die Berechnung von Mitarbeiterzahl, Jahresumsatz und Bilanzsumme gilt die Empfehlung 2003/361/EG mit Ausnahme von Art. 3 Abs. 4 ihres Anhangs (§ 28 Abs. 4 BSIG).

Rechtslage Österreich: Das NISG 2026 wurde am 23.12.2025 kundgemacht (BGBl. I Nr. 94/2025) und wird nach § 51 Abs. 1 und 2 NISG 2026 am 01.10.2026 anwendbar — zum Stand dieses Artikels also noch nicht. Die NIS-2-Richtlinie ist in Österreich nicht über das BSIG, sondern über das NISG 2026 umgesetzt. Die hier genannten §§ des BSIG haben folgende AT-Entsprechungen: Risikomanagementmaßnahmen (10 Inhalte lit. a–j) § 32 NISG statt § 30 BSIG, Verantwortung der Leitungsorgane § 31 NISG statt § 38 BSIG, Geldstrafen § 45 NISG statt § 65 BSIG (Beträge und Staffel in der FAQ zum Bußgeldrisiko), Nachweis der Wirksamkeit § 33 NISG (Selbstdeklaration) statt § 39 BSIG. Zuständige Aufsicht ist die Cybersicherheitsbehörde (nicht das BSI) — das Bundesamt für Cybersicherheit, dem Bundesminister für Inneres unmittelbar nachgeordnet, Sitz Wien (§ 3a Abs. 1 und 2, § 3b Abs. 3 NISG 2026).

2. ISMS-Scope definieren

Der Scope legt fest, welche Prozesse, Standorte, Systeme und Gesellschaften das ISMS abdeckt — und ist damit die Bezugsgröße für die Verhältnismäßigkeit nach § 30 Abs. 1 BSIG; die Einhaltung der Maßnahmenpflicht ist nach derselben Vorschrift zu dokumentieren. In der Praxis gehört deshalb auch das, was außen bleibt, mit Begründung in die Scope-Beschreibung. Der Scope ist nicht dasselbe wie die Betroffenheit: Ob Sie unter NIS2 fallen, entscheidet § 28 BSIG über Einrichtungsart, Größe und die größenunabhängig erfassten Sonderfälle (Abschnitt 1); der Scope entscheidet, wie weit Ihre Schutzmaßnahmen reichen.

Scope-Festlegung:

• Welche Prozesse: alle / nur kritische / spezifische — mindestens die Dienste, mit denen Sie unter eine Einrichtungsart der Anlage 1 oder Anlage 2 fallen, gehören hinein. Wird der Scope enger gezogen als die regulierte Tätigkeit, entsteht die Nachweislücke genau bei dieser Tätigkeit.
• Welche Standorte — inklusive Rechenzentren, Fertigungsstandorte und Home-Office-Arbeitsplätze. Der Standort bestimmt mit, welche physischen Maßnahmen (Policy 12) und welche Notfallszenarien (§ 30 Abs. 2 Nr. 3 BSIG) zu regeln sind.
• Welche IT-Systeme — § 30 Abs. 1 BSIG zielt auf Verfügbarkeit, Integrität und Vertraulichkeit der IT-Systeme; die Systemliste ist deshalb keine Fleißarbeit, sondern die Bezugsgröße für Risikoanalyse, Berechtigungskonzept und Backup-Strategie. Auch von Fachbereichen selbst beschaffte SaaS-Dienste gehören dazu.
• Welche Tochtergesellschaften — ist eine Tochter selbst besonders wichtige oder wichtige Einrichtung, trifft sie die Pflicht eigenständig. Die Konzernmutter kann eine zentrale ISMS-Leitlinie und zentrale Maßnahmen vorgeben; die Tochter setzt sie operativ um. Verträge und Delegationsketten gehören dokumentiert. Registriert wird getrennt: in Deutschland über die gemeinsame Registrierungsmöglichkeit von BSI und BBK (§ 33 Abs. 1 BSIG), in Österreich ab 01.10.2026 bei der Cybersicherheitsbehörde (§ 29 Abs. 2 NISG 2026).

Empfehlung KMU mit NIS2-Pflicht: gesamtes Unternehmen in Scope. Zwei Gründe sprechen dafür: Erstens ersparen Sie sich die laufende Abgrenzungsdiskussion bei jedem neuen System; zweitens verlangt die Registrierung ohnehin die Angabe des relevanten Sektors nach Anlage 1 oder 2 (§ 33 Abs. 1 BSIG) — Registrierungsangaben und Scope-Beschreibung sollten dieselbe Realität beschreiben.

3. Risikoanalyse + Behandlungsplan

Die Risikoanalyse steht im Maßnahmenkatalog an erster Stelle: § 30 Abs. 2 Nr. 1 BSIG verlangt Konzepte für die Risikoanalyse und für die Sicherheit in der Informationstechnik; in Österreich steht der gleichlaufende Inhalt in § 32 Abs. 4 lit. a NISG 2026 (anwendbar ab 01.10.2026). Sie liefert zugleich die Begründung dafür, dass nicht jeder der zehn Maßnahmenbereiche gleich tief umgesetzt sein muss — verlangt sind nach § 30 Abs. 1 BSIG geeignete, verhältnismäßige und wirksame Maßnahmen, und die Risikoanalyse zeigt, wo die Schwerpunkte liegen. Ein Online-Shop wird typischerweise bei Authentifizierung und Zugriffskontrolle priorisieren, ein Maschinenbauer bei der Lieferkette.

1. Asset Inventory: alle IT-Assets, Datenklassen, Geschäftsprozesse. Ohne vollständiges Inventar lässt sich Verhältnismäßigkeit nicht belegen — das Asset-Inventar steht deshalb am Anfang und ist kein Beiwerk.
2. Bedrohungsanalyse: typische Bedrohungen pro Asset (Ransomware, Datenleck, Ausfall). Als Methodik-Rahmen ist ISO 27005 in der Praxis verbreitet; entscheidend ist, dass die Methodik dokumentiert und wiederholbar ist.
3. Verwundbarkeits-Bewertung: aktueller Schutzstand. Hier zeigt sich die Verbindung zu Bereich 5 (Sicherheit beim Erwerb, Entwickeln und Warten): offene Schwachstellen ohne Patch-Pfad sind ein Risiko, kein Restposten.
4. Risiko-Score: Eintrittswahrscheinlichkeit × Schadenshöhe. Legen Sie die Skala und die Akzeptanzschwelle vorab fest und lassen Sie beides von der Geschäftsleitung freigeben — die Umsetzung der Maßnahmen ist nach § 38 Abs. 1 BSIG deren Aufgabe.
5. Behandlungs-Optionen: reduzieren / akzeptieren / übertragen / vermeiden. Jede Entscheidung braucht einen Verantwortlichen und ein Datum; akzeptierte Risiken brauchen zusätzlich die dokumentierte Begründung.
6. Statement of Applicability (SoA): welche Controls anwendbar. Das SoA stammt aus der ISO-Welt, zahlt aber zugleich auf die nach § 30 Abs. 1 BSIG geforderte Dokumentation ein: Es zeigt, welche Maßnahme aus welchem Risiko folgt — und welche warum nicht.

Praxisempfehlung zum Turnus: Die Risikoanalyse ist kein Einmalprodukt. Ein jährlicher Durchlauf plus anlassbezogene Aktualisierung bei neuen Systemen, neuen Lieferanten oder nach einem Vorfall hat sich bewährt — dieser Turnus ist eine Praxisempfehlung, keine Gesetzesfrist.

4. Policies und Konzepte für alle zehn Bereiche

Die folgenden Policies sind das Regelwerk, mit dem das ISMS die zehn Maßnahmenbereiche des § 30 Abs. 2 BSIG in überprüfbare Vorgaben übersetzt. Die folgende Zuordnung ist ein Praxis-Raster: Das Gesetz benennt Maßnahmenbereiche, keine Policy-Namen — welches Dokument welchen Bereich abdeckt, entscheiden Sie. Für Österreich steht der inhaltlich gleichlaufende Katalog in derselben Reihenfolge in § 32 Abs. 4 lit. a bis j NISG 2026 (anwendbar ab 01.10.2026). Welcher Inhalt hinter welcher Nummer steht, listet die FAQ „Muss das ISMS alle zehn Maßnahmenbereiche des § 30 BSIG abdecken?“.

1. Information Security Policy (Top-Level) — Geltungsbereich, Sicherheitsziele, Rollen und Freigabe durch die Geschäftsleitung; das Dokument, auf das alle weiteren Policies verweisen. § 30 Abs. 2 Nr. 1 BSIG
2. Acceptable Use Policy — was Beschäftigte mit Geräten, Konten und Daten tun dürfen und was nicht; die Regel, auf die sich Schulung und Sanktion später berufen. § 30 Abs. 2 Nr. 7 BSIG
3. Access Control Policy — Berechtigungskonzept nach Need-to-Know, Rollenmodell, regelmäßige Rezertifizierung der Rechte, Onboarding- und Offboarding-Workflow. § 30 Abs. 2 Nr. 9 BSIG
4. Cryptographic Controls Policy — Vorgaben für Daten in Transit (TLS 1.3 nach BSI TR-02102), Daten at Rest (AES-256 für Datenträger und Backups), E-Mail-Sicherheit und Schlüsselverwaltung. § 30 Abs. 2 Nr. 8 BSIG
5. Backup + Recovery Policy — Backup-Strategie nach dem 3-2-1-Prinzip oder gleichwertig, RTO und RPO je Geschäftsprozess, getestete Wiederherstellungsroutine. § 30 Abs. 2 Nr. 3 BSIG
6. Patch Management Policy — Fristen je Kritikalität, Ausnahmeverfahren und Anschluss an das Schwachstellenmanagement (CVD-Prozess). § 30 Abs. 2 Nr. 5 BSIG
7. Incident Management Policy — Erkennung, Klassifizierung, Eskalation und die Meldevorlagen für 24 Stunden / 72 Stunden / ein Monat nach § 32 Abs. 1 BSIG. § 30 Abs. 2 Nr. 2 BSIG
8. Supplier Management Policy — Lieferanten-Bewertung mit Risikoklassifizierung, Cybersecurity-Klauseln in Standardverträgen, Right-to-Audit für kritische Lieferanten, Vorfall-Meldepflicht des Lieferanten an Sie. § 30 Abs. 2 Nr. 4 BSIG
9. Mobile Device + BYOD Policy — Verwaltung, Verschlüsselung und Trennung privater und dienstlicher Nutzung auf mobilen Endgeräten. § 30 Abs. 2 Nr. 9 BSIG
10. Clear Desk + Clear Screen Policy — Umgang mit Papier, Bildschirmsperre und Besprechungsräumen; die Regel lässt sich ohne Werkzeuge stichprobenartig prüfen und eignet sich deshalb gut als Einstieg in die Wirksamkeitsmessung. § 30 Abs. 2 Nr. 7 BSIG
11. Password Policy — Anforderungen an Authentifizierung, flankiert von MFA — § 30 Abs. 2 Nr. 10 BSIG verlangt Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung; MFA für alle Administrations- und externen Zugänge ist eine verbreitete Praxisempfehlung. § 30 Abs. 2 Nr. 10 BSIG
12. Physical Security Policy — Zutritt, Besucherregelung, Schutz von Serverräumen und Archiven; die physische Seite von Personalsicherheit und Zugriffskontrolle. § 30 Abs. 2 Nr. 9 BSIG

Für Bereich 6 — Bewertung der Wirksamkeit der Risikomanagementmaßnahmen — sieht diese Liste bewusst keine eigene Policy vor: Er wird nicht durch ein Verhaltensregelwerk abgedeckt, sondern durch die dokumentierten Konzepte und Verfahren der Audit- und Review-Ebene aus Abschnitt 5 — Konzepte und Verfahren verlangt § 30 Abs. 2 Nr. 6 BSIG gleichwohl; die Dokumentation der Einhaltung folgt aus § 30 Abs. 1 BSIG. Jede Policy braucht außerdem drei Angaben, damit sie im Audit trägt: eine benannte verantwortliche Rolle, ein Freigabedatum durch die Geschäftsleitung und eine Versionsnummer.

5. Internes Audit + Management-Review

Internes Audit und Management-Review sind ISO-27001-Praxis im Jahresrhythmus, keine NIS2-Pflicht: § 30 Abs. 2 Nr. 6 BSIG verlangt „Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen“, aber keine Frequenz — gesetzlich getaktet ist allein der Nachweisrhythmus der Betreiber kritischer Anlagen nach § 39 Abs. 1 BSIG (alle drei Jahre); die übrigen Gesetzesfristen stehen in der Übersicht in Abschnitt 6.

• Internes Audit jährlich: kompletter ISMS-Scope, durch unabhängigen internen oder externen Auditor; ISO/IEC 27001:2022 verlangt interne Audits „in geplanten Abständen“.
• Management-Review jährlich (ebenfalls ISO-Praxis): Geschäftsführung sichtet Audit-Bericht, Vorfälle, Risikoänderungen
• Kontinuierliche Verbesserung: CAPA-Prozess (Corrective + Preventive Actions) — jede Audit-Feststellung, jeder Vorfall und jede Kennzahl unterhalb der festgelegten Schwelle erzeugt einen Eintrag mit Ursache, Maßnahme, verantwortlicher Rolle und Termin; der Status wird im Management-Review nachgehalten. Der Nachweis, dass Feststellungen abgearbeitet wurden, ist der praktische Beleg für die Wirksamkeitsbewertung nach § 30 Abs. 2 Nr. 6 BSIG.

Was das Gesetz tatsächlich verlangt: Ein gesetzlich getakteter Nachweisrhythmus besteht allein für Betreiber kritischer Anlagen; er wird durch Sicherheitsaudits, Prüfungen oder Zertifizierungen zu einem vom BSI festgelegten Zeitpunkt erbracht (§ 39 Abs. 1 BSIG) — Frist und Auslöser in der Fristen-Tabelle in Abschnitt 6. Für alle übrigen besonders wichtigen und wichtigen Einrichtungen gibt es keine gesetzlich vorgeschriebene Audit-Frequenz.

Wie Wirksamkeit messbar wird: Ein Audit-Bericht allein beantwortet die Frage nach der Wirksamkeit nicht. In der Praxis bewährt haben sich Kennzahlen je Maßnahmenbereich — etwa Patch-Compliance-Rate, Phishing-Klickrate und tatsächlich gemessene Wiederherstellungszeit —, ein quartalsweises Reporting an die Geschäftsleitung, ein jährlicher Penetrationstest sowie ein externes Audit im Zwei-Jahres-Takt. Alle vier Rhythmen sind Praxisempfehlungen, keine Fristen aus § 30 BSIG. Sie zahlen aber unmittelbar auf drei Lücken ein, die in der Auditpraxis erfahrungsgemäß häufig beanstandet werden (Praxiseinschätzung): Sicherheit der Lieferkette (§ 30 Abs. 2 Nr. 4 BSIG), fehlende dokumentierte Kennzahlen zur Wirksamkeitsbewertung (Nr. 6) und fehlende Phishing-Simulation im Bereich Schulungen und Sensibilisierung (Nr. 7).

Wer das Review verantwortet: Das Management-Review ist kein Delegationsobjekt. § 38 Abs. 1 BSIG verpflichtet die Geschäftsleitung, die Risikomanagementmaßnahmen nach § 30 BSIG umzusetzen und ihre Umsetzung zu überwachen; § 38 Abs. 3 BSIG verlangt zusätzlich ihre regelmäßige Schulungsteilnahme. Praktisch heißt das: Review-Protokoll mit Datum, Teilnehmern, Beschlüssen und Terminen, freigegeben von der Geschäftsleitung.

Rechtslage Österreich: Auch das NISG 2026 kennt keine jährliche Auditpflicht. An die Stelle eines Audit-Nachweises tritt die Selbstdeklaration an die Cybersicherheitsbehörde (§ 33 Abs. 1 NISG); ein Nachweis durch eine unabhängige Stelle ist nur auf Aufforderung zu erbringen (§ 33 Abs. 2 NISG) — Fristen und Anwendungsbeginn in der Fristen-Tabelle in Abschnitt 6. Die Verantwortung der Leitungsorgane regelt § 31 Abs. 1 und 2 NISG 2026: sicherstellen und beaufsichtigen, dazu die Teilnahme an spezifisch gestalteten Cybersicherheitsschulungen und das regelmäßige Schulungsangebot an die Mitarbeiter.

6. 10-Wochen-Roadmap

Die Roadmap verteilt den ISMS-Aufbau auf zehn Wochen, an deren Ende jeweils ein prüffähiges Artefakt steht — der Takt selbst ist eine Praxisempfehlung, keine Gesetzesfrist: Das Gesetz gibt Inhalte vor — die zehn Maßnahmenbereiche des § 30 Abs. 2 BSIG — sowie die Fristen aus der Übersicht im Anschluss; die Verteilung der Aufbauarbeit auf zehn Wochen ist eine Planungsempfehlung. Der Plan ist so geschnitten, dass diese Artefakte im Audit vorgezeigt werden können; die Einhaltung der Maßnahmen ist nach § 30 Abs. 1 BSIG ohnehin zu dokumentieren.

Woche 8 reicht über den Projektzeitraum hinaus: In der Praxis wird die Awareness-Schulung jährlich wiederholt, neue Mitarbeitende erhalten den Onboarding-Baustein üblicherweise in den ersten vier Wochen, und eine quartalsweise Phishing-Simulation mit Auswertung der Klickrate liefert die Kennzahl für Bereich 6. Auch das sind Praxis-Rhythmen — § 30 Abs. 2 Nr. 7 BSIG verlangt grundlegende Schulungen und Sensibilisierungsmaßnahmen, ohne eine Frequenz zu nennen.

Gesetzliche Fristen laufen parallel — unabhängig vom Projektplan

Die gesetzlichen Termine laufen unabhängig vom Projektplan und verschieben sich nicht, nur weil das ISMS-Projekt noch läuft; die letzten beiden Zeilen sind zum Vergleich aufgenommene Praxis-Rhythmen.

Was der Plan leistet — und was danach kommt

Nach zehn Wochen steht das Gerüst: freigegebener Scope, Asset-Inventar und Risiko-Register, Behandlungsplan mit SoA, das in Kraft gesetzte Policy-Set, Schulungsnachweise, Audit-Bericht und Review-Protokoll. Was danach fehlt, ist die technische und vertragliche Tiefe in den zehn Maßnahmenbereichen — MFA-Rollout, Kryptografie-Umstellung, Cybersecurity-Klauseln in Lieferantenverträgen, getestete Wiederherstellung. Planbar wird dieser zweite Abschnitt erst mit dem Risikobehandlungsplan aus Woche 4, weil erst dort feststeht, welche Maßnahme aus welchem Risiko folgt. Erfahrungswerte zur Dauer stehen in den FAQ.