NIS2 Anforderungen im Mittelstand umsetzen

Ein Sicherheitsvorfall in der Produktion, ein kompromittiertes Administratorkonto oder ein Ausfall eines zentralen Dienstleisters ist längst kein reines IT-Thema mehr. Wer NIS2 Anforderungen im Mittelstand umsetzen will, muss deshalb technische Schutzmaßnahmen, Betriebsprozesse und Managementverantwortung zusammenführen. Entscheidend ist nicht, möglichst viele Richtlinien zu erstellen. Entscheidend sind nachweisbar wirksame Abläufe, die auch unter Betriebsdruck funktionieren.

Für mittelständische Unternehmen entsteht dabei eine besondere Herausforderung: Kritische Geschäftsprozesse sind oft über ERP, Fertigungssteuerung, Logistik, Datenplattformen und externe Service-Provider verteilt. Gerade in SAP-nahen Landschaften reichen allgemeine Informationssicherheitsvorgaben nicht aus. Es muss nachvollziehbar sein, welche Systeme welche Geschäftsprozesse stützen, wer Entscheidungen trifft und wie auf Störungen reagiert wird.

Der erste Schritt: Betroffenheit und Geltungsbereich klären

Nicht jedes mittelständische Unternehmen unterliegt automatisch denselben NIS2-Pflichten. Maßgeblich sind unter anderem Branche, Größe, Rolle in der Lieferkette und die Einordnung nach dem jeweils geltenden nationalen Umsetzungsrahmen. Eine pauschale Einschätzung nach Mitarbeiterzahl oder Umsatz greift daher zu kurz.

In der Praxis sollte die Klärung der Betroffenheit mit einer strukturierten Bestandsaufnahme beginnen. Dazu gehören Gesellschaften, Standorte, Geschäftsbereiche, relevante Dienstleistungen und Abhängigkeiten von IT- und OT-Systemen. Ein Handelsunternehmen mit stark automatisierter Lagerlogistik hat andere kritische Prozesse als ein Chemieunternehmen mit vernetzten Produktionsanlagen. Beide können jedoch auf zentrale Identitätsdienste, SAP-Systeme, Cloud-Plattformen oder externe Rechenzentrumsleistungen angewiesen sein.

Die technische Analyse liefert die Grundlage. Die rechtliche Einordnung, etwa zur Einstufung und zu konkreten gesetzlichen Pflichten, muss davon getrennt erfolgen. Bei Bedarf kann hierfür die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingebunden werden. Diese Trennung schafft klare Verantwortlichkeiten und verhindert, dass technische Annahmen als rechtliche Bewertung behandelt werden.

NIS2 Anforderungen im Mittelstand: Vom Regelwerk zum Betriebsmodell

NIS2 verlangt kein isoliertes Compliance-Projekt. Die Anforderungen greifen in den laufenden Betrieb ein. Deshalb ist ein Betriebsmodell erforderlich, das Sicherheitsrisiken systematisch steuert und belastbare Nachweise erzeugt.

Am Anfang steht die Frage, welche Services tatsächlich geschäftskritisch sind. Nicht jedes System hat dieselbe Priorität. Ein Reporting-System kann mehrere Tage ausfallen, ohne die Leistungserbringung unmittelbar zu stoppen. Ein zentraler SAP-Produktivmandant, ein Schnittstellenserver für Lieferabrufe oder ein Active-Directory-Dienst kann hingegen kurzfristig zu erheblichen Betriebsunterbrechungen führen.

Aus dieser Priorisierung ergeben sich realistische Schutzziele für Verfügbarkeit, Integrität, Vertraulichkeit und Wiederherstellbarkeit. Sie bilden die Grundlage für technische Maßnahmen, Notfallverfahren und Eskalationswege. Entscheidend ist die Verknüpfung: Ein Risiko-Register ohne Bezug zu Systemen und Verantwortlichen bleibt ebenso wirkungslos wie technische Härtung ohne dokumentierte Wiederanlaufziele.

Verantwortlichkeiten müssen bis zur Geschäftsleitung reichen

NIS2 rückt die Verantwortung der Leitungsorgane deutlich in den Vordergrund. Im Mittelstand darf diese Verantwortung nicht in einer allgemeinen IT-Leiter-Rolle verschwinden. Die Geschäftsleitung benötigt einen regelmäßigen, verständlichen Überblick über wesentliche Risiken, offene Maßnahmen, Sicherheitsvorfälle und Abhängigkeiten.

Dafür braucht es keine überdimensionierte Gremienstruktur. Ein klarer Steuerungskreis mit festen Berichtsrhythmen ist häufig wirksamer. Die Rollen sollten eindeutig festlegen, wer Risiken bewertet, Maßnahmen priorisiert, Ausnahmen genehmigt und bei Sicherheitsereignissen entscheidet. Besonders an Schnittstellen zwischen IT, Produktion, Einkauf, Compliance und Fachbereichen entstehen sonst Lücken.

Bei laufenden Transformationsprojekten kommt eine weitere Ebene hinzu. Wird beispielsweise ein S/4HANA-System migriert, verändern sich Berechtigungen, Schnittstellen, Betriebsverantwortung und Wiederanlaufverfahren. Sicherheitsanforderungen müssen daher in Testplanung, Cutover und Hypercare einfließen. Ein Go-Live ohne geprüfte Notfallprozesse oder ohne abgestimmte Berechtigungskonzepte schafft neue Risiken, selbst wenn das Projekt fachlich erfolgreich abgeschlossen wird.

Die Maßnahmen priorisieren, statt Kontrollkataloge anzuhäufen

Ein vollständiger Maßnahmenkatalog kann umfangreich sein. Für die operative Umsetzung empfiehlt sich dennoch eine Priorisierung nach tatsächlichem Risiko und Umsetzbarkeit. Dabei haben einige Handlungsfelder meist unmittelbare Wirkung:

• Identitäten und privilegierte Zugriffe müssen zentral nachvollziehbar, regelmäßig überprüft und gegen Missbrauch abgesichert sein.

• Kritische Systeme benötigen aktuelle Schutzstände, segmentierte Zugänge, gesicherte Konfigurationen und eine dokumentierte Behandlung erkannter Schwachstellen.

• Backups müssen nicht nur vorhanden sein, sondern sich unter realistischen Bedingungen wiederherstellen lassen.

• Sicherheitsereignisse brauchen definierte Melde-, Entscheidungs- und Kommunikationswege, die regelmäßig getestet werden.

• Dienstleister und Cloud-Anbieter müssen anhand ihrer konkreten Leistung, Zugriffsrechte und Wiederanlaufabhängigkeiten gesteuert werden.

Die Reihenfolge hängt vom Unternehmen ab. Bestehen weitreichende Administratorrechte ohne nachvollziehbare Freigabe, sollte Identity und Access Management Vorrang haben. Gibt es keine belastbar getestete Wiederherstellung für produktionskritische Daten, ist ein Backup-Projekt keine Infrastrukturmaßnahme neben vielen anderen, sondern eine betriebliche Priorität.

Ein häufiger Fehler ist die ausschließliche Orientierung an Zertifikaten oder Fragebögen. Diese können eine strukturierte Grundlage sein, ersetzen aber keine Wirksamkeitsprüfung. Wer etwa einen Incident-Response-Prozess dokumentiert hat, sollte prüfen, ob Rufbereitschaften, Entscheidungsbefugnisse, Log-Zugänge und Kommunikationsvorlagen im Ernstfall tatsächlich verfügbar sind.

Lieferketten und Schnittstellen konkret bewerten

Mittelständische Organisationen arbeiten selten isoliert. Managed-Service-Provider, Hosting-Partner, SaaS-Anbieter, Maschinenhersteller, Logistikdienstleister und Beratungspartner können Zugriff auf kritische Systeme oder Daten erhalten. Daraus entsteht ein Risiko, das nicht allein über Vertragsklauseln steuerbar ist.

Sinnvoll ist eine abgestufte Betrachtung der Lieferanten. Ein Anbieter für allgemeine Bürosoftware stellt andere Anforderungen als ein Dienstleister mit Fernwartungszugriff auf Produktionsanlagen oder ein Partner, der SAP-Basisbetrieb und Berechtigungsverwaltung übernimmt. Für kritische Leistungen sollten Verantwortlichkeiten, Sicherheitsanforderungen, Meldewege, Eskalationen, Nachweise und Ausstiegsoptionen konkret vereinbart und im Betrieb überprüft werden.

Auch Datenflüsse verdienen besondere Aufmerksamkeit. Viele Risiken entstehen nicht im Kernsystem, sondern in Schnittstellen: beim Datentransfer zwischen S/4HANA und Lagerverwaltung, bei Integrationen mit Lieferantenportalen oder bei der Übernahme von Stammdaten aus externen Quellen. Eine Datenflussanalyse macht sichtbar, wo schutzbedürftige Informationen liegen, welche Konten kommunizieren und welche Abhängigkeiten einen Wiederanlauf erschweren.

Nachweise so aufbauen, dass sie auditierbar bleiben

NIS2-Umsetzung wird nur dann steuerbar, wenn Entscheidungen und Maßnahmen nachvollziehbar dokumentiert sind. Revisionssicheres Reporting bedeutet dabei nicht, jede technische Aktivität manuell zu protokollieren. Es bedeutet, für wesentliche Kontrollen klare Evidenzen zu definieren: etwa Freigaben für privilegierte Zugriffe, Ergebnisse von Wiederherstellungstests, Patch-Status kritischer Systeme, Schulungsnachweise oder Protokolle von Notfallübungen.

Diese Nachweise sollten möglichst aus vorhandenen Betriebsprozessen entstehen. Ein separates Excel-Register, das niemand im Tagesgeschäft pflegt, wird schnell unvollständig. Besser ist die Anbindung an Change-Management, Ticketing, Berechtigungsprozesse, Sicherheitsmonitoring und Projektsteuerung. So verbindet sich Compliance mit operativer Steuerbarkeit.

Für die Geschäftsleitung eignet sich ein kompaktes Reporting mit wenigen belastbaren Kennzahlen: Status kritischer Maßnahmen, Anzahl und Schwere relevanter Vorfälle, Testergebnisse, offene Lieferantenrisiken und überfällige Entscheidungen. Der Bericht soll nicht technische Details ersetzen, sondern wirksame Steuerung ermöglichen.

Ein realistischer Umsetzungsplan beginnt mit Transparenz

Der richtige Start ist selten ein Großprojekt. Ein zeitlich klar begrenzter Quick Check kann zunächst Betroffenheit, kritische Systeme, Verantwortlichkeiten, Nachweislücken und vorrangige Risiken erfassen. Daraus entsteht eine umsetzbare Roadmap mit konkreten Arbeitspaketen, Eigentümern und Entscheidungspunkten.

Je nach Ausgangslage kann anschließend ein Workshop zur Zielarchitektur, zur Sicherheitsorganisation oder zu Notfall- und Meldeprozessen folgen. In komplexen SAP- und Transformationsvorhaben gehört NIS2 in die bestehende Projektgovernance: in Rollenmodelle, Testfälle, Freigaben, Cutover-Planung und Betriebsübergabe. Das reduziert Doppelarbeit und schützt den stabilen Betrieb während der Veränderung.

Nächster sinnvoller Schritt

Quteco unterstützt Unternehmen mit Quick Checks, Datenflussanalysen und operativer Projektbegleitung dabei, NIS2-relevante Anforderungen in IT-, SAP- und Transformationsprozesse zu überführen. Für die rechtliche Einordnung konkreter Pflichten kann ergänzend die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingebunden werden. Ein belastbarer Startpunkt ist eine gemeinsame Sicht auf kritische Services, Verantwortlichkeiten und die Nachweise, die im Betrieb tatsächlich geführt werden können.