NIS2 · BSIG · Technische Umsetzung
NIS2-Beratung: Technische Sicherheitsmaßnahmen wirksam umsetzen
Wir machen aus den zehn Bereichen des § 30 Abs. 2 BSIG konkrete Konfiguration in Cloud, Kubernetes und Rechenzentrum und liefern die Nachweise, die Geschäftsleitung und Prüfer sehen wollen. Keine Rechtsberatung, keine Zertifizierung.
- Technische Gap-Analyse je Bereich
- Controls, Runbooks, Nachweis-Artefakte
- Umsetzung und optional Betrieb
01Aufgabe
Von der Vorschrift zur Konfiguration
SKAFFON unterstützt Unternehmen, die unter das NIS2-Umsetzungsgesetz fallen, bei der technischen Umsetzung der Risikomanagementmaßnahmen nach § 30 BSIG: von der technischen Gap-Analyse über Plattform-Controls für Zugriff, Backup, Lieferkette und Incident-Fähigkeit bis zu den Betriebsnachweisen, die Sie Ihrer Geschäftsleitung und Prüfern vorlegen können.
Die Seite richtet sich an IT-Leitung, CISO und CTO, die aus Paragrafen konkrete Konfiguration machen müssen.
02Maßnahmen
Zehn Bereiche des § 30 Abs. 2 BSIG: Controls, Nachweise und was bei Ihnen bleibt
Die Zuordnung zeigt, welche konkreten Controls wir je Bereich technisch umsetzen oder prüfen, welches Artefakt dabei als Nachweis entsteht und was ausdrücklich bei Ihnen bleibt. Sie ist unsere fachliche Übersetzung des Gesetzestextes in technische Arbeitspakete und keine amtliche Auslegung. Verbindlich ist allein der Gesetzestext.
| Bereich nach § 30 Abs. 2 BSIG | Konkrete technische Controls | Nachweis-Artefakt | Bleibt bei Ihnen |
|---|---|---|---|
| 1. Konzepte zu Risikoanalyse und IT-Sicherheit | Technische Systeminventur aus IaC-Zustand und Konfigurationsexporten; Schwachstellen- und Fehlkonfigurationsprüfung; Sicherheits-Baseline für Plattformen | Systeminventar, Gap-Bericht mit Einstufung | Risikomethodik, Risikoakzeptanz, Sicherheitsleitlinie |
| 2. Bewältigung von Sicherheitsvorfällen | Zentrale Log-Erfassung, Anbindung an Ihr SIEM, Alarmierungswege; unveränderliche Audit-Logs; technische Eindämmung als Runbook (Zugangsdaten sperren, Workload isolieren, Snapshot sichern) | Log-Architekturdiagramm, Runbooks, Alarm-Testprotokoll | Einstufung von Vorfällen, Meldungen nach § 32 BSIG, Krisenstab |
| 3. Aufrechterhaltung des Betriebs, Backup, Wiederherstellung | Backup-Architektur mit Offsite- und unveränderlicher Kopie, getrennte Zugangsdaten, dokumentierte Wiederanlaufreihenfolge, regelmäßiger Restore-Test | Backup-Konzept, Restore-Testprotokoll, Wiederanlauf-Runbook | Festlegung der Wiederanlaufziele (RPO/RTO) aus Geschäftssicht, Notfall- und Krisenmanagement |
| 4. Sicherheit der Lieferkette | Technisches Inventar externer Dienste und deren Zugriffsrechte; Beschränkung und Protokollierung von Dienstleisterzugängen; Software-Lieferkette mit SBOM, signierten Artefakten und Registry-Richtlinien (siehe DevSecOps und Lieferketten) | Lieferantenzugriffs-Matrix, SBOM-Pipeline | Vertragliche und organisatorische Lieferantenbewertung |
| 5. Sicherheit bei Erwerb, Entwicklung, Wartung, Schwachstellenmanagement | Image- und Abhängigkeits-Scanning in der Pipeline, IaC-Prüfung, Patch- und Update-Prozess, Härtungs-Baselines, Richtlinien als Code (z. B. Kyverno für Kubernetes) | Pipeline-Konfiguration, Scan-Berichte, Patch-Runbook | Beschaffungsvorgaben, Prozess der Schwachstellenoffenlegung |
| 6. Verfahren zur Wirksamkeitsbewertung | Laufende Konformitätsprüfung der Konfiguration (Policy-Audit, Cloud-Posture-Prüfung), Drift-Erkennung, wiederholbare Restore- und Alarmtests | Prüfberichte mit Datum, Testkalender | Interne Revision, unabhängige Audits und Penetrationstests (nicht Teil dieser Leistung) |
| 7. Schulung und Sensibilisierung | Technische Einweisung Ihrer Administratoren anhand der Runbooks | Übergabedokumentation | Inhalte und Durchführung von Schulungen für Beschäftigte und Geschäftsleitung (§ 38 Abs. 3 BSIG) |
| 8. Kryptographie | Schlüsselverwaltung (KMS, Secrets-Management z. B. mit OpenBao), Verschlüsselung ruhender Daten, TLS-Konfiguration, Zertifikats- und Schlüsselrotation | Kryptographie-Parameterliste je System, Rotationsnachweis | Kryptokonzept und Freigabe von Verfahren |
| 9. Personal, Zugriffskontrolle, Verwaltung von IKT-Systemen | Rollenmodell nach Least Privilege, zentrale Identitäten, privilegierter Zugriff mit Protokollierung, Break-Glass-Konten, Trennung von Umgebungen | Rollen- und Rechtematrix, Berechtigungsreview | Personalsicherheit, Ein-/Austrittsprozess, Rollenfreigabe |
| 10. MFA, gesicherte Kommunikation, Notfallkommunikation | Mehrfaktor-Authentifizierung für Administratorzugänge und Fernzugriff, möglichst phishing-resistent; Zugangspfade, die bei Ausfall der Primärumgebung weiter funktionieren | MFA-Abdeckungsbericht, Zugangspfad-Dokumentation | Auswahl der Kommunikationsmittel, Notfallkommunikationskonzept |
Auf Wunsch ordnen wir die Maßnahmen den Bausteinen des BSI IT-Grundschutzes zu, wenn Ihr ISMS bereits darauf aufbaut; ob und wie weit der Grundschutz die Anforderungen aus § 30 BSIG im Einzelfall abdeckt, beurteilen wir nicht. Die Checkliste gibt es als PDF: SKAFFON NIS2-Checkliste (PDF), eine technische Arbeitshilfe und keine Rechtsberatung.
03Zuständigkeit
Wo bei den zehn Bereichen der Schwerpunkt liegt: Geschäftsleitung, gemeinsam oder technisch
Die Anforderungen aus NIS2 und BSIG haben technische, organisatorische und rechtliche Anteile. Wir übernehmen den technischen Anteil und sagen klar, wo er endet.
04Rollen
Fünf Beteiligte, fünf getrennte Verantwortungen
-
Ihre Geschäftsleitung
Trägt die Umsetzungs- und Überwachungspflicht (§ 38 BSIG), entscheidet über Risikoakzeptanz und nimmt an Schulungen teil.
-
Ihre Rechtsberatung
Klärt, ob und als welche Einrichtung Sie betroffen sind, und begleitet Registrierung und Meldungen.
-
Ihr Datenschutzbeauftragter
Bewertet Fragen, bei denen Sicherheitsmaßnahmen personenbezogene Daten berühren, zum Beispiel Log-Inhalte.
-
Prüfer und Zertifizierungsstellen
Bewerten unabhängig. Wir erstellen Nachweise, wir stellen kein Zertifikat aus und führen keine ISO-27001-Zertifizierung durch.
-
SKAFFON
Analysiert, plant und setzt die technischen Maßnahmen um, dokumentiert sie und überträgt sie in den Betrieb.
Grenze
Wir liefern Nachweise, kein Konformitätsurteil
Wir dokumentieren den technischen Stand und die umgesetzten Maßnahmen. Ob Ihr Unternehmen NIS2-konform ist, bewerten Sie, Ihre Prüfer und die Aufsicht.
Projekt anfragen05Rechtsstand
Was seit dem 6. Dezember 2025 verbindlich gilt
Das Gesetz zur Umsetzung der NIS-2-Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung (NIS2UmsuCG) wurde am 5. Dezember 2025 im Bundesgesetzblatt verkündet (BGBl. 2025 I Nr. 301). Nach Artikel 30 des Gesetzes trat es am Tag nach der Verkündung in Kraft, also am 6. Dezember 2025. Sein Kern ist das neu gefasste BSI-Gesetz (BSIG), das die europäische NIS-2-Richtlinie (EU) 2022/2555 in deutsches Recht überführt. Quelle für alle Paragrafenangaben ist der Gesetzestext im Bundesgesetzblatt, Stand der Prüfung: 13. November 2026.
Für die technische Arbeit sind vier Vorschriften maßgeblich:
- § 28 BSIG bestimmt, welche Einrichtungen „besonders wichtig“ oder „wichtig“ sind. Ob Ihr Unternehmen dazugehört, ist eine rechtliche Frage, die Sie mit Ihrer Rechtsberatung klären.
- § 30 Abs. 1 BSIG verpflichtet diese Einrichtungen, geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen zu ergreifen und die Einhaltung zu dokumentieren. Bei der Verhältnismäßigkeit zählen Risikoexposition, Größe der Einrichtung, Umsetzungskosten sowie Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen und deren gesellschaftliche und wirtschaftliche Auswirkungen.
- § 30 Abs. 2 BSIG konkretisiert das in zehn Mindestbereichen. Die Maßnahmen sollen den Stand der Technik einhalten, einschlägige Normen berücksichtigen und auf einem gefahrenübergreifenden Ansatz beruhen.
- § 38 BSIG verpflichtet die Geschäftsleitung, die Maßnahmen nach § 30 umzusetzen und ihre Umsetzung zu überwachen. Sie haftet bei Pflichtverletzung nach den Regeln des Gesellschaftsrechts und muss regelmäßig an Schulungen teilnehmen.
Die Meldepflichten bei Sicherheitsvorfällen regelt § 32 BSIG, die Registrierung § 33 BSIG. Beides sind Pflichten Ihres Unternehmens, die wir technisch unterstützen (Log-Bereitstellung, Alarmierungswege), aber nicht für Sie erfüllen.
06Ausnahmen
Wann §§ 30 und 38 BSIG nicht gelten: die Ausnahmen in § 28 Abs. 5 und 6
Nach § 28 Abs. 6 BSIG gelten die §§ 30, 31, 32, 35, 36, 38 und 39 BSIG nicht für Finanzunternehmen nach Artikel 2 Absatz 2 der Verordnung (EU) 2022/2554 (DORA) und für Unternehmen, für die DORA aufgrund von § 1a Abs. 2 und 2a KWG oder § 293 Abs. 5 VAG gilt; ebenso nicht für die in Nummer 2 genannten Telematikinfrastruktur-Stellen.
Nach § 28 Abs. 5 BSIG gelten die §§ 30, 31, 32, 35, 36, 38, 39, 61 und 62 BSIG nicht für besonders wichtige und wichtige Einrichtungen, die ein öffentliches Telekommunikationsnetz betreiben oder öffentlich zugängliche Telekommunikationsdienste erbringen, oder Energieversorgungsnetze, Energieanlagen oder digitale Energiedienste betreiben und den §§ 5c bis 5e des Energiewirtschaftsgesetzes unterliegen. Satz 2 bis 4 des Absatzes 5 enthalten Rückausnahmen, etwa wenn die Einrichtung weitere kritische Anlagen betreibt oder aufgrund weiterer Tätigkeiten einer anderen Einrichtungsart zuzuordnen ist.
Ob eine dieser Ausnahmen auf Sie zutrifft, ist eine Rechtsfrage; die Wiedergabe folgt dem Gesetzestext im Bundesgesetzblatt (BGBl. 2025 I Nr. 301, Stand der Prüfung: 13. November 2026).
07Ablauf
Acht Schritte vom Scoping bis zur Übergabe
Sie können den Ablauf komplett oder ab einem beliebigen Schritt beauftragen.
- 01
Scoping
Mit IhnenGemeinsam mit Ihnen legen wir fest, welche Systeme, Standorte und Cloud-Konten für die Dienste Ihrer Einrichtung relevant sind. Die rechtliche Einordnung bringen Sie mit.
- 02
Bestandsaufnahme
Ergebnis: InventarWir erfassen Plattformen, Netze, Identitäten, Datenspeicher, Backups und externe Dienstleister. Wo Infrastructure as Code vorhanden ist, nutzen wir den Zustand als Quelle, sonst Konfigurationsexporte und Interviews.
- 03
Technische Gap-Analyse
Ergebnis: Gap-BerichtJeder der zehn Bereiche aus § 30 Abs. 2 BSIG wird gegen den tatsächlichen Zustand geprüft (Tabelle oben).
- 04
Bewertung
Entscheidung bei IhnenJede Abweichung erhält eine Einstufung nach Risiko und Aufwand. Die Risikoakzeptanz bleibt eine Entscheidung Ihrer Geschäftsleitung.
- 05
Maßnahmenplan
Ergebnis: PlanPriorisierte, technisch konkrete Maßnahmen mit Abhängigkeiten.
- 06
Umsetzung
Ergebnis: ControlsWir setzen um, was technisch umsetzbar ist: Konfiguration, Automatisierung, Richtlinien als Code, Backup-Architektur, Logging-Anbindung.
- 07
Nachweise
Ergebnis: ArtefakteKonfigurationsstände, Testprotokolle und Runbooks werden so abgelegt, dass sie Ihre Dokumentationspflicht nach § 30 Abs. 1 BSIG stützen.
- 08
Übergabe oder Betrieb
Ihr Team oder wirÜbergabe an Ihr Team mit Dokumentation und Einweisung; optional laufender Betrieb über unsere Managed Services.
08Anlass
Typische Ausgangslagen: Wenn aus der Pflicht der Geschäftsleitung ein belastbarer Stand werden soll
Typische Ausgangslagen, in denen eine technische Umsetzung sinnvoll ist: Papierlage und Konfiguration laufen auseinander.
- Die Geschäftsleitung hat die Pflicht aus § 38 BSIG erkannt und verlangt von der IT einen belastbaren Stand statt einer Absichtserklärung.
- Es existiert ein Maßnahmenkatalog oder ein ISMS auf dem Papier, aber niemand kann zeigen, welche Konfiguration in Cloud, Kubernetes oder Rechenzentrum das umsetzt.
- Backup, Zugriffsrechte oder Lieferantenzugänge sind historisch gewachsen und nicht dokumentiert.
- Die Plattform wird gerade neu gebaut (Cloud-Migration, Kubernetes-Einführung, souveräne Cloud) und soll die Anforderungen von Anfang an erfüllen.
09Plattformen
Dieselben Controls auf AWS, Azure, STACKIT, Kubernetes oder eigener Hardware
Die Maßnahmen setzen wir plattformneutral um: auf AWS, Azure, STACKIT, auf Kubernetes und auf eigener Infrastruktur, etwa mit Proxmox oder in einer souveränen Cloud. Die Wahl folgt Ihren Anforderungen, nicht einem Produkt.
Für Erkennung und Alarmierung binden wir Ihr bestehendes SIEM an; ein eigener Security-Operations-Betrieb ist nicht Gegenstand dieser Seite. Wir hängen die technischen Controls an Ihre vorhandenen ISMS-Dokumente und Begriffe an, statt ein paralleles System aufzubauen.
10Voraussetzungen
Was wir von Ihnen für die Gap-Analyse brauchen
- Zugriff auf Cloud-Konten, Kubernetes-Cluster, Backup- und Identitätssysteme (lesend für die Analyse; schreibend für die Umsetzung, jeweils nach Freigabe)
- Eine benannte Person für Informationssicherheit oder IT-Leitung als Entscheiderin oder Entscheider für Maßnahmen
- Ihre rechtliche Einordnung der Betroffenheit
- Vorhandene ISMS-Dokumente, falls vorhanden
- Verfügbarkeit von Systemverantwortlichen für Rückfragen und Abnahmen
11Angebot
Was den Aufwand eines NIS2-Projekts bestimmt
Aufwand und Kosten bestimmen vor allem:
- die Zahl der Systeme und Plattformen im Scope,
- der Reifegrad von Dokumentation und Automatisierung,
- die Anzahl der Standorte und Cloud-Konten,
- die Tiefe der Umsetzung (nur Analyse, Analyse mit Umsetzung oder Umsetzung mit Betrieb),
- Abhängigkeiten zu Ihren Dienstleistern.
Auf dieser Basis erstellen wir nach einem Erstgespräch ein Angebot mit klar abgegrenztem Leistungsumfang. Für Einordnung und Scope sprechen wir gern mit Ihnen: Projekt anfragen.
12Abgrenzung
Für wen die technische NIS2-Umsetzung gedacht ist und wofür Sie jemand anderen brauchen
Das passt
- Sie müssen aus § 30 BSIG konkrete Konfiguration und belegbare Nachweise machen.
- Sie wollen Analyse, Umsetzung oder Umsetzung mit Betrieb aus einer Hand.
- Sie haben ein ISMS und brauchen die technische Seite dazu.
Das liefern wir nicht
- Rechtsberatung oder ein Gutachten zur Betroffenheit: dafür brauchen Sie eine Kanzlei.
- Ein Zertifikat oder eine Konformitätsgarantie.
- Ausschließlich Richtlinien, Schulungsunterlagen und organisatorische Dokumente ohne technische Umsetzung.
- Einen vollständigen Security-Operations-Betrieb oder unabhängige Penetrationstests als eigenständige Leistung.
13
Häufige Fragen
Können Sie bestätigen, dass wir NIS2-konform sind?
Nein. Wir dokumentieren den technischen Stand und die umgesetzten Maßnahmen. Die Bewertung der Konformität liegt bei Ihnen, Ihren Prüfern und der Aufsicht.
Gilt NIS2 überhaupt für uns?
Das entscheidet sich nach § 28 BSIG und der Einrichtungsart. Lassen Sie das juristisch klären. Sobald Sie die Einordnung haben, bestimmen wir den technischen Scope.
Arbeiten Sie mit bestehenden ISMS-Strukturen?
Ja. Wir hängen die technischen Controls an Ihre vorhandenen Dokumente und Begriffe an, statt ein paralleles System aufzubauen.
Aus § 30 BSIG wird Konfiguration: Scope mit uns klären
Schildern Sie uns Ihre Plattformen und den Stand Ihrer Dokumentation. Wir ordnen den technischen Scope ein und erstellen ein Angebot mit klar abgegrenztem Leistungsumfang.