Der minimale Policy-Stack für kleine Einrichtungen

Der Leitfaden hat Ihnen die Bausteine genannt: IS-Policy mit Mindestinhalt, sieben Unterrichtlinien nach § 30 Abs. 2 BSIG, Verantwortliche, Gültigkeitsdaten, GF-Genehmigung, jährlicher Review. Was er nicht erklärt: warum die meisten Erstentwürfe trotzdem vier Schwachstellen enthalten, welcher Pitfall je Unterrichtlinie am häufigsten Prüfungsbefunde erzeugt, und wie eine GF-Genehmigung strukturiert sein muss, damit sie auch nach einem BSI-Prüfer-Besuch standhält. Darum geht es in diesem Artikel.

Schritt 1: IS-Policy – die vier Stellen, an denen Erstentwürfe scheitern

Die IS-Policy ist das erste Dokument, das ein BSI-Prüfer anfordert. Dass sie existiert, reicht nicht. Ihr Inhalt entscheidet, ob § 30 Abs. 2 Nr. 1 BSIG als erfüllt gilt. Vier Fehler tauchen in den meisten Erstentwürfen auf – oft gleichzeitig.

Fehler 1: Keine Risikoakzeptanzkriterien

Die Risikoakzeptanzkriterien – auch Risikoappetit – legen fest, bis zu welchem Niveau Ihre Organisation Risiken toleriert, ohne sie aktiv zu mitigieren. Fehlt dieser Abschnitt, hängen alle Unterrichtlinien in der Luft: Eine Zugangskontrollrichtlinie, die das Least-Privilege-Prinzip fordert, ist ohne definierten Akzeptanzschwellenwert nicht logisch begründbar. Ein BSI-Prüfer, der nach der Herleitung Ihrer Sicherheitsentscheidungen fragt, braucht genau diese Definition als Fundament.

Das Minimum für eine kleine Einrichtung sind drei Akzeptanzniveaus mit klaren Kriterien. Beispiel: "Risiken mit geringer Eintrittswahrscheinlichkeit und begrenzten Auswirkungen auf den Geschäftsbetrieb werden akzeptiert. Risiken mit mittlerer Wahrscheinlichkeit oder erheblichen Auswirkungen werden durch Maßnahmen aus dem Sicherheitsplan mitigiert. Risiken mit hoher Wahrscheinlichkeit oder kritischen Auswirkungen werden auf das mittlere Niveau reduziert oder führen zur Einstellung des betroffenen Prozesses." Verweisen Sie für die Operationalisierung auf Ihre Risikoanalyse.

Fehler 2: Management-Bekenntnis als Absichtserklärung

"Die Geschäftsführung bekennt sich zur Informationssicherheit und unterstützt alle damit verbundenen Maßnahmen." Dieser Satz steht in vielen IS-Policies und gibt einem BSI-Prüfer keine verwertbare Information. § 38 BSIG verlangt keine Absichtserklärung – er verlangt, dass das Leitungsorgan Maßnahmen nach § 30 BSIG aktiv billigt und deren Umsetzung überwacht.

Ein ausreichendes Management-Bekenntnis enthält drei konkrete Elemente: die namentliche Benennung des ISB mit Funktion, eine Ressourcenzusage (als Budgetlinie oder prozentuale Freistellung) und die explizite Aussage, dass die Unterrichtlinien für das gesamte Unternehmen verbindlich sind und Verstöße Konsequenzen haben. Der Satz "Frau Müller ist als ISB bestellt und mit 20 % ihrer Arbeitszeit sowie einem Jahresbudget für Sicherheitsmaßnahmen ausgestattet" erfüllt das Kriterium. "Die Unterrichtlinien sind verbindlich" allein nicht.

Fehler 3: Geltungsbereich ohne Cloud

"Diese Richtlinie gilt für alle IT-Systeme des Unternehmens" klingt vollständig – schließt aber Cloud-Dienste, SaaS-Anwendungen und externe Dienstleister mit Systemzugang häufig implizit aus, weil diese aus Nutzersicht nicht als "IT-Systeme des Unternehmens" wahrgenommen werden. Formulieren Sie den Geltungsbereich explizit: "Diese Richtlinie gilt für alle Informationssysteme, Netzwerke und Daten der [Einrichtung], einschließlich aller cloudbasierten Dienste, SaaS-Anwendungen, externer Dienstleister mit Zugang zu unternehmenseigenen Systemen oder Daten sowie privater Endgeräte, die im Rahmen von BYOD-Regelungen eingesetzt werden."

Wenn Ausnahmen existieren – etwa Systeme einer Tochtergesellschaft oder separate regulatorische Umgebungen – benennen Sie diese explizit als ausgenommen. Was nicht explizit ausgenommen ist, fällt unter die Richtlinie. Nicht umgekehrt.

Fehler 4: Kein datierbarer Genehmigungsakt

Das Datum der GF-Unterschrift ist der rechtliche Ankerpunkt: Ab diesem Datum gilt die Richtlinie als eingeführt. Wenn ein Prüfer fragt "Seit wann betreiben Sie eine dokumentierte Informationssicherheitspolitik?", ist die Antwort das GF-Unterschriftsdatum – nicht das Datum der Datei-Erstellung oder der internen Fertigstellung. Das bedeutet: Die Genehmigung muss ein tatsächliches, nachvollziehbares Ereignis sein. Eine Unterschrift im Meeting, eine protokollierte Sitzung, eine E-Mail mit explizitem Bezug auf Dokumentname und Version. Dieses Datum steht im Dokument, und es stimmt mit dem tatsächlichen Genehmigungsakt überein.

Ergebnis dieses Schritts: IS-Policy mit Geltungsbereich (inkl. Cloud), Risikoakzeptanzkriterien, Management-Bekenntnis mit namentlichem ISB und Ressourcenzusage, Verweis auf alle Unterrichtlinien und Unterschriftenfeld mit echtem GF-Datum.

Schritt 2: Die sieben Kernrichtlinien – was "minimal" bedeutet und der kritische Pitfall je Richtlinie

Jede der sieben Unterrichtlinien ist der dokumentarische Nachweis dafür, dass eine konkrete Maßnahme nach § 30 Abs. 2 BSIG in Ihrer Organisation verankert ist. Ohne die Richtlinie können Sie eine implementierte Maßnahme nicht belegen – nicht weil die Maßnahme nicht existiert, sondern weil kein Regelwerk vorhanden ist, auf das ein Prüfer verweisen kann.

Die §-Zuordnung im Überblick:

• Zugriffskontrollrichtlinie → § 30 Abs. 2 Nr. 9 BSIG
• Patch-Management-Richtlinie → § 30 Abs. 2 Nr. 6 BSIG
• Kryptographierichtlinie → § 30 Abs. 2 Nr. 8 BSIG
• Incident-Response-Richtlinie → § 30 Abs. 2 Nr. 2 BSIG
• Backup- und Wiederherstellungsrichtlinie → § 30 Abs. 2 Nr. 3 BSIG
• Lieferantensicherheitsrichtlinie → § 30 Abs. 2 Nr. 4 BSIG
• Nutzungsrichtlinie / Acceptable Use Policy (inkl. BYOD- und Passwortregeln) → § 30 Abs. 2 Nr. 7 BSIG

"Minimal sufficient" heißt nicht wenige Seiten – es heißt: Die Richtlinie definiert eine konkrete Regel, einen namentlich verantwortlichen Eigentümer und eine Konsequenz bei Nichtbefolgung. Eine zweiseitige Richtlinie, die das leistet, ist prüfungsrelevanter als eine 15-seitige, die es nicht tut. Im Folgenden je Richtlinie der Pitfall, der am häufigsten Prüfungsbefunde erzeugt.

1. Zugriffskontrollrichtlinie (§ 30 Abs. 2 Nr. 9 BSIG)

Der häufigste Pitfall: "MFA ist für alle kritischen Systeme verpflichtend." Was sind kritische Systeme? Ohne eine Liste oder ein Klassifizierungskriterium im Dokument entscheidet jeder Administrator selbst – was die MFA-Pflicht de facto aufhebt. Formulieren Sie systembezogen: "MFA ist verpflichtend für alle Admin-Konten, alle Fernzugangssysteme (VPN, RDP), alle Cloud-Dienste mit Zugang zu internen Daten und alle E-Mail-Konten." Ebenso zwingend: eine messbare Offboarding-Frist. "Konten ehemaliger Mitarbeitender werden innerhalb von 24 Stunden nach Austritt deaktiviert" ist prüfbar. "Zeitnah" ist es nicht.

2. Patch-Management-Richtlinie (§ 30 Abs. 2 Nr. 6 BSIG)

Der häufigste Pitfall: Die Patch-Fristen sind definiert, aber als Ziel des IT-Dienstleisters – nicht als verbindliche Anforderung der eigenen Richtlinie. Wenn Ihr externer IT-Dienstleister das Patch-Management übernimmt, müssen seine SLA-Fristen explizit in Ihrer Richtlinie stehen und vertraglich abgesichert sein. "Kritische Patches werden innerhalb von 72 Stunden nach Verfügbarkeit eingespielt – sofern kein genehmigtes Ausnahmedokument vorliegt" ist die korrekte Formulierung. Ohne diese Übernahme der Verantwortung in die eigene Richtlinie fehlt Ihnen der § 30-Nachweis, selbst wenn der Dienstleister pünktlich patcht.

3. Kryptographierichtlinie (§ 30 Abs. 2 Nr. 8 BSIG)

Der häufigste Pitfall: Die zugelassenen Algorithmen sind aufgelistet – AES-256, RSA-3072+, TLS 1.2 minimum – aber niemand ist namentlich für das Schlüsselmanagement verantwortlich. Bei Schlüsselverlust oder Kompromittierung fehlt die Eskalationslinie. Benennen Sie explizit: wer verwaltet Zertifikate, wer genehmigt Ausnahmen bei der Algorithmenauswahl, wer ist bei Schlüsselkompromittierung die erste Anlaufstelle. Schlüsselverlust = Sicherheitsvorfall muss als solcher in der Richtlinie stehen.

4. Incident-Response-Richtlinie (§ 30 Abs. 2 Nr. 2 BSIG)

Der häufigste Pitfall: Die Eskalationskette endet bei "ISB benachrichtigen" ohne Kontaktdaten im Dokument selbst. Im Ernstfall – Ransomware-Angriff um 3 Uhr morgens – wird kein Mitarbeiter das Intranet durchsuchen, um die Telefonnummer des ISB zu finden. Primäre und Fallback-Kontaktdaten (Telefon, E-Mail) müssen in der Richtlinie stehen. Dasselbe gilt für externe Stellen: BSI-Meldestelle MELDIS, externe Forensikfirma falls vertraglich vereinbart, rechtliche Anlaufstelle. Die 24-Stunden-Erstmeldepflicht nach § 35 BSIG muss explizit als Frist in der Richtlinie stehen – nicht im IR-Plan vergraben, der möglicherweise nicht bekannt ist.

5. Backup- und Wiederherstellungsrichtlinie (§ 30 Abs. 2 Nr. 3 BSIG)

Der häufigste Pitfall: Backup-Frequenz und Aufbewahrungsfristen sind definiert, aber keine Testpflicht. Das BSI betrachtet ein Backup ohne Wiederherstellungstest als unvollständige Maßnahme. Schreiben Sie explizit: "Vierteljährlicher Test der Wiederherstellung eines definierten Datensatzes, jährlicher Volltest. Testergebnisse werden dokumentiert. Bei Nichtbestehen eines Tests ist innerhalb von 14 Tagen eine Nachtest-Pflicht einzuhalten." Ohne diese Testpflicht in der Richtlinie ist die Backup-Implementierung prüfungstechnisch nicht nachweisbar.

6. Lieferantensicherheitsrichtlinie (§ 30 Abs. 2 Nr. 4 BSIG)

Der häufigste Pitfall: Die Richtlinie gilt für "wichtige Lieferanten", ohne zu definieren, was das bedeutet. Wenn ein Prüfer fragt "Welche Ihrer Lieferanten fallen unter diese Richtlinie?", sollte die Antwort aus dem Dokument ableitbar sein. Definieren Sie Tier-1-Kriterien: Lieferanten mit direktem Zugang zu produktionskritischen Systemen oder zu sensiblen Daten, ohne die der Geschäftsbetrieb innerhalb von 24 Stunden nicht aufrechtzuerhalten ist. Diese Lieferanten unterliegen einer jährlichen Sicherheitsbewertung und einer vertraglichen Meldepflicht bei Sicherheitsvorfällen. Die Tier-Klassifizierung muss nicht in der Richtlinie selbst stehen – sie muss auf eine dokumentierte Klassifizierungslogik verweisen.

7. Nutzungsrichtlinie / Acceptable Use Policy (§ 30 Abs. 2 Nr. 7 BSIG, inkl. BYOD und Passwortregeln)

Zwei Pitfalls in einer Richtlinie. Erstens BYOD: "Private Geräte sind unter bestimmten Bedingungen erlaubt" ohne Definition dieser Bedingungen ist nicht durchsetzbar. Entweder BYOD ist nicht erlaubt – dann steht das klar im Dokument – oder BYOD ist erlaubt mit MDM-Pflicht, Datentrennung (Container-Ansatz), Remote-Wipe-Berechtigung der IT und Bildschirmsperre nach maximal 5 Minuten. Jede Mittelposition ohne diese technischen Anforderungen ist eine Richtlinie ohne Durchsetzungsmechanismus.

Zweitens Passwortregeln: Ein erzwungener Passwortwechsel alle 90 Tage steht im Widerspruch zur BSI-Empfehlung seit 2021. Das BSI empfiehlt keinen turnusmäßigen Zwangswechsel mehr – ausgenommen bei konkretem Kompromittierungsverdacht. Eine Richtlinie, die auf veraltetem Sicherheitswissen basiert, signalisiert einem Prüfer, dass kein aktueller Review stattgefunden hat. Aktuelle Formulierung: "Passwortwechsel ist unverzüglich bei Kompromittierungsverdacht oder auf Anforderung des ISB erforderlich – kein turnusmäßiger Zwangswechsel."

Ergebnis dieses Schritts: Sieben Richtlinien von je ein bis vier Seiten, jede mit einer eindeutigen Regel, einem namentlichen Verantwortlichen und einer Konsequenzregelung.

Schritt 3: Das Policy-Register – das Dokument, das Audits rettet

Der Leitfaden weist an, für jede Richtlinie Verantwortliche und Review-Datum festzulegen. Ein Policy-Register hält das auf einer Seite zusammen – als Arbeitsunterlage für Sie und als erste Antwort für einen Prüfer auf die Frage "Zeigen Sie mir Ihre Policy-Governance." Das Register enthält je Richtlinie fünf Felder: Name der Richtlinie, Verantwortlicher (Name, nicht Funktion), aktuelle Version, Datum der letzten Genehmigung, Datum des nächsten Reviews.

Eigentümerschaft: ISB als Owner aller Richtlinien ist ein Warnsignal

Wenn der ISB alle acht Richtlinien verantwortet, zeigt das einem Prüfer, dass keine Linienverwantwortung für Sicherheitsthemen existiert. Eine sinnvollere Verteilung: Der IT-Leiter verantwortet die Zugriffskontroll- und die Patch-Management-Richtlinie, weil er die operativen Entscheidungen trifft und im Prüfgespräch zur Implementierung Auskunft geben kann. Der ISB verantwortet Kryptographie-, IR- und Backup-Richtlinie. Lieferantensicherheit liegt bei ISB und Einkauf gemeinsam. Die Nutzungsrichtlinie liegt bei ISB und HR gemeinsam. Diese Verteilung ist kein Formalismus – sie klärt, wer bei Prüfungsfragen sachkundig antworten kann.

Überfällige Reviews: schlechter als kein Register

Ein Policy-Register mit einem Review-Datum in der Vergangenheit ist aktiv schlechter als gar kein Register – es dokumentiert eine versäumte Pflicht. Wenn Sie das Register erstellen und ein Review-Datum bereits abgelaufen ist, gibt es zwei akzeptable Reaktionen: Entweder holen Sie den Review sofort nach, oder Sie dokumentieren den Verzögerungsgrund und setzen ein verbindliches neues Datum. Ein altes Datum unverändert stehen zu lassen ist in keinem Prüfkontext vertretbar.

Die vier Auslöser für sofortigen Ad-hoc-Review

Außer dem jährlichen Rhythmus gibt es vier Ereignisse, die einen sofortigen Review der betroffenen Richtlinie erfordern: eine regulatorische Änderung, die den Richtlinienbereich direkt betrifft; ein Sicherheitsvorfall, der eine Lücke in einer bestehenden Richtlinie offengelegt hat; eine wesentliche Systemänderung, die eine Regel technisch nicht mehr durchsetzbar macht; und ein Prüfungsbefund, der eine konkrete Richtlinie referenziert. Bei diesen vier Auslösern reicht der jährliche Kalendertermin nicht.

Ergebnis dieses Schritts: Policy-Register – eine Seite, acht Zeilen, fünf Spalten. Jede Richtlinie, jeder Owner, jede Version auf einem Blick.

Schritt 4: GF-Genehmigung – das Gespräch vorbereiten und die richtige Form wählen

Das häufigste Problem: Der ISB schickt die acht Dokumente per E-Mail an die GF mit dem Hinweis "bitte kurz gegenlesen und genehmigen." Ergebnis: Eine Antwortmail "sieht gut aus, machen Sie das so" – ohne Dokumentreferenz, ohne Versionsnummer, ohne Datum. Das ist keine prüfungssichere Genehmigung.

Was eine gültige Genehmigung erfordert: einen eindeutigen Bezug auf das Dokument (Name und Version), ein Datum und eine Unterschrift oder ein digital nachvollziehbares Äquivalent. Eine E-Mail-Genehmigung ist möglich, wenn sie explizit lautet: "Ich genehmige IS-Policy Version 1.0 und die sieben Unterrichtlinien in den Versionen 1.0 vom [Datum]." Diese E-Mail wird archiviert und ist der Genehmigungsnachweis. Eine undatierte E-Mail oder eine ohne Dokumentreferenz genügt nicht.

Für die erste Genehmigung empfiehlt sich ein 30-minütiger Termin – nicht wegen der Dauer, sondern wegen der Fragen. Wenn die GF die IS-Policy zum ersten Mal sieht, sind Rückfragen zu erwarten. Diese Fragen sind ein Zeichen dafür, dass die GF den Inhalt versteht – was § 38 BSIG unter "aktiver Billigung" versteht. Zukünftige Jahres-Reviews können per E-Mail mit korrekter Formulierung erfolgen, sobald der Rahmen etabliert ist.

Die drei Sätze für das GF-Gespräch: "Dieses Dokumentenpaket ist der schriftliche Nachweis, dass Sie die Informationssicherheit unserer Einrichtung aktiv steuern – § 38 BSIG macht Sie als Leitungsorgan persönlich verantwortlich. Es ändert nichts am Tagesgeschäft, das bleibt beim ISB. Was es ändert: Im Prüffall haben Sie einen datierten Genehmigungsnachweis statt einer mündlichen Aussage."

Wann brauchen Unterrichtlinien erneute GF-Genehmigung: Bei Minor-Änderungen – Tippfehlerkorrekturen, aktualisierte Kontaktdaten, präzisierte Formulierungen ohne Regeländerung – reicht eine ISB-Genehmigung, dokumentiert mit neuer Versionsnummer. Bei Major-Änderungen – erweiterter Geltungsbereich, neue Regeln, geänderte Verantwortlichkeiten – ist GF-Genehmigung erforderlich. Wenn jede Kleinigkeit GF-Genehmigung erfordert, hört die GF auf, die Dokumente zu lesen. Das ist das Ende eines funktionierenden Policy-Prozesses.

Schritt 5: Versionskontrolle ohne DMS – was BSI tatsächlich prüft

Die meisten kleinen Einrichtungen haben kein DMS. Ein SharePoint-Ordner oder ein Dateiserver-Verzeichnis reicht – unter vier Bedingungen, die gemeinsam Unveränderbarkeit und Nachvollziehbarkeit sichern.

• Schreibschutz für alle außer ISB und IT-Administrator: Wenn jeder Mitarbeiter Richtlinien bearbeiten kann, können Sie nicht nachweisen, dass die genehmigte Version unverändert ist. Der Ordner "Richtlinien/Aktuell" ist für alle lesbar, aber nur für den ISB und einen definierten Admin beschreibbar.
• Dateinamen mit Versionsnummer und Datum: "IS-Policy_v1.0_2026-03-03_genehmigt.pdf" – nicht "IS-Policy-final.pdf" oder "IS-Policy-neu.pdf". Der Dateiname ist der erste Anhaltspunkt für einen Prüfer und muss den Genehmigungs-Stand eindeutig ausdrücken.
• Änderungshistorie im Dokument selbst: Ein dreispaltiger Abschnitt am Ende jeder Richtlinie: Datum | Version | Änderung. Diese Tabelle gehört zum Dokument – nicht in eine separate Datei, die möglicherweise nicht mitgeschickt wird, wenn jemand "die aktuelle Richtlinie" anfragt.
• Archivordner für ältere Versionen: Alte Versionen werden nicht gelöscht, sondern in einen Unterordner "Archiv" verschoben. Ein BSI-Prüfer kann fragen, wie sich eine Richtlinie über Zeit entwickelt hat – die Antwort muss aus dem Archiv abrufbar sein.

Die MAJOR.MINOR-Regel bestimmt, wann welche Version ausgelöst wird. Minor-Versionen (1.0 → 1.1) sind Korrekturen ohne Regeländerung – keine GF-Genehmigung nötig. Major-Versionen (1.x → 2.0) bedeuten geänderte Regeln, geänderter Geltungsbereich oder geänderte Verantwortlichkeiten – immer GF-Genehmigung erforderlich. Diese Schwellendefinition muss schriftlich festgelegt sein, damit nicht jedes Mal situativ entschieden wird.

Die empfohlene Ordnerstruktur – aufbauend auf dem Archivierungssystem aus Schritt 5-4 (Management-Security-Reporting): NIS2-Governance/Richtlinien/Aktuell/ für alle acht genehmigten Dokumente; NIS2-Governance/Richtlinien/Archiv/ für ältere Versionen mit Datum im Dateinamen; NIS2-Governance/Policy-Register.pdf für das aktuelle Register.

Was das BSI bei einer Prüfung tatsächlich sieht: Ein Prüfer öffnet den Ordner, findet acht PDF-Dateien mit lesbaren Namen und Versionsdaten, öffnet eine davon und findet die Änderungshistorie am Ende des Dokuments. Das ist ausreichend. Kein aufwändiges DMS, keine Blockchain-Signatur – aktive Verwaltung, die sich aus den Dokumenten selbst belegen lässt.

Was Sie jetzt haben

Nach diesen fünf Schritten haben Sie fünf konkrete Artefakte:

1. IS-Policy (2–4 Seiten, GF-genehmigt) mit explizitem Geltungsbereich, Risikoakzeptanzkriterien, namentlichem ISB und Ressourcenzusage im Management-Bekenntnis
2. Sieben Unterrichtlinien (je 1–4 Seiten), jede mit einer eindeutigen Regel, einem benannten Eigentümer und einer Konsequenzregelung
3. Policy-Register (1 Seite) mit Owner, Version, Genehmigungsdatum und nächstem Review-Datum je Richtlinie
4. GF-Genehmigungsnachweis – Unterschriften auf Deckblättern oder E-Mail-Protokoll mit Dokumentreferenz, Versionsnummer und Datum
5. Versionierungsregel (MAJOR.MINOR-Definition) und Ordnerstruktur, die einen BSI-Prüfer ohne Erläuterung durch die Dokumente führt

Dieser Policy-Stack ist Ihr primärer Nachweis nach § 30 Abs. 2 Nr. 1 BSIG. Für das regelmäßige Management-Reporting über den Status dieses Stacks – also wie Sie quartalsweise belegen, dass die Richtlinien aktiv gelebt werden – lesen Sie Schritt 5-4 (Management-Security-Reporting für NIS2).

Dieser Artikel ersetzt keine Rechtsberatung. Die Ausführungen geben eine praxisorientierte Einordnung der NIS2-Anforderungen aus Sicht eines IT-Sicherheitsberaters, begründen aber keine rechtliche Beratungsleistung. Für rechtliche Fragen zu Ihrer spezifischen Situation ziehen Sie einen Rechtsanwalt hinzu.