Nachweisbarkeit
NIS2 und Ihre Software: Was Sie im Audit tatsächlich vorlegen müssen.
Die Richtlinie sagt, was Sie schulden. Sie sagt nicht, wie die Software gebaut sein muss, damit Sie es belegen können. Diese Seite übersetzt die Pflichten in Architekturanforderungen — und in das, was am Prüfungstag auf dem Tisch liegt.
Dokumentation haben die meisten. Belegbarkeit nicht.
In fast jedem Gespräch nach einem Audit-Finding hören wir denselben Satz: „Wir haben doch alles dokumentiert.“ Das stimmt meistens auch. Nur fragt ein Prüfer nicht nach der Beschreibung eines Prozesses, sondern nach dem Nachweis, dass er im Einzelfall so gelaufen ist — an einem bestimmten Tag, für einen bestimmten Datensatz, durch eine bestimmte Person.
Diese Frage beantwortet keine Richtlinie und kein Konzeptpapier, sondern das System selbst. Wenn es den Beleg nicht mitliefert, entsteht er in Handarbeit aus Logs, Backups und Erinnerung. Genau dort wird NIS2 teuer — nicht in der Umsetzung der Maßnahmen, sondern in der Wiederbeschaffung von Nachweisen, die nie erzeugt wurden.
Der Anspruch ist dabei nicht neu. Neu ist, dass die Geschäftsleitung persönlich in der Pflicht steht und dass Meldefristen in Stunden gemessen werden. Beides verschiebt die Anforderung von der Organisation in die Architektur.
Von der Pflicht zur Architekturanforderung.
Die linke Spalte steht in der Richtlinie. Die mittlere ist das, was Ihr System dafür können muss. Die rechte ist das, was Sie im Prüfungsfall vorlegen.
| Pflicht aus NIS2 | Was das System können muss | Was Sie vorlegen |
|---|---|---|
| Risikomanagement und Wirksamkeit der Maßnahmen (Art. 21) | Sicherheitsrelevante Zustandsänderungen werden als fachliche Ereignisse erfasst, nicht nur als technisches Log. | Lückenlose, zeitlich geordnete Historie der sicherheitsrelevanten Vorgänge — maschinell auswertbar statt als Screenshot. |
| Meldepflicht: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden (Art. 23) | Betroffenheit lässt sich innerhalb von Stunden eingrenzen: welche Mandanten, welche Datensätze, welcher Zeitraum. | Eine rekonstruierbare Antwort auf „wer war betroffen und ab wann“ — abgeleitet aus der Historie, nicht geschätzt. |
| Zugriffskontrolle und Identitätsmanagement (Art. 21 Abs. 2) | Rollen, Rechte und deren Änderungen sind versioniert und einem Verantwortlichen zugeordnet. | Wer hatte wann welche Berechtigung, wer hat sie erteilt und aufgrund welcher Freigabe. |
| Sicherheit in Beschaffung, Entwicklung und Wartung | Änderungen an Code, Konfiguration und Berechtigungen sind derselben Nachweiskette unterworfen wie fachliche Daten. | Herkunft jeder Änderung: Auslöser, Freigabe, Zeitpunkt, ausgerollte Version. |
| Lieferkettensicherheit | Abhängigkeiten und deren Zugriffe auf Ihre Daten sind explizit modelliert, nicht implizit über Netzwerkzugang geregelt. | Nachweis, welcher Dienstleister und welches Fremdsystem wann auf welche Daten zugegriffen hat. |
| Verantwortung und Aufsicht der Leitungsebene (Art. 20) | Die Lage lässt sich ohne Entwicklerhilfe abfragen — Auswertungen sind Teil des Systems. | Regelmäßiger, aus dem System erzeugter Nachweis statt einer manuell gepflegten Tabelle. |
Die Zuordnung ist unsere Umsetzungssicht, keine Rechtsberatung. Welche Pflichten Sie treffen, hängt von Sektor, Größe und dem nationalen Umsetzungsgesetz ab — in Österreich und Deutschland unterschiedlich ausgestaltet.
Die vier Lücken, die wir regelmäßig finden.
Nicht bei schlechten Teams. Bei Systemen, die vor der Nachweispflicht entstanden sind.
Logs, die jeder ändern kann
Protokolliert wird in dieselbe Datenbank, in der auch die Fachdaten liegen, mit Schreibrechten für den Anwendungsbenutzer. Technisch sauber, als Nachweis wertlos: Ein Prüfer akzeptiert keine Historie, die dieselbe Instanz nachträglich verändern kann.
Zustand ohne Begründung
Die Tabelle sagt, dass ein Datensatz freigegeben ist. Sie sagt nicht, wer freigegeben hat, wann und auf welcher Grundlage. Für den Betrieb reicht das. Für die Frage nach dem Stichtag nicht.
Mandantentrennung als Filterbedingung
Die Isolation entsteht durch eine WHERE-Klausel im Code. Ein einziger vergessener Filter ist ein meldepflichtiger Vorfall — und der Nachweis der Trennung ist ein Code-Review, kein Beleg.
Berechtigungen ohne Historie
Das aktuelle Rechtemodell ist bekannt. Das von vor acht Monaten nicht mehr. Genau danach wird nach einem Vorfall gefragt.
Wie wir die Lücke schließen.
Nicht als Gesamtumbau. Am Prozess, an dem es im Ernstfall weh tut.
1 — Bestandsaufnahme der Nachweisfähigkeit
Wir gehen die konkreten Fragen durch, die ein Prüfer oder ein Großkunde stellt, und markieren, welche Ihr System heute beantwortet und welche nicht. Ergebnis ist eine Liste mit Aufwand und Risiko je Lücke — keine Präsentation.
2 — Der kritischste Schnitt zuerst
Ein Prozess bekommt eine unveränderliche Historie und ein sauberes Rechtemodell. Klein genug, um in Wochen produktiv zu sein, groß genug, um im Audit zu zählen.
3 — Identität und Mandantentrennung belegbar machen
Berechtigungen werden versioniert, Isolation wird technisch statt per Filter durchgesetzt — mit Keycloak, wenn Souveränität über die Identität gefordert ist.
4 — Übergabe mit Namen drauf
Am Ende steht jemand intern dafür gerade. Wir dokumentieren nicht für uns, sondern für die Person, die die nächste Prüfung ohne uns übersteht.
Wann das passt — und wann nicht.
Passt, wenn
- ein Audit-Finding offen ist, das intern nicht sauber geschlossen werden kann
- ein Großkunde Mandantentrennung, SSO und Audit-Trails verlangt
- ein Vorfall gezeigt hat, dass die Historie nicht belastbar ist
- ein neues Fachsystem entsteht und die Nachweispflicht von Anfang an mitgedacht werden soll
Passt nicht, wenn
- Sie eine Zertifizierung oder ein Gutachten brauchen — dafür gibt es Auditoren, nicht uns
- Sie Rechtsberatung zur Betroffenheit suchen
- es keinen Auslöser gibt und nur „Modernisierung“ im Raum steht
- reine Entwicklungskapazität zum Stundensatz gesucht wird
Häufige Fragen
- Reicht ein revisionssicheres Logging-Tool nicht aus?
- Für Infrastrukturereignisse oft ja. Für fachliche Fragen selten: Ein Logeintrag sagt, dass ein Update ausgeführt wurde, nicht, dass eine Kreditprüfung übersprungen wurde. Nachweisbar wird es, wenn die fachliche Entscheidung selbst als Ereignis festgehalten ist.
- Müssen wir dafür das ganze System neu bauen?
- Nein, und wir raten meistens davon ab. Nachweisbarkeit lohnt sich dort, wo die Fragen gestellt werden — in der Regel ein bis drei Prozesse. Der Rest bleibt, wie er ist.
- Was hat Event Sourcing mit NIS2 zu tun?
- Als Muster nichts. Als Antwort auf die Frage „können Sie unveränderlich belegen, wer wann was geändert hat“ ist es die naheliegendste Bauform. Es gibt einfachere Wege, und wir sagen auch, wann sie reichen.
- Wie lange dauert eine Bestandsaufnahme?
- Zwei bis vier Wochen, abhängig davon, wie viele Systeme am betroffenen Prozess hängen. Ergebnis ist eine priorisierte Lückenliste, mit der Sie auch ohne uns weiterarbeiten können.
- Beraten Sie zur Betroffenheit nach NIS2?
- Nein. Ob Sie unter die Richtlinie fallen, klärt Ihre Rechtsberatung oder die zuständige Behörde. Wir setzen an, wenn feststeht, dass Nachweise gefordert sind.
Quellen
Wir zitieren die konsolidierten Rechtstexte, damit Sie jede Aussage selbst prüfen können.
Wissen Sie, welche dieser Fragen Ihr System heute beantwortet?
Der Nachweisfähigkeits-Check geht in zehn Fragen durch, was ein Prüfer wissen will. Zehn Minuten, keine Anmeldung, Ergebnis sofort.