Zum Hauptinhalt
Wissen · 13.10.2026 · Matthias Hinner

NIS2 und die eigene Website: Was Betreiber nachweisen müssen

Fällt eine Organisation unter NIS2, gehört auch die Website zu den Systemen, für die sie Sicherheit nachweisen muss. Matthias Hinner erzählt, warum dabei selten die Technik das Problem ist, was wir beim Aufbau unseres eigenen Managementsystems für Informationssicherheit gelernt haben und welche Nachweise Sie für Ihre Website brauchen.

Eine Liste mit Fragen

Vor einiger Zeit schickten uns Kunden aus der Logistik und aus dem Finanzbereich Listen mit Fragen. Wie schnell spielen Sie Sicherheitsupdates ein? Wer hat Zugriff auf unsere Systeme? Wie würden Sie uns über einen Vorfall informieren, und innerhalb welcher Frist?

Technisch konnten wir jede Frage sofort beantworten. Die Updates liefen, die Zugänge waren geregelt, die Backups vorhanden. Schwierig war etwas anderes: zu zeigen, dass es so ist. Die Antworten lagen verteilt in Tickets, Server-Logs und im Kopf einzelner Kolleginnen und Kollegen. Für eine Prüfung ist das zu wenig, und ehrlich gesagt war es auch uns zu wenig.

Was NIS2 von Website-Betreibern verlangt

Die NIS2-Richtlinie verpflichtet die Organisation selbst, nicht ihre Dienstleister. Sie verlangt aber ausdrücklich, die Sicherheit der Lieferkette in das Risikomanagement aufzunehmen. Wird die Website von einer Agentur entwickelt und betrieben, gehört diese Agentur zur Lieferkette, ebenso das Rechenzentrum und jede eingesetzte Erweiterung.

Für Sie heißt das: Ihre Unterlagen müssen auch abdecken, was Ihr Dienstleister tut. Die technischen und organisatorischen Maßnahmen, der Vertrag zur Auftragsverarbeitung und ein abgestimmter Meldeweg sind die Grundlage. Kommt es zu einem erheblichen Vorfall, laufen die Fristen schnell: eine Frühwarnung binnen 24 Stunden, die Meldung binnen 72 Stunden und ein Abschlussbericht binnen eines Monats (Artikel 23 der NIS2-Richtlinie  (externer Link)). Das schafft nur, wer vorher weiß, wer wen anruft.

Das NISG 2026 in Österreich

In Österreich setzt das Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026, BGBl. I Nr. 94/2025)  (externer Link) die Richtlinie um. Es ist seit 1. Oktober 2026 in Kraft, und betroffene Einrichtungen müssen sich innerhalb von drei Monaten registrieren, also bis Ende 2026 (§ 29 Abs. 3). Welche Organisationen darunter fallen, hängt von Branche und Größe ab. Für viele Organisationen wird mit der Registrierung aus einer abstrakten Richtlinie eine konkrete Aufgabe.

Unser eigener Weg

Die Fragen unseres Kunden waren für uns der Anlass, Informationssicherheit nicht nur zu betreiben, sondern nachweisbar zu machen. Wir bauen seither ein Managementsystem für Informationssicherheit nach ISO 27001 auf. Das klingt nach Papier, und am Anfang ist es das auch. Aber hinter jeder Richtlinie steckt eine sehr praktische Frage.

Sicherheitsupdates spielen wir nach Schweregrad ein, und jede Änderung landet in einem Protokoll. Zugänge sind persönlich: Ins Backend dieser Website kommen wir nur noch über die zentrale Anmeldung unseres Teams, ein geteiltes Admin-Konto gibt es nicht. Für Backups haben wir festgeschrieben, dass sie regelmäßig probeweise zurückgespielt werden, und für Vorfälle gibt es einen festgelegten Ablauf mit Ansprechpersonen und Fristen. Vieles davon haben wir vorher auch schon gemacht. Der Unterschied ist, dass wir es heute zeigen können.

Drei Lücken, die wir oft sehen

Seit wir selbst so arbeiten, fällt uns bei anderen Websites immer wieder dasselbe auf. Die häufigste Lücke ist nicht technisch: Die Website wird gepflegt, aber niemand kann sagen, wann die letzte Sicherheitslücke geschlossen wurde. Dabei genügt ein Protokoll aus dem Deployment oder dem Ticketsystem, es muss nur geführt werden.

Die zweite ist das geteilte Admin-Konto. Für drei Personen ist es bequem, im Ernstfall weiß aber niemand, wer was getan hat. Persönliche Zugänge mit Zwei-Faktor-Anmeldung kosten wenig und schließen diese Lücke. Die dritte sind Backups, die nie geprobt wurden. Gesichert wird täglich, zurückgespielt noch nie. Erst eine Testwiederherstellung zeigt, ob das Backup im Ernstfall hält und wie lange der Wiederanlauf dauert.

Was Sie daraus mitnehmen können

Wenn Ihre Organisation unter NIS2 fällt, beginnen Sie nicht mit der Technik, sondern mit der Frage, was Sie heute belegen können. Fragen Sie Ihre Agentur nach ihren technischen und organisatorischen Maßnahmen, nach dem Protokoll der letzten Updates und nach dem Meldeweg bei einem Vorfall. Wer gut arbeitet, hat diese Antworten parat und schickt sie gerne vorab.

Die Checkliste unten zeigt, welche Nachweise für den Betrieb einer Website vorliegen sollten. Ob und wie Ihre Organisation unter NIS2 fällt, klären Sie mit Ihrer Rechtsberatung. Für Schulungen und Beratung im Unternehmen empfehlen wir unsere Schwestermarke Earlybird  (externer Link, öffnet in neuem Tab) im selben Haus.

Auf einen Blick: Nachweise für den Website-Betrieb

BereichWas vorliegen sollte
UpdatesEine Update-Policy mit Fristen nach Schweregrad und ein Protokoll, wann welche Version eingespielt wurde
AbhängigkeitenEine aktuelle Liste der Extensions und Pakete sowie die regelmäßige Prüfung auf bekannte Schwachstellen
ZugriffeEine Übersicht der Backend- und Serverzugänge, Zwei-Faktor-Anmeldung, ein geregeltes Vorgehen beim Austritt von Personen
BackupsEin Sicherungsplan und das Protokoll einer erfolgreichen Testwiederherstellung
VorfälleEine Meldekette mit Ansprechpersonen beim Dienstleister, abgestimmt auf die Fristen: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats
DienstleisterTOMs, Vertrag zur Auftragsverarbeitung und eine Liste der Subunternehmer
VerschlüsselungTLS für jede Verbindung und eine verschlüsselte Ablage von Zugangsdaten

Über den Autor

Porträt von Matthias Hinner

Matthias Hinner

Kundenbetreuung

Matthias Hinner kümmert sich bei TYPOHEADS um Kundenbetreuung und Informationssicherheit.

Ihre Nachweise für den TYPO3-Betrieb