OperativeOps und die NIS2-Richtlinie
Wenn KI-Agenten-Bereitstellungen wesentliche oder wichtige Einrichtungen im Sinne der NIS2 berühren, fällt die Einrichtung in den Anwendungsbereich der Richtlinie — nicht die Software. OperativeOps wird selbst betrieben und tritt damit als Softwarekomponente in Ihre Lieferkette ein, nicht als Managed-Service-Provider; die Laufzeit, die Sie absichern und überwachen müssen, betreiben Sie ohnehin bereits.
- Die meisten Organisationen, die OperativeOps einsetzen, fallen NICHT direkt unter NIS2 — der Geltungsbereich hängt vom Sektor (Anhang I oder Anhang II) und den Größenschwellen ab (in der Regel ≥50 Beschäftigte oder 10 Mio. € Jahresumsatz).
- Organisationen in Sektoren wesentlicher oder wichtiger Einrichtungen müssen NIS2 auf Unternehmensebene einhalten; OperativeOps liegt in ihrer technologischen Lieferkette gemäß Artikel 21 Absatz 2 Buchstabe d.
- OperativeOps gibt es ausschließlich im Selbstbetrieb. Es existiert kein betreutes oder gehostetes Angebot; damit ist es Softwarelieferant in Ihrer Lieferkette und nie Managed-Service-Provider — Laufzeit, Monitoring und Angriffserkennung liegen bei Ihnen.
- Der Append-only-Audit-Ledger und die rollenbezogenen Berechtigungsgrenzen sind die Kontrollen mit dem unmittelbarsten Bezug zur Vorfallsbehandlung nach Art. 21 Abs. 2 lit. b und zur Zugangssteuerung nach Art. 21 Abs. 2 lit. i.
- Die Meldepflicht bleibt bei Ihnen — Frühwarnung innerhalb von 24 Stunden, substantielle Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats gemäß Artikel 23.
- Diese Seite ist keine Rechtsberatung. Geltungsbereichsbestimmung und regulatorische Auslegung erfordern Ihre eigenen Rechtsberater.
Was die NIS2-Richtlinie verlangt
Die Netz- und Informationssicherheitsrichtlinie 2 (NIS2, Richtlinie 2022/2555/EU) ersetzt die ursprüngliche NIS-Richtlinie und erweitert deren Anwendungsbereich erheblich. Die Mitgliedstaaten mussten NIS2 bis zum 17. Oktober 2024 in nationales Recht umsetzen. In Deutschland erfolgte die Umsetzung durch das NIS2UmsuCG.
NIS2 gilt für 'wesentliche Einrichtungen' gemäß Anhang I — Sektoren wie Energie, Verkehr, Bankwesen, Finanzmarktinfrastruktur, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, IKT-Dienstemanagement, öffentliche Verwaltung und Raumfahrt — und 'wichtige Einrichtungen' gemäß Anhang II, darunter Post- und Kurierdienste, Abfallbewirtschaftung, Herstellung kritischer Produkte, Lebensmittel und digitale Anbieter. Die Größenschwellen liegen in der Regel bei ≥50 Beschäftigten oder €10 Mio. Jahresumsatz, wobei kritische Infrastrukturen unabhängig von der Größe in den Geltungsbereich fallen können.
Artikel 21 verpflichtet zu Risikomanagementmaßnahmen, die mindestens umfassen: Governance und Richtlinienadoption, Sicherheitsvorfallsbehandlung, Geschäftskontinuität und Krisenmanagement, Lieferkettensicherheit (einschließlich Lieferanten- und Dienstleisterbeziehungen), Schwachstellenoffenlegung, Einsatz von Kryptographie und Verschlüsselung, Zugangssteuerung und Asset-Management, Multi-Faktor-Authentifizierung und sichere Kommunikation.
Artikel 23 legt Meldepflichten für erhebliche Sicherheitsvorfälle fest: eine Frühwarnung an das nationale CSIRT oder die zuständige Behörde innerhalb von 24 Stunden; eine substantielle Sicherheitsvorfallsmeldung innerhalb von 72 Stunden; und einen Abschlussbericht spätestens einen Monat nach der Frühwarnung. Zwischenberichte können erforderlich sein.
Artikel 20 legt die direkte Verantwortung der Geschäftsleitung fest — Vorstände und Geschäftsführer müssen Risikomanagementmaßnahmen genehmigen, regelmäßige Schulungen zur Cybersicherheit erhalten und können persönlich für die Nichteinhaltung haftbar gemacht werden. Dies ist eine der bedeutendsten Neuerungen gegenüber der ursprünglichen NIS-Richtlinie.
Wie OperativeOps auf NIS2-Anforderungen ausgerichtet ist
| Requirement | Our control | Where |
|---|---|---|
| Lieferkettensicherheit (Art. 21 Abs. 2 lit. d) | OperativeOps tritt als Software-Artefakt samt seiner Drittanbieter-Abhängigkeiten in Ihre Lieferkette ein, nicht als betriebener Dienst. Da Sie es selbst betreiben, endet die zu betrachtende Lieferkettengrenze bei dem Release, das Sie ausrollen — dahinter steht kein externer Laufzeitbetreiber, den Sie zusätzlich bewerten müssten. | self-hosted |
| Sicherheitsvorfallsbehandlung (Art. 21 Abs. 2 lit. b) | Append-only-Audit-Ledger jeder Modellentscheidung, Agentenaktion, jedes Tool-Aufrufs und jeder menschlichen Freigabe — in Ihrer eigenen Datenbank und mit Ihrem vorhandenen SIEM auswertbar. | self-hosted |
| Zugangssteuerung (Art. 21 Abs. 2 lit. i) | Rollenbezogen abgegrenzte Agenten mit expliziten Berechtigungsgrenzen: Jeder Agent liest nur die Quellen und ruft nur die Tools auf, die ihm zugestanden sind. Menschliche Freigabe-Gates pro Aktion sind nach Rolle und Tool-Klasse konfigurierbar. | self-hosted |
| Verschlüsselung (Art. 21 Abs. 2 lit. h) | TLS zwischen den Komponenten bei der Übertragung; Verschlüsselung im Ruhezustand über die Speicherschicht und das Schlüsselmanagement, die Sie betreiben. Ihr KMS, Ihr Schlüsselmaterial, Ihre Rotationsrichtlinie — kein externer Schlüsselverwahrer im Pfad. | self-hosted |
| Geschäftskontinuität (Art. 21 Abs. 2 lit. c) | Ihre eigene Disaster-Recovery- und Backup-Strategie, angewandt auf eine Bereitstellung ohne externe Laufzeitabhängigkeit. Mit einem lokalen Modell-Backend arbeitet das System auch ganz ohne ausgehende Konnektivität weiter. | self-hosted |
| Netzsegmentierung und Egress-Kontrolle | Sämtlicher ausgehender Modellverkehr läuft über ein Egress-Gate, das Sie konfigurieren. Eine Bereitstellung mit lokalem Modell-Backend lässt sich ganz ohne ausgehenden Pfad betreiben — genau das macht die air-gapped Installation möglich. | self-hosted |
Was der Selbstbetrieb für NIS2 ändert
Für NIS2-Lieferkettenpflichten kommt es darauf an, welche Parteien in der Kette stehen und was jede von ihnen betreibt. OperativeOps gibt es ausschließlich im Selbstbetrieb — es existiert kein betreutes oder gehostetes Angebot —, also ist es Softwarelieferant und niemals Managed-Service-Provider im Sinne von Artikel 21 Absatz 2 Buchstabe d. Das ist eine engere Lieferantenbeziehung, als ein SaaS-Einkauf sie schafft: Die Abhängigkeit besteht gegenüber Release-Artefakten und deren Drittkomponenten, nicht gegenüber fremder Verfügbarkeit, fremdem Patch-Rhythmus und fremder Vorfallsreaktion.
Die Kehrseite ist, dass die Laufzeit vollständig Ihnen gehört. Sie verantworten Netzgrenze, Infrastruktur und Datenebene, können also eigene Sicherheitsprüfungen der Bereitstellung durchführen und die Angriffserkennung unmittelbar in den Security-Operations-Betrieb einbinden, den Sie ohnehin führen. Nichts an der Bereitstellung liegt außerhalb des Perimeters, den Sie ohnehin überwachen müssen, und keine Lieferantenmeldung muss Sie erreichen, bevor Sie ein Ereignis sehen — der Audit-Ledger liegt in Ihrer eigenen Datenbank.
Derselbe Umstand bestimmt den Aufwand. Es gibt kein fremdes Infrastruktur-Monitoring, auf das Sie sich stützen könnten; Anomalieerkennung, Kapazitätsüberwachung, Backup-Verifikation und Patch-Einspielung müssen Sie selbst instrumentieren. Die Meldepflicht nach Artikel 23 lag als Einrichtung ohnehin bei Ihnen; der Selbstbetrieb legt auch die vorgelagerte Erkennung in Ihre Hand. Ist Ihre Organisation dafür personell nicht aufgestellt, sollten Sie diesen Aufwand vor dem Kauf ehrlich veranschlagen.
Wofür Sie verantwortlich sind
- Geltungsbereichsbestimmung — ob Ihre Organisation als wesentliche oder wichtige Einrichtung gemäß NIS2 Anhang I oder II gilt und ob die Größenschwellen für Ihren Sektor zutreffen.
- Sicherheitsvorfallsmeldungsprozess — Einrichtung Ihres internen Prozesses für die 24-Stunden-Frühwarnung, die 72-Stunden-substantielle Meldung und den 1-Monats-Abschlussbericht an Ihr nationales CSIRT oder die zuständige Behörde gemäß Artikel 23.
- Governance und Schulung der Geschäftsleitung — Sicherstellung, dass Ihre Geschäftsleitung NIS2-Risikomanagementmaßnahmen genehmigt und Cybersicherheitsschulungen gemäß Artikel 20 erhält.
- NIS2-spezifische Risikobewertung — Dokumentation der Risiken, die Ihre OperativeOps-Bereitstellung im Rahmen Ihres übergeordneten organisatorischen Risikomanagements einführt und mindert.
- Betrieb und Überwachung der Bereitstellung — Patching, Backup-Verifikation, Kapazitäts- und Anomalieüberwachung sowie die Einbindung des Audit-Ledgers in Ihre Erkennungswerkzeuge. Im Selbstbetrieb gibt es keine vom Lieferanten betriebene Laufzeit, auf die Sie zurückfallen könnten.
- Schwachstellenoffenlegungsrichtlinie — Pflege einer Richtlinie für den Umgang mit und die Offenlegung von Schwachstellen, die in oder durch Ihre Bereitstellung entdeckt werden.
- Cyberhygieneprogramm — Implementierung und Pflege der übergreifenden Cyberhygieneanforderungen, von denen OperativeOps eine Komponente darstellt.
- Rechtsberatung einholen — NIS2-Geltungsbereichsbestimmungen und Meldepflichten erfordern rechtliche Auslegung gemäß Ihrem nationalen Umsetzungsgesetz. Wir leisten keine Rechtsberatung.
Frequently asked questions
Ist OperativeOps NIS2-konform?
NIS2-Konformität ist eine Pflicht für Einrichtungen (Organisationen), nicht für Software-Produkte. OperativeOps ist darauf ausgelegt, die NIS2-Pflichten betroffener Einrichtungen zu unterstützen — durch einen Append-only-Audit-Ledger, rollenbezogene Berechtigungsgrenzen, konfigurierbare Verschlüsselung im Ruhezustand über Ihr eigenes Schlüsselmanagement und eine Bereitstellung, die innerhalb des Perimeters bleibt, den Sie ohnehin schützen. Ob Ihre Organisation konform ist, entscheiden Ihre Rechtsberater und die zuständige Behörde; kein Softwarelieferant kann das für Sie zertifizieren.
Wann gilt NIS2 für mich?
NIS2 gilt für Ihre Organisation, wenn Sie in einem Sektor gemäß Anhang I (wesentliche Einrichtungen) oder Anhang II (wichtige Einrichtungen) der Richtlinie tätig sind und die Größenschwellen erfüllen — in der Regel ≥50 Beschäftigte oder €10 Mio. Jahresumsatz. Einige Sektoren (kritische Infrastrukturen, bestimmte Anbieter digitaler Infrastruktur) fallen unabhängig von der Größe in den Geltungsbereich. Die genauen Kriterien hängen vom nationalen Umsetzungsgesetz Ihres Mitgliedstaats ab, das nationale Besonderheiten ergänzen kann. Die Geltungsbereichsbestimmung ist eine Rechtsfrage; konsultieren Sie Ihre Rechtsberater.
Welche Rolle spielt OperativeOps für unsere NIS2-Compliance?
Es ist eine Softwarekomponente in Ihrer Lieferkette. Für betroffene Einrichtungen ist es vor allem für die Lieferkettensicherheitspflicht gemäß Artikel 21 Absatz 2 Buchstabe d und die Vorfallsbehandlung gemäß Artikel 21 Absatz 2 Buchstabe b relevant. Da es selbst betrieben wird, umfasst die Lieferantenbeziehung ausschließlich Release-Artefakte und deren Abhängigkeiten — dahinter steht kein betriebener Dienst, dessen Sicherheitslage Sie zusätzlich prüfen müssten. Es wird keine NIS2-Attestierung für Sie gehalten; Compliance ist eine Eigenschaft Ihrer Organisation.
Wie melde ich einen Sicherheitsvorfall mit einer OperativeOps-Bereitstellung?
Die Meldepflicht gemäß Artikel 23 läuft von Ihnen als Einrichtung an Ihr nationales CSIRT oder die zuständige Behörde. Da die Bereitstellung Ihnen gehört, gilt das auch für die Erkennung: (1) Erkennung über den Audit-Ledger und das Monitoring, das Sie daran angebunden haben; (2) Bewertung der Erheblichkeit anhand Ihrer nationalen Umsetzungskriterien; (3) Übermittlung der 24-Stunden-Frühwarnung an Ihre Behörde; (4) Einbindung Ihres Incident-Response-Teams; (5) Übermittlung der 72-Stunden-Meldung; (6) Übermittlung des 1-Monats-Abschlussberichts. Betrifft der Vorfall die Software selbst und nicht ihre Konfiguration, melden Sie ihn bitte, damit er behoben werden kann.
Stellen Sie eine Software-Stückliste (SBOM) bereit?
Fragen Sie vor dem Kauf danach. Eine maschinenlesbare SBOM ist eine berechtigte Erwartung an eine selbstbetriebene Komponente in einer NIS2-Lieferkette — und wir vereinbaren lieber schriftlich, was geliefert wird, als auf dieser Seite Format und Rhythmus zu behaupten, an denen Ihr Prüfer uns anschließend misst. Bis dahin gilt: Der Abhängigkeitsbestand einer selbstbetriebenen Bereitstellung ist in den Artefakten einsehbar, die Sie ausrollen.
Sind Sie ein Managed Security Service Provider (MSSP) gemäß NIS2?
Nein — und der Selbstbetrieb klärt die Frage abschließend: Es wird nichts in Ihrem Auftrag betrieben, also kann OperativeOps kein Managed-Service-Provider im Sinne von NIS2 Anhang I (Abschnitt 8) sein. Es ist Software, die Sie betreiben. Sind Sie selbst ein MSSP, der OperativeOps einsetzt, gelten Ihre eigenen NIS2-Pflichten als wesentliche Einrichtung für Ihre Tätigkeiten, und die Software liegt in Ihrer Lieferkette wie jede andere Komponente, die Sie ausrollen.
Wie wirkt sich der Selbstbetrieb auf unser NIS2-Lieferkettenrisiko aus?
Er verengt die Lieferantenbeziehung auf Software-Artefakte und deren Abhängigkeiten, weil hinter dem Release keine betriebene Laufzeit steht. Das vereinfacht die Lieferkettendokumentation, die Sie zusammentragen müssen: Sie bewerten eine Komponente, die Sie ausrollen, statt Infrastruktur, Personal und Vorfallsprozess eines Anbieters. Der Preis ist, dass Sie sämtliche operativen Kontrollen verantworten — Angriffserkennung, Geschäftskontinuität, Patching und Schlüsselverwaltung —, was reale interne Ressourcen bindet. Der Selbstbetrieb beseitigt keine NIS2-Pflichten; er bündelt sie innerhalb Ihrer eigenen Grenze.