Informationssicherheitsrichtlinie 2026: ein Leitungsdokument, das das System steuern muss

Was eine Richtlinie ist und was nicht

Diese Unterscheidung verhindert einen häufigen Fehler: ein Dokument zu schreiben, das angeblich "KRI, KSC, NIS2, DSGVO und ISO erfüllt". Diese Regime haben unterschiedliche Anwendungsbereiche und Rechtscharaktere. Eine gut konzipierte Richtlinie kann gemeinsames Element des Managementsystems sein, Compliance muss aber gegenüber jedem anwendbaren Kriterium separat nachgewiesen werden.

Im Sicherheitsumfeld bezeichnet "Policy" sowohl eine Managementerklärung als auch technische Systemeinstellungen. Im ISMS sollte die oberste Richtlinie strategisch bleiben. Sie legt Richtung, Grundsätze, Verantwortlichkeit und den Rahmen für detailliertere Dokumente fest.

Sie sollte nicht jede technische Einstellung enthalten. TLS-Parameter, Aufbewahrungsfristen eines bestimmten Logs, EDR-Konfiguration, Firewallregeln oder ein Server-Restore-Verfahren ändern sich häufiger und gehören in Standards, Verfahren, Arbeitsanweisungen und Betriebsnachweise.

Sie ist auch keine Betriebsordnung, kein Projektplan, kein Incident-Response-Playbook und keine Information nach Art. 13 oder 14 DSGVO. Diese Dokumente können mit der Richtlinie verbunden sein, erfüllen aber andere Aufgaben und haben einen anderen Lebenszyklus.

Der wichtigste Test ist einfach: Nach dem Lesen sollte klar sein, welche Grundsätze die Organisation angenommen hat und wer für ihre Umsetzung verantwortlich ist. Ein Satz wie "die Organisation gewährleistet Informationssicherheit" ohne Verantwortungsmechanismus beantwortet diese Frage nicht.

Stellung in der Dokumentationshierarchie

Es gibt keine gesetzlich vorgeschriebene Zahl von Dokumentationsebenen. Praktisch können Dokumente nach Stabilität und Detailgrad getrennt werden:

• übergeordnete Richtlinie - Richtung, Ziele, Grundsätze und Verantwortlichkeit;
• thematische Richtlinien oder Standards - etwa Zugriffskontrolle, Kryptographie, Backups, Lieferanten, Remote Work, Schwachstellenmanagement;
• Verfahren - Ablauf eines Prozesses und operative Rollen;
• technische Anweisungen - konkrete Schritte für System oder Technologie;
• Register und Aufzeichnungen - Nachweise, dass Verfahren tatsächlich ausgeführt wurden.

Diese Trennung verhindert, dass jede kleinere technische Änderung erneut der obersten Leitung vorgelegt werden muss. Ändert sich nach einem Produktupdate eine Konfigurationsanweisung, muss deshalb nicht automatisch die strategische Richtlinie geändert werden.

Die Richtlinie soll stabil, aber nicht statisch sein. Sie ist in geplanten Abständen und bei Veränderungen von Kontext, Recht, Risiko, Verantwortlichkeiten oder grundlegenden Systemprinzipien zu überprüfen. ISO/IEC 27001 verlangt keine universelle jährliche Änderung des Richtlinientextes. Die Organisation muss vielmehr ihre fortdauernde Eignung und Kontrolle als dokumentierte Information sicherstellen.^[2]

Was ISO/IEC 27001:2022 verlangt

Klausel 5.2 von ISO/IEC 27001 verlangt, dass die oberste Leitung eine zum Zweck der Organisation passende Informationssicherheitsrichtlinie festlegt. Sie muss Informationssicherheitsziele enthalten oder einen Rahmen zu deren Festlegung schaffen sowie die Verpflichtung zur Erfüllung anwendbarer Anforderungen und zur kontinuierlichen Verbesserung des ISMS. Sie muss als dokumentierte Information verfügbar sein, intern kommuniziert und interessierten Parteien soweit angemessen zugänglich gemacht werden.^[2]

Die Norm schreibt weder ein Muster, eine Seitenzahl noch eine bestimmte Unterschriftsform vor. Die oberste Leitung muss die Richtlinie jedoch tatsächlich festlegen und die Verantwortung für die ISMS-Ausrichtung tragen. Unterschrift, Beschluss, Verfügung oder ein anderer genehmigter Mechanismus können je nach Governance als Nachweis dienen.

Anhang A und ISO/IEC 27002 konkretisieren Kontrollbereiche. Daraus folgt nicht, dass alle 93 Controls in die übergeordnete Richtlinie kopiert werden sollen. Ihre Anwendbarkeit wird im Risiko- und ISMS-Kontext bewertet und unter anderem in der Erklärung zur Anwendbarkeit dokumentiert.^[2][6]

Was aus KRI folgt

Die KRI-Verordnung vom 21. Mai 2024 verlangt von der Leitung erfasster Stellen, ein Informationssicherheitsmanagementsystem einzurichten, umzusetzen, zu betreiben, zu überwachen, zu überprüfen, aufrechtzuerhalten und zu verbessern. § 19 Abs. 2 enthält 14 Anforderungsgruppen, darunter Aktualisierung interner Regelungen, Risikoanalyse, Inventarisierung, Berechtigungsmanagement, Schulungen, Schutz vor Schwachstellen, Incident Management, Konformitätskontrollen und ein jährliches internes Audit.^[1]

KRI verlangt nicht, dass alle diese Anforderungen in einem Dokument mit dem Titel Informationssicherheitsrichtlinie stehen. Ein KRI-Audit sollte das gesamte System von Regelungen, Verantwortlichkeiten und Aufzeichnungen prüfen. Die Richtlinie kann oberste Ebene sein, während Detailanforderungen in Standards und Verfahren verteilt werden.

§ 19 Abs. 3 enthält einen Mechanismus, nach dem Anforderungen als erfüllt gelten, wenn das ISMS auf einschlägigen Polnischen Normen, darunter PN-ISO/IEC 27001, basiert und verbundene Normen für Controls und Risikomanagement verwendet werden.^[1] Das ist keine Zertifizierungspflicht.

Am 29. August 2026 ist die KRI-Verordnung von 2024 weiterhin in Kraft. Parallel wird der Entwurf RD313 für eine neue Verordnung entwickelt.^[7] Organisationsdokumente sollten daher nicht so formuliert werden, als seien Entwurfsanforderungen bereits geltendes Recht.

KSC und NIS2: Richtlinie als Teil des Risikomanagements

Nach der seit 3. April 2026 geltenden Novelle verlangt das KSC von wesentlichen und wichtigen Einrichtungen ein ISMS in Informationssystemen, die in für die Leistungserbringung relevanten Prozessen genutzt werden, sowie systematisches Cybersicherheitsrisikomanagement. Art. 8 umfasst unter anderem Sicherheitsrichtlinien, sichere Beschaffung und Wartung, Lieferkette, Kontinuität, Monitoring, Wirksamkeitsbewertung, Schulung, Kryptographie sowie das Management von Assets, Schwachstellen und Vorfällen.^[3]

Art. 21 Abs. 2 NIS2 nennt Richtlinien für Risikoanalyse und Sicherheit von Informationssystemen als Risikomanagementmaßnahme.^[4] Für Organisationen in Polen ist jedoch das aktuelle KSC das zentrale Compliance-Kriterium, während NIS2 den gemeinsamen EU-Kontext liefert.

Die Leitung besitzt in diesem System eine reale Rolle: Sie genehmigt angemessene Maßnahmen und überwacht deren Umsetzung. Das ist nicht mit einer Rechtsvorschrift gleichzusetzen, die die Unterschrift unter eine bestimmte Datei namens "Informationssicherheitsrichtlinie" verlangt. Der Dokumentationsmechanismus muss zur Governance passen und Managemententscheidungen nachweisbar machen, was zu den geprüften Bereichen eines KSC/NIS2-Audits gehört.

DSGVO: Richtlinien, aber nicht zwingend ein Dokument dieses Namens

Art. 24 Abs. 2 DSGVO sieht vor, dass Maßnahmen des Verantwortlichen, soweit verhältnismäßig, die Umsetzung geeigneter Datenschutzrichtlinien umfassen. Art. 32 verlangt risikoadäquate Sicherheitsmaßnahmen, Art. 25 Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen.^[5]

Die DSGVO schreibt aber kein universelles Dokument "Informationssicherheitsrichtlinie" in einem bestimmten Format vor. Eine Organisation kann Teile von Datenschutzgrundsätzen mit der Sicherheitsrichtlinie verbinden oder separate Dokumente führen. Zuständigkeiten dürfen nicht verwischt werden: Eine Sicherheitsrichtlinie ersetzt weder das Verzeichnis von Verarbeitungstätigkeiten, Datenschutzhinweise, DPIA, Auftragsverarbeitungsverträge noch das Verfahren bei Datenschutzverletzungen, die alle Gegenstand eines DSGVO-Audits sind.

Was eine gute Richtlinie enthalten sollte

Der Umfang muss zur Organisation passen. Praktisch sind folgende Elemente sinnvoll.

Zweck und Scope. Klar benennen, welche Einheiten, Standorte, Systeme, Informationsarten und Personen erfasst sind. Ein zu vager Scope führt später zu Streit über die Anwendbarkeit einzelner Regeln.

Verpflichtung der Leitung. Informationssicherheit muss als Teil der Organisationssteuerung und nicht als isoliertes IT-Projekt erkennbar sein.

Ziele und Grundsätze. Beispiele sind Least Privilege, Funktionstrennung, Security in Change Management, Defense in Depth, Risikomanagement und dokumentierte Ausnahmen. Grundsätze sollten so konkret sein, dass Verstöße erkennbar sind.

Rollen und Verantwortlichkeiten. Zu beschreiben sind Leitung, Informations- und Systemverantwortliche, Sicherheitsteam, Administratoren, Benutzer, Datenschutzbeauftragter soweit einschlägig und Lieferanten. "Die IT ist für Sicherheit verantwortlich" ist meist zu pauschal und falsch.

Informationsklassifizierung und Umgang. Kategorien sind an die reale Arbeitsweise anzupassen. Es gibt keine allgemeine gesetzliche Pflicht für drei oder vier Stufen.

Verweise auf Themenrichtlinien. Die Richtlinie kann auf detaillierte Regeln zu Zugriff, Kryptographie, Backup, Lieferanten, Schwachstellen, Vorfällen, Kontinuität, Remote Work und physischer Sicherheit verweisen.

Meldung von Sicherheitsereignissen. Die Richtlinie sollte Kanal und Prinzip schneller Eskalation festlegen. Detaillierte Rechtsfristen und Klassifizierungslogik gehören besser in Response-Verfahren, da sie sich zwischen KSC, DSGVO, DORA und anderen Regimen unterscheiden.

Review und Dokumentenlenkung. Verantwortlicher, Review-Trigger, Genehmigungsverfahren, Veröffentlichung der gültigen Version und Rücknahme veralteter Versionen sind festzulegen.

Klassifizierung nur, wenn sie Verhalten steuert

Eine Tabelle mit den Stufen öffentlich, intern, vertraulich und streng vertraulich schützt allein nichts. Für jede Kategorie sind umsetzbare Regeln erforderlich: Wer darf zugreifen? Darf externe E-Mail genutzt werden? Welche Verschlüsselung gilt? Wo darf gespeichert werden? Wie wird gekennzeichnet und gelöscht?

Die Klassifizierung sollte sich an Folgen unbefugter Offenlegung, Veränderung oder Nichtverfügbarkeit orientieren und nicht an der Intuition des Dokumentautors. Öffentliche Organisationen müssen zusätzlich spezielle gesetzliche Informationskategorien berücksichtigen. Eine interne Klassifizierung ändert keinen gesetzlich bestimmten Informationsstatus.

Compliance-Mapping: nützlich, aber keine Magie

Zur Richtlinie oder zur ISMS-Dokumentation kann eine Matrix gehören, die zeigt, welche Dokumente und Prozesse bestimmte Anforderungen aus KRI, KSC, DSGVO, ISO/IEC 27001 oder anderen Regimen unterstützen. Dadurch beginnt ein Audit nicht jedes Mal mit der manuellen Suche in Dutzenden Dateien.

Die Matrix darf keine Gleichwertigkeit von Dokumenten unterschiedlichen Rechtscharakters suggerieren. Eine Kontrolle kann mehrere Anforderungen unterstützen, die Erfüllung einer ISO-Klausel beweist aber nicht automatisch die Erfüllung einer Rechtsnorm. Jedes Mapping ist innerhalb seines Scopes zu lesen; die Methodik dafür liefert ISO 19011:2026.^[9]

Richtlinie und Praxis

Das wichtigste Policy-Audit prüft, ob Grundsätze Spuren in Systemen und Entscheidungen hinterlassen.

• Verlangt die Richtlinie Least Privilege, wird eine Stichprobe privilegierter Konten geprüft.
• Verlangt sie Lieferantenrisikomanagement, werden Vertrag und Risikobewertung eines kritischen Cloud-Dienstes geprüft.
• Erklärt sie Wiederherstellungsfähigkeit, wird der Nachweis des letzten Restore-Tests geprüft.
• Verlangt sie Incident Reporting, wird ein Vorfall von der Erkennung bis zur Entscheidung verfolgt.
• Verlangt sie Klassifizierung, werden reale Dokumente und deren Austausch geprüft.

Eine Richtlinie, die solche Tests nicht unterstützt, ist wahrscheinlich zu abstrakt. Prüfungen des polnischen Obersten Rechnungshofs in öffentlichen Stellen zeigen, dass das Problem oft nicht ein fehlendes Dokument ist, sondern der fehlende Nachweis seiner Anwendung.^[10] Eine Risikobewertung nach ISO/IEC 27005 ist dabei der natürliche Bezugspunkt, weil sie den Grundsatz mit der Entscheidung über eine Maßnahme verbindet.^[8]

Häufige Fehler

1. Internetvorlage. Erkennbar an nicht existierenden Rollen, veraltetem Recht, nicht verwendeten Technologien und nicht ersetzten Platzhaltern wie "Organisation".
2. Alles in einem Dokument. Enthält die Richtlinie jede technische Anweisung, wird ihre Pflege unverhältnismäßig aufwendig und unterbleibt.
3. Regeln ohne Verantwortliche. Verantwortung muss realen Rollen zugeordnet sein, und die Rolle muss in der Struktur existieren.
4. Eine willkürliche Review-Frequenz als ISO-Pflicht darstellen. Ein jährlicher Review kann sinnvoll sein, ISO/IEC 27001 verlangt aber keine jährliche Änderung des Richtlinientextes.
5. Detaillierte Rechtsfristen ohne Pflegeprozess. Ändert sich das Recht, wird die Richtlinie zur falschen Anweisung. Besser ist die Trennung zwischen sofortiger Eskalationspflicht auf Policy-Ebene und konkreten Fristen in Response-Verfahren.
6. Unterschrift mit Umsetzung gleichsetzen. Sie beweist Genehmigung, nicht die Wirksamkeit der Kontrollen.
7. Fehlende Kommunikation. Eine Richtlinie, die nur auf dem Laufwerk des ISMS-Verantwortlichen liegt, erfüllt ihre Organisationsfunktion nicht.

Wie die Richtlinie umgesetzt wird

Nach Genehmigung ist festzulegen, welche Gruppen das gesamte Dokument und welche nur relevante Regeln kennen müssen. Administratoren benötigen andere Informationen als die Finanzabteilung. Ein externer Dienstleister braucht nicht zwingend die gesamte interne Richtlinie, aber seine Anforderungen müssen in Vertrag, Sicherheitsanlage oder Zugriffsanweisung stehen.

Schulungen sollten Grundsätze in Entscheidungen übersetzen: Wie wird ein Vorfall gemeldet? Was darf nicht versendet werden? Wie wird Zugang geschützt? Wo werden Informationen gespeichert? Wer genehmigt eine Ausnahme? Ein Wissensquiz nach dem Lesen beweist nicht, dass der Prozess funktioniert.

Bei der Gestaltung von Richtlinien in 4crypto ist es meist sinnvoller, mit ISMS-Scope, Risikolandkarte und bestehenden Prozessen zu beginnen und erst danach den Text zu schreiben. Die umgekehrte Reihenfolge erzeugt häufig ein Dokument für eine vorgestellte statt für die reale Organisation.

Wann die Richtlinie geändert werden sollte

Eine Änderung ist erforderlich, wenn die Richtlinie Richtung und Grundsätze nicht mehr korrekt beschreibt. Typische Trigger sind:

• wesentliche Änderung von Struktur oder Verantwortlichkeit;
• Eintritt in einen neuen Rechtsrahmen oder wesentliche regulatorische Änderung;
• Cloud, Outsourcing oder eine neue Technologieklasse mit verändertem Risiko;
• ein schwerer Vorfall, der einen fehlerhaften Grundsatz offenlegt;
• ein Audit- oder Management-Review-Ergebnis;
• Änderung von Risikoappetit oder Sicherheitszielen.

Ein Review kann legitim mit "keine Änderung erforderlich" enden. Auch dieser Beschluss sollte dokumentiert werden. Nur Datum und Versionsnummer zu ändern, um Aktualität vorzutäuschen, schafft dagegen keinen Wert: Ein Auditor liest den Inhalt und nicht die Fußzeile.