¶ Verhältnismäßigkeit und Stand der Technik
Keine automatische Konformitätsaussage: Diese öffentliche Musterseite bestätigt nicht, dass eine bestimmte Organisation, Architektur, Technologie oder Maßnahme angemessen, verhältnismäßig, wirksam oder Stand der Technik ist. Die Bewertung muss für den konkreten Dienst, Scope, Zeitpunkt und Rechtsrahmen erfolgen.
Kosten sind nur ein Faktor: Hohe Kosten allein rechtfertigen keine unzureichende Sicherheitsmaßnahme. Eine abweichende oder gestufte Lösung benötigt eine belastbare Risiko- und Optionsprüfung, wirksame Zwischenkontrollen, befugte Entscheidung, Befristung und Wiedervorlage.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-MA-02-04 |
| Dokumentenart | Bewertungsverfahren und Entscheidungsakte für Verhältnismäßigkeit und Stand der Technik |
| Wiki.js-Pfad | /NIS2/02-Risikomanagement-und-Nachweise/Verhaeltnismaessigkeit-und-Stand-der-Technik |
| Verantwortlich | Informationssicherheitsfunktion; Dienst-, Risiko- und System-Owner; Compliance |
| Status | Entwurf – keine realen Technologien bewertet und keine Kriterien oder Abweichungen freigegeben |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Wiki enthält Methodik und Muster; Architektur-, Schwachstellen- und Kostendetails geschützt |
| Rechtsbezug | insbesondere § 30 BSIG; abhängig vom Einzelfall §§ 31 und 37 BSIG sowie EU-Vorgaben |
| Freigabe | Ausstehend; Quellenhierarchie, Bewertungsschwellen und Entscheidungsbefugnisse festzulegen |
Technische Eignung, Risikowirkung, Lebenszyklus, Kosten und verfügbare Alternativen transparent abwägen. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Bewertungs-Cockpit – Muster ohne Echtdaten
Das Cockpit zeigt die vorgesehene Arbeits- und Leitungsansicht. Ein Gedankenstrich bedeutet: Auf dieser Musterseite liegt kein realer Bewertungswert vor. Fehlende Daten dürfen nicht als Null, Freigabe oder angemessene Umsetzung interpretiert werden.
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein reales Cockpit nennt Stichtag, Scope, Datenquelle, Rechtsstand und Aussagegrenze. Die Zahl eingesetzter Sicherheitsprodukte ist kein Beleg für Angemessenheit oder Wirksamkeit.
¶ 2. Zweck und Arbeitsergebnisse
Das Verfahren soll für eine konkrete Schutzfrage nachvollziehbar beantworten:
- Welche Risiken und Dienstwirkungen müssen beherrscht werden?
- Welche verbindlichen und fachlichen Anforderungen gelten?
- Welche technisch und organisatorisch geeigneten Optionen sind verfügbar?
- Welche Option ist wirksam, nachhaltig betreibbar und verhältnismäßig?
- Welche Annahmen, Unsicherheiten und Restlücken bleiben bestehen?
- Welche Zwischenmaßnahmen, Nachweise und Reviews sind erforderlich?
Das Arbeitsergebnis ist eine versionierte Entscheidungsakte. Sie verbindet Risiko, Dienst, Anforderung, Quellenlage, Optionsvergleich, Kosten, Entscheidung, Nachweise, Restrisiko und Wiedervorlage.
¶ 3. Fünf Begriffe getrennt bewerten
| Begriff | Arbeitsdefinition für das Verfahren |
|---|---|
| geeignet | Die Maßnahme kann das definierte Sicherheitsziel im vorgesehenen Scope unterstützen. |
| verhältnismäßig | Schutzwirkung, Risiko, Folgen, Größe, Kosten und verfügbare Alternativen stehen in nachvollziehbarer Relation. |
| wirksam | Das Sicherheitsziel wird im realen Betrieb anhand geeigneter Kriterien tatsächlich erreicht. |
| Stand der Technik | Aktueller Entwicklungsstand fortschrittlicher, praktisch geeigneter Verfahren, Einrichtungen oder Betriebsweisen für den konkreten Anwendungsfall. |
| einschlägige Norm | Fachliche Referenz, deren Anwendungsbereich, Ausgabe und Anforderungen zur Schutzfrage passen. |
Die Begriffe überschneiden sich, sind aber nicht austauschbar. Eine moderne Technologie kann ungeeignet implementiert sein; eine zertifizierte Organisation kann eine einzelne Schutzfrage unzureichend behandeln; eine kostengünstige Kontrolle kann bei hoher Dienstwirkung unverhältnismäßig schwach sein.
¶ 4. Rechtsrahmen des § 30 BSIG
§ 30 Absatz 1 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen. Für die Verhältnismäßigkeit nennt das Gesetz insbesondere Risikoexposition, Größe der Einrichtung, Umsetzungskosten sowie Eintrittswahrscheinlichkeit und Schwere möglicher Sicherheitsvorfälle einschließlich gesellschaftlicher und wirtschaftlicher Auswirkungen. Die Einhaltung ist zu dokumentieren.
Nach § 30 Absatz 2 sollen Maßnahmen den Stand der Technik einhalten, einschlägige europäische und internationale Normen berücksichtigen und auf einem gefahrenübergreifenden Ansatz beruhen. Das bedeutet weder eine freie Produktwahl ohne Begründung noch eine starre, zeitlose Checkliste.
Diese Wiki-Seite ist eine methodische Orientierung und keine Rechtsberatung. Anwendbarkeit und Auslegung werden im Einzelfall geprüft.
¶ 5. Vorrang konkretisierender EU-Vorgaben
Für die in § 30 Absatz 3 BSIG genannten Einrichtungsarten hat die Durchführungsverordnung (EU) 2024/2690 Vorrang. Dazu gehören unter anderem bestimmte DNS-, TLD-, Cloud-, Rechenzentrums-, CDN-, Managed-Service-, Managed-Security-Service-, Onlineplattform- und Vertrauensdiensteanbieter.
Vor Anwendung einer allgemeinen Bewertungsmatrix ist deshalb zu prüfen:
- Gehört die Einrichtung oder der bewertete Dienst zu einer erfassten Kategorie?
- Welche technischen und methodischen Anforderungen sind unmittelbar einschlägig?
- Welche Konkretisierung verbleibt noch für Risiko, Scope und Umsetzung?
- Bestehen zusätzliche nationale, sektorale oder vertragliche Anforderungen?
Eine allgemeine interne Risikoakzeptanz darf vorrangige Anforderungen nicht verdrängen.
¶ 6. Besondere Lage kritischer Anlagen
Für Betreiber kritischer Anlagen kann § 31 BSIG ein erhöhtes Schutzniveau verlangen. Bei maßgeblichen Systemen, Komponenten und Prozessen werden die Folgen eines Ausfalls oder einer Beeinträchtigung besonders gewichtet. Anforderungen an Systeme zur Angriffserkennung sind gesondert zu beachten.
Die Einstufung als kritische Anlage und der konkrete Scope werden nicht aus der Mustervorlage abgeleitet. Sie benötigen eine organisations- und anlagenbezogene Prüfung.
¶ 7. Bewertungsobjekt und Scope
Jede Bewertung beginnt mit einem eindeutig abgegrenzten Objekt. Mögliche Objekte sind:
- relevanter Dienst oder kritische Anlage,
- Prozess, Standort oder Organisationseinheit,
- Informationssystem, Komponente oder Schnittstelle,
- Cloud-, Plattform- oder Lieferantenleistung,
- technische Sicherheitsfunktion,
- organisatorische Kontrolle oder Betriebsverfahren.
Der Scope nennt produktive und nicht produktive Umgebungen, Standorte, Nutzergruppen, Datenarten, Abhängigkeiten, ausgeschlossene Bereiche und Betrachtungszeitraum. Ohne Scope ist eine Aussage zum Stand der Technik nicht belastbar.
¶ 8. Bewertungsanlass
Eine Bewertung kann ausgelöst werden durch:
- neue oder wesentlich geänderte Dienste und Systeme,
- Risikobehandlung oder Architekturentscheidung,
- Beschaffung, Vertragsverlängerung oder Anbieterwechsel,
- neue Bedrohung, Schwachstelle oder Angriffsmethode,
- Produktabkündigung oder Ende des Herstellersupports,
- Vorfall, Auditfeststellung oder Wirksamkeitsmangel,
- neue Norm, technische Richtlinie oder behördliche Veröffentlichung,
- Änderung von Rechtslage, Scope, Nutzung oder Skalierung,
- regelmäßige Wiedervorlage kritischer Kontrollen.
Anlass und Stichtag werden in der Entscheidungsakte festgehalten.
¶ 9. Durchgängige Referenzkette
Die Nachvollziehbarkeit folgt der Kette:
Dienst → Szenario/Risiko → Schutz- und Rechtsanforderung → aktuelle Quellenlage → realistische Optionen → Vergleich → Entscheidung → Maßnahme → Nachweis → Wirksamkeit → Restrisiko → Review
Jeder Übergang benötigt eine Referenz. Herstellerfolien, Einzelmeinungen oder ein Budgetwert ersetzen die fachliche Verbindung nicht.
¶ 10. Quellenhierarchie
Quellen werden nach Bindungswirkung, Aktualität und Passung eingeordnet. Eine mögliche Reihenfolge ist:
- unmittelbar anwendbares Recht und konkretisierende Rechtsakte,
- verbindliche behördliche Festlegungen und sektorspezifische Vorgaben,
- einschlägige technische Richtlinien, geeignete Normen und Standards,
- BSI-, ENISA- und andere behördliche Empfehlungen,
- anerkannte Branchenstandards und erprobte Praxis,
- aktuelle Bedrohungs-, Schwachstellen- und Lageinformationen,
- unabhängige Prüfungen und wissenschaftlich-technische Erkenntnisse,
- Herstellerinformationen und Produktdokumentationen.
Die Reihenfolge ist kein Automatismus. Entscheidend bleiben Rechtsbezug, Anwendungsbereich, Ausgabe, Aktualität und Aussagekraft für den konkreten Fall.
¶ 11. Quellenregister
| Feld | Inhalt |
|---|---|
| Quellen-ID | dauerhafte Referenz |
| Titel/Herausgeber | eindeutige Bezeichnung und verantwortliche Stelle |
| Typ | Gesetz, Verordnung, Norm, Richtlinie, Empfehlung, Lageinformation oder Herstellerquelle |
| Version/Stand | Ausgabe, Veröffentlichungs- und Abrufdatum |
| Geltungsbereich | Branche, Technologie, Dienst, Region und Zielgruppe |
| Relevanz | betroffene Schutzfrage und konkrete Anforderung |
| Bindungswirkung | verbindlich, vorrangig, zu berücksichtigen oder informativ |
| Aussagegrenze | Ausschlüsse, Annahmen und verbleibender Interpretationsbedarf |
| Owner/Review | verantwortliche Rolle und nächster Aktualitätstermin |
Veraltete Quellen werden nicht gelöscht, sondern als ersetzt markiert und mit dem Nachfolger verbunden.
¶ 12. Technikreife und Bewertungsampel
aktuelle Quellen, praktische Eignung, tragfähiger Betrieb und ausreichende Nachweise im Scope.
grundsätzlich geeignet, aber mit dokumentierten Grenzen, Übergang oder offenen Nachweisen.
wesentliche Schutzlücke, veraltete Technik, fehlende Eignung oder keine vertretbare Risikoreduktion.
Scope, Quellen oder Prüfergebnisse reichen für eine belastbare Aussage noch nicht aus.
Die Farbe wird immer mit Begründung, Quelle, Prüfer, Datum und nächster Aktion dokumentiert.
¶ 13. Technologiestufen nicht verwechseln
Das Verfahren unterscheidet:
- Stand von Wissenschaft und Forschung: hohe Innovation, aber möglicherweise noch geringe Marktreife oder Praxiserprobung,
- Stand der Technik: fortschrittlich und praktisch geeignet, ohne bereits überall allgemein anerkannt und langjährig bewährt sein zu müssen,
- allgemein anerkannte Regeln der Technik: stärker verbreitet, anerkannt und in der Praxis bewährt.
„Neueste Technik“ ist daher nicht automatisch „Stand der Technik“. Umgekehrt kann langjährige Verbreitung kein Argument für eine inzwischen unsichere Alttechnologie sein.
¶ 14. Ermittlung der grundlegenden Anforderungen
Vor dem Produkt- oder Lösungsvergleich werden die Anforderungen festgelegt:
- Schutz von Verfügbarkeit, Integrität und Vertraulichkeit,
- gegebenenfalls Authentizität, Nachvollziehbarkeit und Resilienz,
- relevante Dienst- und Wiederanlaufanforderungen,
- Bedrohungen und Angriffspfade,
- gesetzliche und sektorale Mindestanforderungen,
- Schnittstellen, Lieferketten und Notfallbetrieb,
- Betriebs-, Wartungs- und Überwachungsfähigkeit,
- Datenschutz, Arbeitsschutz und weitere Compliance-Anforderungen.
Nur so lässt sich vermeiden, dass eine vorhandene Produktfunktion nachträglich zum unpassenden Bewertungsmaßstab wird.
¶ 15. All-Gefahren-Ansatz
Der gefahrenübergreifende Ansatz berücksichtigt neben Cyberangriffen auch technische Fehler, Fehlbedienung, Versorgungsunterbrechung, physische Einwirkung, Naturereignis, Lieferantenausfall, Personalengpass und organisatorisches Versagen. Die Relevanz wird anhand des betrachteten Dienstes und Szenarios bestimmt.
Eine hochwirksame Cyberkontrolle kann unverhältnismäßig unvollständig sein, wenn sie beispielsweise Stromversorgung, Wiederanlauf, Schlüsselverlust oder Lieferkettenausfall nicht berücksichtigt.
¶ 16. Risikoexposition
Zur Risikoexposition gehören nicht nur der aktuelle Risikowert, sondern unter anderem:
- Attraktivität und Erreichbarkeit des Ziels,
- bekannte Schwachstellen und technische Schulden,
- Abhängigkeit von Identitäten, Netzen, Cloud und Lieferanten,
- Konzentration und fehlende Alternativen,
- Häufigkeit und Geschwindigkeit möglicher Auswirkungen,
- bestehende Kontrollen und deren nachgewiesene Wirksamkeit,
- Unsicherheit und fehlende Daten,
- externe Bedrohungs- und Lageinformationen.
Die Bewertung verweist auf das Risikoregister und übernimmt keine unkontrollierte Kopie.
¶ 17. Eintrittswahrscheinlichkeit und Schwere
Wahrscheinlichkeit und Schwere werden getrennt begründet. Schwere umfasst unmittelbare und mittelbare Folgen für Dienst, Kunden, Beschäftigte, Partner und Öffentlichkeit. Ein seltenes Szenario kann bei katastrophaler Dienstwirkung hohe Anforderungen begründen.
Zeitverlauf, Dauer, räumliche Ausbreitung, Wiederherstellbarkeit und Kaskadenwirkung werden berücksichtigt. Numerische Werte ohne Szenariobeschreibung sind nicht ausreichend.
¶ 18. Gesellschaftliche und wirtschaftliche Auswirkungen
Gesellschaftliche Auswirkungen können Versorgung, Gesundheit, Sicherheit, Vertrauen oder grenzüberschreitende Dienste betreffen. Wirtschaftliche Auswirkungen umfassen nicht nur unmittelbaren Umsatzverlust, sondern auch Wiederherstellung, Vertragsfolgen, Lieferketten, Haftung, Kunden- und Marktfolgen.
Die Organisation dokumentiert, welche Wirkungen sie belastbar einschätzen kann und wo Unsicherheit bleibt. Sensible Berechnungen verbleiben geschützt.
¶ 19. Größe und Leistungsfähigkeit der Einrichtung
Größe beeinflusst Ressourcen, Komplexität, Skalierung und Umsetzungsweg. Sie senkt jedoch nicht automatisch ein durch Dienstwirkung oder verbindliche Vorgaben erforderliches Schutzniveau. Kleinere Einrichtungen können standardisierte, verwaltete oder gemeinsam genutzte Lösungen einsetzen, wenn diese wirksam und beherrschbar sind.
Bewertet werden unter anderem Mitarbeitendenzahl, Standorte, Systemlandschaft, Nutzer- und Transaktionsvolumen, Umsatz/Bilanz, Verbundstruktur, interne Kompetenz und Betriebsmodell.
¶ 20. Kosten über den gesamten Lebenszyklus
Kosten umfassen:
- Analyse, Beschaffung und Vertragsgestaltung,
- Einführung, Migration, Integration und Test,
- Schulung, Kommunikation und Prozessanpassung,
- Lizenzen, Hardware, Personal und externe Leistungen,
- Betrieb, Monitoring, Wartung und Support,
- Notfallbetrieb, Redundanz und Wiederherstellung,
- Audit, Nachweis und regelmäßige Neubewertung,
- Exit, Ablösung, Datenmigration und sichere Entsorgung.
Anschaffungspreis und Sicherheitsnutzen dürfen nicht isoliert verglichen werden. Eine scheinbar günstige Lösung mit hohem Betriebs- oder Lock-in-Risiko kann über den Lebenszyklus ungeeignet sein.
¶ 21. Nutzen und erwartete Risikoreduktion
Der Nutzen wird als überprüfbare Wirkung beschrieben. Dazu gehören beispielsweise geringere Angriffsfläche, niedrigere Ausfallwahrscheinlichkeit, begrenzter Schaden, schnellere Erkennung, kürzere Wiederherstellung oder geringere Abhängigkeit.
Die erwartete Wirkung erhält Hypothese, Scope, Zielkriterium, Prüfmethode und Zeitpunkt. Marketingversprechen oder allgemeine Produktzertifikate ersetzen die betriebliche Wirksamkeitsprüfung nicht.
¶ 22. Vergleich realistischer Optionen
| Bewertungspunkt | Leitfrage |
|---|---|
| Schutzwirkung | Welche Szenarien und Schutzziele werden im Scope wie begrenzt? |
| Rechts-/Normbezug | Welche verbindlichen und fachlichen Anforderungen werden erfüllt? |
| Reife/Praxiseignung | Ist die Lösung fortschrittlich, verfügbar, erprobt und angemessen beherrschbar? |
| Betrieb | Sind Kompetenz, Monitoring, Wartung, Support und Notfallbetrieb gesichert? |
| Integration | Welche Schnittstellen, Migrationen und Abhängigkeiten entstehen? |
| Nebenrisiken | Entstehen neue Cloud-, Lieferanten-, Datenschutz-, Komplexitäts- oder Konzentrationsrisiken? |
| Lebenszyklus | Wie werden Updates, Kryptografie, Abkündigung, Exit und Ablösung gesteuert? |
| Gesamtkosten | Welche einmaligen und laufenden Aufwände entstehen? |
| Nachweisbarkeit | Können Umsetzung und Wirksamkeit geeignet belegt werden? |
Mindestens die ernsthaft verfügbaren Optionen einschließlich organisatorischer, technischer und gestufter Varianten werden verglichen.
¶ 23. Gewichtung und Entscheidungsmatrix
Eine Bewertungsmatrix kann Transparenz schaffen, ersetzt aber keine Fachentscheidung. Gewichtungen werden vor dem Vergleich festgelegt und dürfen nicht nachträglich zugunsten einer Wunschlösung verändert werden. Mindestanforderungen werden als Ausschlusskriterien statt als kompensierbare Punktwerte behandelt.
Ergebnis, Sensitivität und Unsicherheit werden erläutert. Bei ähnlichen Punktwerten können Pilot, Proof of Concept oder unabhängige Prüfung erforderlich sein.
¶ 24. Verhältnismäßigkeit ist keine reine Kostenrechnung
Eine Maßnahme kann trotz hoher Kosten verhältnismäßig sein, wenn schwere oder gesellschaftlich relevante Auswirkungen verhindert werden. Umgekehrt kann eine teure Technologie ungeeignet sein, wenn sie das maßgebliche Risiko nicht wirksam reduziert oder nicht sicher betrieben werden kann.
Kostenargumente werden deshalb immer mit Alternativen, Dienstwirkung, Risikoreduktion, Lebenszyklus und verbleibenden Folgen verbunden.
¶ 25. Normen, Standards und Zertifizierungen
Normen und Standards strukturieren Anforderungen und Vergleichsmaßstäbe. Vor Verwendung werden Ausgabe, Anwendungsbereich, Aktualität und konkrete Kontrollanforderung geprüft. Eine ISO-27001-Zertifizierung oder TISAX-Bewertung kann hilfreiche Nachweise liefern, bestätigt aber nicht automatisch die NIS2-Verhältnismäßigkeit jeder einzelnen Maßnahme.
Ein Zertifikat wird auf Organisationseinheit, Standort, Dienst, Ausschlüsse, Gültigkeit und zugrunde liegende Prüfgrenzen geprüft.
¶ 26. Hersteller- und Anbieterangaben
Herstellerinformationen liefern wichtige technische Details, besitzen aber ein eigenes Vertriebsinteresse. Aussagen zu „Best Practice“, „Zero Trust“, „NIS2-ready“ oder „state of the art“ werden nicht ungeprüft übernommen.
Erforderlich sind technische Dokumentation, Support- und Updatepolitik, Schwachstellenprozess, Lebenszyklus, Referenzen, unabhängige Prüfungen, vertragliche Zusagen und betriebliche Eignung.
¶ 27. Alttechnologien und technische Schulden
Legacy-Systeme werden auf Supportstatus, bekannte Schwachstellen, Segmentierbarkeit, Wiederherstellbarkeit, Protokollierung, Authentisierung, Ersatzteile, Kompetenzen und Exit-Fähigkeit geprüft. „Historisch gewachsen“ ist keine Begründung für dauerhafte Untätigkeit.
Ist eine sofortige Ablösung nicht möglich, benötigt die Entscheidung eine Roadmap, wirksame Kompensationen, Überwachung, Ablaufdatum und Restrisikofreigabe.
¶ 28. Produktlebenszyklus und Hersteller-Support
End-of-Sale, End-of-Support und End-of-Security-Updates werden getrennt geführt. Der Plan berücksichtigt Vorwarnzeit, Migrationsdauer, Ersatzstrategie und sichere Außerbetriebnahme. Eine Technologie kann vor dem formalen Supportende ungeeignet werden, wenn Bedrohungslage oder Anforderungen sich wesentlich ändern.
Supportverträge ersetzen nicht die eigene Bewertung von Aktualität und Wirksamkeit.
¶ 29. Kryptografie und technischer Wandel
Kryptografische Verfahren werden hinsichtlich Algorithmus, Schlüssellänge, Protokoll, Implementierung, Schlüsselmanagement, Zertifikaten, Hardware, Nutzungskontext und Migrationsfähigkeit bewertet. Technische Entwicklungen und behördliche Empfehlungen können eine vorzeitige Ablösung erfordern.
Eine sichere Bibliothek allein genügt nicht, wenn Schlüssel unsicher verwaltet, Zertifikate nicht erneuert oder veraltete Protokolle weiterhin zugelassen werden.
¶ 30. Cloud, Plattformen und Lieferketten
Bei ausgelagerten Leistungen werden Verantwortungsgrenzen, Konfiguration, Mandantentrennung, Identitäten, Protokolle, Notfallzugriff, Datenstandorte, Unterauftragnehmer, Exit und Nachweisrechte betrachtet. Ein Anbieterzertifikat deckt nicht automatisch die kundenindividuelle Konfiguration oder den gesamten Dienst ab.
Konzentrations- und Kaskadenrisiken werden in den Optionsvergleich aufgenommen.
¶ 31. Pilot, Proof of Concept und Test
Neue oder unsichere Optionen können durch Pilot oder Proof of Concept bewertet werden. Vorab werden Ziel, Scope, Testdaten, Erfolgskriterien, Sicherheitsgrenzen und Rückbau festgelegt. Ein erfolgreicher Labortest beweist nicht automatisch Skalierbarkeit oder Wirksamkeit im Dauerbetrieb.
Testresultate, Fehler, Ausschlüsse und offene Annahmen fließen in die Entscheidung ein.
¶ 32. Abweichungs- und Übergangsentscheidung
Kann der ermittelte Stand der Technik vorübergehend nicht vollständig erreicht werden, dokumentiert die Entscheidung:
- konkrete Anforderung und Abweichung,
- Tatsachenbasis und Ursachen,
- geprüfte Alternativen und Ausschlussgründe,
- Risiko- und Dienstwirkung,
- wirksame Zwischen- oder Kompensationsmaßnahmen,
- Owner, Budget, Roadmap und Zieltermin,
- Restrisiko und befugten Entscheider,
- Ablaufdatum, Überwachung und Reviewauslöser.
Eine interne Abweichung ist kein Ausnahmebescheid nach § 37 BSIG und beseitigt keine gesetzliche Pflicht.
¶ 33. Statusmodell der Bewertung
„Freigegeben“ gilt nur für den dokumentierten Scope und Stichtag. Es ist keine dauerhafte Allgemeinaussage zur Technologie.
¶ 34. Entscheidungsakte – Mindestfelder
| Feldgruppe | Mindestinhalt |
|---|---|
| Identität | Bewertungs-ID, Titel, Version, Anlass und Stichtag |
| Scope | Dienst, Prozess, System, Standort, Anbieter, Daten und Ausschlüsse |
| Risiko | Szenario, Exposition, Wahrscheinlichkeit, Schwere und Unsicherheit |
| Anforderungen | Rechtsbezug, Normen, technische und betriebliche Anforderungen |
| Quellen | Quelle, Version, Abrufdatum, Relevanz und Aussagegrenze |
| Optionen | Schutzwirkung, Reife, Betrieb, Lebenszyklus, Nebenrisiken und Kosten |
| Entscheidung | gewählte Lösung, Begründung, Bedingungen, Entscheider und Datum |
| Abweichung | Restlücke, Kompensation, Roadmap, Ablauf und Eskalation |
| Nachweis | Umsetzung, Test, Abnahme, Wirksamkeit und kontrollierte Referenzen |
| Review | Regeltermin, Frühwarnindikatoren und anlassbezogene Auslöser |
Abweichende Fachmeinungen und nicht gewählte Optionen bleiben nachvollziehbar.
¶ 35. Rollen und RACI-Grundmodell
| Aufgabe | Dienst-/Risk Owner | Informationssicherheit | Architektur/Betrieb | Einkauf/Finanzen | Legal/Compliance | Leitung |
|---|---|---|---|---|---|---|
| Scope und Schutzfrage festlegen | V | M | M | I | K | I |
| Quellen und Anforderungen prüfen | M | V | M | I | M | I |
| technische Optionen bewerten | K | M | V | K | K | I |
| Kosten und Vertragslage bewerten | I | K | M | V | M | I |
| Empfehlung erstellen | V | M | M | K | K | I |
| wesentliche Abweichung entscheiden | M | K | K | K | K | V/E |
| Wirksamkeit und Aktualität prüfen | M | V | M | I | K | I |
V = verantwortlich, M = mitwirkend, K = konsultiert, I = informiert, E = entscheidend. Die tatsächliche Matrix folgt Vollmachten und Organisation.
¶ 36. Review und Frühwarnindikatoren
Regelmäßige und anlassbezogene Reviews betrachten:
- neue Schwachstellen, Angriffsmethoden und Lageinformationen,
- geänderte Normen, Rechtsakte oder behördliche Empfehlungen,
- Herstellerabkündigung und Supportänderung,
- Wirksamkeitsmängel, Vorfälle und Auditfeststellungen,
- neue Dienste, Skalierung, Standorte oder Nutzergruppen,
- Anbieter-, Unterauftragnehmer- oder Architekturwechsel,
- deutliche Kosten-, Verfügbarkeits- oder Leistungsänderung,
- Ablauf einer Abweichung, Kompensation oder Risikoakzeptanz.
Frühwarnindikatoren erhalten Quelle, Schwelle, Empfänger und Reaktionszeit.
¶ 37. Technologieradar
Das Technologieradar beobachtet für kritische Schutzfragen:
- Lebenszyklus und Support aktueller Lösungen,
- neue Schutztechnologien und deren Reife,
- Kryptografie- und Protokollentwicklung,
- Bedrohungs- und Schwachstellenlage,
- Normen, BSI-/ENISA-Veröffentlichungen und EU-Rechtsakte,
- Branchenpraxis und unabhängige Prüfungsergebnisse,
- Lieferketten- und Konzentrationsrisiken.
Es ist kein Einkaufskatalog. Beobachtungen werden erst nach fachlicher Bewertung zu Anforderungen oder Maßnahmen.
¶ 38. Kennzahlen und Steuerungsansichten
Mögliche Kennzahlen sind:
- kritische Schutzfragen ohne aktuelle Bewertung,
- Bewertungen mit ungeklärter oder veralteter Quellenlage,
- befristete Abweichungen nach Risikostufe,
- überfällige Reviews und Roadmap-Meilensteine,
- Alttechnologien ohne genehmigte Ablösestrategie,
- Optionen ohne Lebenszyklus- oder Wirksamkeitsbetrachtung,
- Maßnahmen mit nicht bestandenem Wirksamkeitsnachweis,
- wiederkehrende Abweichungsursachen.
Jede Kennzahl nennt Definition, Stichtag, Scope, Quelle und Aussagegrenze.
¶ 39. Fiktive Musterbewertungen
Die folgenden Zeilen sind reine Demonstrationsdaten. Sie bewerten keine reale Technologie oder Organisation.
| ID | fiktive Schutzfrage | fiktiver Scope | Technikampel | Status | Entscheidung/Review |
|---|---|---|---|---|---|
| DEMO-ST-001 | Unterstützungsende eines Musterbetriebssystems | Beispielplattform A | × ROT · MUSTER | ▲ ENTSCHEIDUNG OFFEN | keine reale Entscheidung |
| DEMO-ST-002 | stärkere Authentisierung für Musterfernzugriff | Beispieldienst B | ! GELB · MUSTER | ◇ OPTIONEN BEWERTET | Wirksamkeit ungeprüft |
| DEMO-ST-003 | Aktualisierung eines Musterprotokolls | fiktive Schnittstelle | ○ GRAU · MUSTER | ◆ QUELLEN GEPRÜFT | Scope noch offen |
¶ 40. Qualitätsgate vor Freigabe
- Sind Bewertungsobjekt, Dienst, Scope und Stichtag eindeutig?
- Wurden vorrangige EU-, nationale und sektorale Vorgaben geprüft?
- Sind Quellen aktuell, einschlägig und mit Aussagegrenzen dokumentiert?
- Sind Risikoexposition, Eintritt, Schwere und Folgen nachvollziehbar?
- Wurden mehrere realistische technische und organisatorische Optionen verglichen?
- Berücksichtigt die Kostenbetrachtung den gesamten Lebenszyklus?
- Sind praktische Eignung, Betrieb, Wartung und Notfallfähigkeit bewertet?
- Sind Neben-, Lieferketten-, Datenschutz- und Konzentrationsrisiken sichtbar?
- Besitzen Abweichungen wirksame Kompensationen, Roadmap und Ablaufdatum?
- Sind Wirksamkeitsnachweis, Restrisiko, Entscheider und Review festgelegt?
Erst nach bestandenem Qualitätsgate erhält die Entscheidungsakte den vorgesehenen Freigabestatus.
¶ 41. Häufige Fehler und Gegenmaßnahmen
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| Kosten allein begründen Verzicht | Schutzwirkung und Alternativen fehlen | vollständigen Risiko- und Optionsvergleich verlangen |
| ein Zertifikat gilt als Gesamtbeweis | Scope und konkrete Maßnahme bleiben ungeprüft | Zertifikatsgrenzen und betriebliche Wirksamkeit prüfen |
| Hersteller nennt Produkt „NIS2-ready“ | Marketing ersetzt keine Bewertung | unabhängige Quellen, Anforderungen und Test nutzen |
| Stand der Technik wird einmalig festgestellt | technische Entwicklung bleibt unbeachtet | Review und Technologieradar einrichten |
| nur Anschaffungskosten werden betrachtet | Betrieb und Exit werden unterschätzt | Lebenszykluskosten erfassen |
| Alttechnik bleibt ohne Roadmap | Dauerabweichung | Kompensationen, Termin und befugte Entscheidung |
| Matrixwert ersetzt Fachurteil | Scheingenauigkeit | Begründung, Unsicherheit und Ausschlusskriterien dokumentieren |
| interne Akzeptanz wird mit § 37 verwechselt | falsche Rechtswirkung | behördlichen Ausnahmebescheid klar abgrenzen |
¶ 42. Offene Entscheidungen vor produktiver Nutzung
- Quellenhierarchie und Quellenregister freigeben,
- Bewertungsobjekte, Mindestanforderungen und Ausschlusskriterien definieren,
- Technikreife-, Risiko- und Entscheidungsschwellen genehmigen,
- Lebenszyklus- und Kostenmodell abstimmen,
- Rollen, Unabhängigkeit und Entscheidungsbefugnisse festlegen,
- Verfahren für Abweichungen und Zwischenmaßnahmen beschließen,
- Technologieradar und Frühwarnindikatoren einrichten,
- Reviewintervalle je Schutzfrage bestimmen,
- Pilotbewertungen aus Technik, Organisation und Lieferkette kalibrieren.
Bis zur Entscheidung bleiben sämtliche Musterstatus ausdrücklich Entwurf.
¶ 43. Verknüpfte Seiten
- NIS2-Risikomethodik
- NIS2-Risikoregister
- Risikobehandlungsplan
- Maßnahmenkatalog nach BSIG
- Wirksamkeitsprüfung
- NIS2-Nachweisregister
- Ausnahmen und Risikoakzeptanzen
- Bedrohungsinformationen
- Schwachstellen- und Patchmanagement
¶ 44. Offizielle Grundlagen und Orientierungshilfen
- § 30 BSIG – Risikomanagementmaßnahmen und Verhältnismäßigkeitskriterien
- § 31 BSIG – besondere Anforderungen für Betreiber kritischer Anlagen
- § 37 BSIG – Ausnahmebescheid
- EUR-Lex – Durchführungsverordnung (EU) 2024/2690
- EUR-Lex – Richtlinie (EU) 2022/2555
- BSI – Orientierungshilfe zu branchenspezifischen Sicherheitsstandards mit Begriffsorientierung zum Stand der Technik
Anwendbarkeit, Rechtsstand, behördliche Festlegungen sowie Version und Geltungsbereich der Quellen werden vor jeder realen Entscheidung aktuell geprüft. Die Links öffnen in einem neuen Tab.
¶ 45. Weiterführende Unterstützung durch SMCT MANAGEMENT
Unterstützung bei dokumentierten Verhältnismäßigkeitsprüfungen, Stand-der-Technik-Bewertungen, Optionsvergleichen, Abweichungen und Technologie-Roadmaps.
Informationen zur NIS2-Beratung öffnen
¶ 46. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Begriffsabgrenzung, EU-Vorrangprüfung, Quellenhierarchie, Technikreifeampel, All-Gefahren-Ansatz, Risiko- und Folgenbewertung, Lebenszykluskosten, Optionsvergleich, Legacy, Kryptografie, Lieferkette, Abweichung, RACI, Technologieradar und Qualitätsgate umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Rollen, Technikquellen, Optionsvergleich, Lebenszykluskosten, Entscheidungsakte, Technologieradar und Freigabekriterien vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Musterprüfung für Verhältnismäßigkeit und Stand der Technik erstellt | Ausstehend |