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.
- Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS2-Richtlinie). URL: https://eur-lex.europa.eu/eli/dir/2022/2555/oj.
- Netz- und Informationssystemsicherheitsgesetz 2026, BGBl I Nr 94/2025. URL: https://www.ris.bka.gv.at/eli/bgbl/I/2025/94.
- Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 zur Festlegung technischer und methodischer Anforderungen an Cybersicherheits-Risikomanagementmaßnahmen für bestimmte Einrichtungen. URL: https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj.
- ENISA: NIS2 Technical Implementation Guidance. URL: https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance.
- ISO: ISO/IEC 27001:2022, ISO/IEC 27002:2022 und ISO/IEC 27005:2022. URLs: https://www.iso.org/standard/27001, https://www.iso.org/standard/75652.html, https://www.iso.org/standard/80585.html.
- Bundesamt für Sicherheit in der Informationstechnik: BSI-Standards und IT-Grundschutz-Kompendium. URLs: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/bsi-standards_node.html, https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html.
- A-SIT/Bundeskanzleramt: Österreichisches Informationssicherheitshandbuch. URLs: https://www.onlinesicherheit.gv.at/Themen/Experteninformation/Handbuecher/Informationssicherheitshandbuch.html, https://www.sicherheitshandbuch.gv.at/.
- NIST: The NIST Cybersecurity Framework (CSF) 2.0. URL: https://www.nist.gov/cyberframework.
- Cyber Trust Austria/Cyber Risk Rating: Cyber Risk Rating & Cyber Trust Label Schema Policy 2026. URL: https://www.cyber-trust.at/scheme_2026.pdf.
