Kundenservice: Tel +43.1.97000-100 • kundenservice@forum-media.at
OnlineBuch Praxishandbuch Cybersicherheit

© FM Forum Business Solutions GmbH
A-1200 Wien, Dresdner Straße 45
E-Mail: kundenservice@forum-media.at


drucken

DEMO
Neu Dokument-ID: 1277175

Harald Straub | Praxiswissen | Fachbeitrag

1 Erarbeitung von Sicherheitskonzepten und Cybersicherheits-Richtlinien

Cybersicherheits-Risikomanagement verbindet Sicherheitsziele, Risiken, Maßnahmen, Verantwortlichkeiten und Nachweise. Hier wird Informationssicherheit in den Regelbetrieb übersetzt: Sicherheitskonzepte werden gepflegt, Richtlinien angewendet, Maßnahmen priorisiert, Lieferunternehmen gesteuert, Kontrollen geprüft und Beschäftigte im sicheren Umgang mit Informationen unterstützt.

Ein Sicherheitskonzept macht Informationssicherheit steuerbar. Es hält fest, welche Informationen, Prozesse, Systeme, Standorte und Dienstleister betrachtet werden, welche Sicherheitsziele gelten, wer entscheidet und wie Risiken in Maßnahmen übersetzt werden. Es ersetzt weder technische Detailplanung noch Rechtsprüfung. Sein Wert liegt darin, die tragenden Entscheidungen sichtbar zu machen und Richtlinien, Maßnahmen und Nachweise auf einen gemeinsamen Rahmen zu beziehen.

Cybersicherheits-Richtlinien konkretisieren diesen Rahmen. Sie legen für wiederkehrende Themen fest, welche Regeln im Betrieb gelten: Zugriff, mobile Arbeit, Cloud-Nutzung, Datensicherung, Patch- und Schwachstellenmanagement, Lieferantensteuerung, Umgang mit Informationen oder Meldewege bei Sicherheitsereignissen. Eine Richtlinie ist dann belastbar, wenn sie verständlich, freigegeben, bekannt gemacht, umsetzbar und überprüfbar ist.

Sicherheitskonzept, Leitlinie und Richtlinien unterscheiden

Am Anfang steht die Sicherheitsleitlinie. Sie ist die oberste, meist kurze Aussage der Leitungsebene zur Informationssicherheit und benennt Grundsätze, Verantwortungsrahmen und Erwartungen. Sie muss tragfähig genug sein, um spätere Entscheidungen zu leiten, darf aber nicht bei jeder technischen Änderung neu geschrieben werden müssen.

Das Sicherheitskonzept ordnet Anwendungsbereich, Schutzobjekte, Risikobezug, Rollen, Maßnahmenlogik, Nachweisführung und Pflege. Standards und Leitfäden können die Struktur stützen, etwa die ISO/IEC-27000-Familie, der BSI IT-Grundschutz, das Österreichische Informationssicherheitshandbuch oder branchenspezifische Vorgaben. Sie liefern Orientierung für Aufbau und Nachweislogik; rechtliche Einordnung, konkrete Pflichten und eine allfällige Zertifizierungsbewertung bleiben davon getrennt.

Richtlinien regeln einzelne Themenfelder und stehen näher am Betrieb als Leitlinie und Sicherheitskonzept. Sie betreffen zum Beispiel:

  • Zugriffsmanagement
  • Passwörter und Multi-Faktor-Authentifizierung
  • Nutzung von IT-Systemen
  • Mobile Arbeit
  • Cloud-Dienste
  • Datensicherung
  • Sicherheitsereignisse
  • Lieferunternehmen
  • Sichere Softwareentwicklung
  • Informationsklassifikation

Welche Richtlinien nötig sind, hängt von Risiko, Größe, Branche, technischen Abhängigkeiten und Nachweisbedarf ab.

Dokument

Funktion

Typischer Nachweis

Sicherheitsleitlinie

Grundsatzentscheidung der Leitungsebene zu Informationssicherheit, Verantwortungsrahmen und Sicherheitszielen

Freigegebene Leitlinie mit Geltungsbereich, Datum, Verantwortlichkeit und Review-Zyklus

Sicherheitskonzept

Übersetzt Sicherheitsziele in Scope, Schutzbedarf, Risikobezug, Rollen, Maßnahmenlogik und Nachweise

Aktuelles Konzept mit Freigabe, Bezug zu Risikoregister, Maßnahmenplan und Ausnahmeregelung

Cybersicherheits-Richtlinie

Regelt ein wiederkehrendes Thema so, dass Fachbereiche, IT und Dienstleister danach handeln können

Richtlinienregister, Version, Verantwortliche, Kommunikationsnachweis, Umsetzungs- und Prüfnachweise

Ausnahmeregelung

Erlaubt begründete, befristete Abweichungen ohne informelle Regelbrüche

Ausnahmeregister mit Risiko, Kompensationsmaßnahme, Genehmigung, Frist und Review

Scope, Schutzbedarf und Risikobezug

Der Scope legt fest, welcher organisatorische und technische Bereich betrachtet wird: ein Unternehmen, ein Standort, eine kritische Geschäftseinheit, ein Dienst, eine Plattform oder ein Produktionsbereich. Ein zu enger Scope blendet Abhängigkeiten aus; ein zu breiter Scope überfordert häufig die erste Umsetzungswelle. Tragfähig ist die Abgrenzung, wenn sie die geschäftskritischen Leistungen, die dafür nötigen Systeme, Daten und Dienstleister sowie rechtliche, vertragliche oder kundenseitige Erwartungen nachvollziehbar berücksichtigt.

Der Schutzbedarf verbindet Geschäftsrelevanz und Sicherheitsanforderung. Kundendaten, Produktionssteuerung, Zahlungsprozesse, Identitätsdienste, Backup-Systeme, Quellcode, Vertragsdaten oder privilegierte Administrationszugänge haben unterschiedliche Anforderungen an Vertraulichkeit, Integrität und Verfügbarkeit. Die Bewertung sollte fachlich begründet und dokumentiert sein, nicht nur technisch geschätzt. Fachbereiche, Prozessverantwortliche, Datenschutz, Compliance und Leitungsebene sind dort einzubeziehen, wo geschäftliche Auswirkungen oder rechtliche Treiber eine Rolle spielen.

Der Risikobezug schützt vor Papier-Compliance. Eine Richtlinie sollte nicht nur vorhanden sein, sondern auf ein Risiko oder eine nachvollziehbare Anforderung antworten. Multi-Faktor-Authentifizierung kann aus dem Risiko kompromittierter Zugangsdaten, aus Lieferkettenanforderungen oder aus Standardorientierung folgen. Datensicherung wird über Verfügbarkeitsrisiken, Ransomware-Szenarien und Wiederanlaufziele begründet; Lieferantenanforderungen über Abhängigkeiten, Datenzugriffe, Remote-Zugriffe oder vertragliche Kundenerwartungen.

Rollen, Verantwortlichkeiten und Freigaben

Rollen müssen so beschrieben sein, dass sie im Alltag funktionieren. Eine Organisation braucht zumindest die folgenden Rollen:

  • Eine verantwortliche Stelle für das Sicherheitskonzept
  • Eine Stelle für Richtlinienpflege
  • Operative Verantwortliche für Maßnahmen und
  • Eine Leitungsebene, die wesentliche Sicherheitsentscheidungen trägt

In kleineren Unternehmen können mehrere Rollen bei denselben Personen liegen. Das ist zulässig, solange Interessenkonflikte erkannt und kritische Entscheidungen nicht vollständig ohne Gegenprüfung getroffen werden.

Rollenbeschreibungen brauchen Entscheidungsrechte und Mitwirkungspflichten. Dazu zählen Freigabe von Richtlinien, Bewertung von Ausnahmen, Priorisierung von Maßnahmen, Prüfung der Umsetzung, Bericht an die Leitungsebene, Einbindung externer Dienstleister und Entscheidung über Restrisiken. Bleiben diese Punkte offen, bleibt auch ein formal sauberes Sicherheitskonzept im Betrieb schwach.

Freigaben sollten risikogerecht erfolgen. Eine allgemeine Leitlinie braucht in der Regel eine Freigabe durch eine geeignete Leitungsebene. Technische Detailrichtlinien können durch fachlich verantwortliche Rollen freigegeben werden, wenn der Rahmen klar ist. Ausnahmen mit erheblichem Risiko sollten nicht allein dort genehmigt werden, wo sie operativ entstehen. Sie brauchen eine dokumentierte Risikoabwägung, eine Befristung und eine Entscheidung auf einer angemessenen Ebene.

Steuerungsfrage

Praxisregel

Nachweisidee

Wer trägt den Rahmen?

Leitlinie und Sicherheitskonzept brauchen eine erkennbare fachliche und organisatorische Eigentümerschaft.

Rollenmatrix, Freigabevermerk, Verantwortlichkeitsbeschreibung

Wer setzt Regeln um?

Für jede wesentliche Richtlinie muss klar sein, welche Rolle Umsetzung und Pflege koordiniert.

Richtlinienregister mit Owner, Version, Geltungsbereich und Review-Termin

Wer akzeptiert Restrisiken?

Risikoakzeptanz soll bewusst, befristet und nachvollziehbar erfolgen

Risikoregister, Ausnahmeregister, Managemententscheidung oder Review-Protokoll

Wer prüft Aktualität?

Mindestens anlassbezogen und regelmäßig prüfen, ob Scope, Risiken, Rollen und Maßnahmen noch passen

Review-Protokoll, Änderungsverzeichnis, Maßnahmen-Backlog

Kommunikation, Anwendung und Ausnahmen

Richtlinien entfalten nur Wirkung, wenn die betroffenen Zielgruppen sie kennen und anwenden können. Beschäftigte benötigen klare Arbeitsregeln, keine abstrakte Normsprache. IT-Verantwortliche benötigen technische Mindestanforderungen, Betriebsgrenzen und Prüfpunkte. Einkauf und Fachbereiche benötigen Sicherheitsanforderungen für Dienstleister, Cloud-Dienste und neue Anwendungen. Leitung und Compliance benötigen Nachweise, Entscheidungsgrundlagen und Statusberichte.

Kommunikation beginnt nicht mit einem Rundmail, sondern mit Zielgruppenlogik. Eine Passwort- oder MFA-Regel betrifft fast alle Personen. Eine Richtlinie für privilegierte Zugriffe richtet sich vor allem an IT, externe Administratoren und Dienstleister. Vorgaben zur Softwareentwicklung oder zur Beschaffung sicherer Webanwendungen betreffen andere Rollen als Regeln zur mobilen Arbeit. Je genauer die Zielgruppe bestimmt ist, desto besser lässt sich eine Regel erklären und prüfen.

Ausnahmen sind unvermeidbar. Legacy-Systeme, technische Einschränkungen, externe Plattformen oder zeitkritische Projekte können dazu führen, dass eine Vorgabe nicht sofort erfüllt wird. Eine Ausnahme darf jedoch nicht zur informellen Dauergenehmigung werden. Sie sollte Risiko, Grund, betroffenen Scope, kompensierende Maßnahme, verantwortliche Rolle, Frist und Review enthalten. Ohne solche Mindestangaben ist später kaum prüfbar, ob die Abweichung gesteuert oder nur geduldet wurde.

Beispiel:

Ein Altsystem unterstützt keine Multi-Faktor-Authentifizierung. Eine belastbare Ausnahme beschreibt nicht nur diese technische Einschränkung, sondern auch den betroffenen Prozess, zusätzliche Schutzmaßnahmen, Laufzeit, geplante Ablöse oder technische Kompensation und die Rolle, die den Fortschritt überwacht.

Pflege, Änderung und Nachweisführung

Sicherheitskonzepte und Richtlinien altern schnell, wenn sie nicht mit Änderungen im Betrieb verbunden sind. Neue Cloud-Dienste, Standorte, Lieferunternehmen, Schnittstellen, regulatorische Anforderungen, größere Systemwechsel oder wiederkehrende Sicherheitsereignisse können Anpassungen auslösen. Ein jährlicher Review ist ein sinnvoller Mindestanker; wesentliche Änderungen verlangen zusätzlich eine anlassbezogene Aktualisierung.

Nachweisführung bleibt am besten schlank. Zentrale Nachweise sind freigegebene Dokumente, Richtlinienregister, Rollenmatrix, Risikoregister, Maßnahmen-Backlog, Ausnahmeregister, Schulungs- oder Kommunikationsnachweise, Review-Protokolle und Wirksamkeitsprüfungen. Sie müssen nicht in einem einzigen Dokument stehen; zusammen sollten sie zeigen, welche Regel gilt, wer entschieden hat, wie umgesetzt wurde und wann die nächste Prüfung erfolgt.

Für Prüfungen zählt die Verbindung zwischen Regelung und Umsetzung. Eine Richtlinie zum Zugriffsschutz ist nur ein erster Nachweis; sichtbar werden muss auch, wie Zugriffe vergeben, überprüft und entzogen werden. Eine Backup-Richtlinie trägt erst, wenn Wiederherstellung angemessen getestet wird. Eine Lieferantenrichtlinie gewinnt Wert, wenn Lieferunternehmen klassifiziert, Anforderungen festgelegt und Nachweise geprüft werden.

Typische Schwachstellen in Sicherheitskonzepten und Richtlinien

Häufige Schwachstellen entstehen nicht durch fehlende Textmenge, sondern durch fehlende Entscheidungskraft. Dazu gehören unklarer Scope, veraltete Rollen, nicht freigegebene Dokumente, Richtlinien ohne technische Umsetzung, fehlende Ausnahmeregelung, fehlender Review-Zyklus oder ein Maßnahmenkatalog ohne Bezug zu Risiken und Schutzbedarf. Auch zu viele Richtlinien können problematisch sein, wenn sie nicht gepflegt und nicht angewendet werden.

Problematisch ist auch die Verwechslung von Standardorientierung und Pflichtenerfüllung. ISO/IEC 27001, BSI IT-Grundschutz, CyberRisk Rating 2026 und andere Rahmenwerke können Struktur, Kontrolllogik und Nachweisführung unterstützen. Sie sind aber keine pauschale rechtliche Erfüllung. Ihr Beitrag liegt in Orientierung und Nachweisfähigkeit; rechtliche Bewertung bleibt der konkreten Prüfung vorbehalten.

Quellenhinweise

Lizenzpflichtige Normtexte werden nicht wiedergegeben oder normnah nachgebildet. Maßgeblich ist die jeweils aktuelle Originalfassung.

FM Forum Business Solutions GmbH auf linkedin FM Forum Business Solutions GmbH bei XING

© 2026 FM Forum Business Solutions GmbH