Was 300-1 und der Katalog zu Rollen festlegen
Kapitel 2.8 von 300-1 hält fest, dass für ein ISMS eine Informationssicherheitsorganisation „mit festgelegten Rollen und Zuständigkeiten zwingend erforderlich“ ist. Zu beachten sind drei Punkte: Rollen und Zuständigkeiten mit den notwendigen Qualifikationen und Kompetenzen festlegen, Interessenkonflikte vermeiden, mit den Beispielen „IT-Leitung vs. ISB, DSB vs. ISB“, und Schnittstellen innerhalb des Anwendungsbereichs festlegen. Dazu kommt eine Beteiligungsregel: Der ISB oder eine andere Rolle der Sicherheitsorganisation muss in sicherheitsrelevante Projekte eingebunden und über die wesentlichen Inhalte informiert werden; wann das geschieht, wird festgelegt.
Der Anwenderkatalog setzt das vor allem in der Praktik Governance und Compliance (GC) als MUSS-Anforderungen um, für den Risikoeigentümer in der Praktik Risikomanagement (RISK):
| Anforderung | Inhalt (gekürzt) | Parameter |
|---|---|---|
| GC.9.1 Festlegung einer Sicherheitsorganisation | Sicherheitsorganisation unter Einbezug von Rollen, Zuständigkeiten und Gremien festlegen | - |
| GC.9.1.1 Festlegung von Rollen und Zuständigkeiten | die [Parameter] im Rahmen des ISMS inklusive ihrer Kompetenzen bzw. Befugnisse zuweisen | „Rollen und Zuständigkeiten“ |
| GC.9.1.1.1 Informationssicherheitsbeauftragter | die Zuständigkeit für Informationssicherheit [Parameter], welche unmittelbar der Institutionsleitung unterstellt ist, zuweisen | „einer unabhängigen Person“ |
| GC.9.1.1.1.1 Ressourcen für den ISB | dem ISB hinreichende Ressourcen zuweisen | - |
| GC.9.1.1.1.2 Vorspracherecht | das direkte Vorspracherecht des ISB bei der Institutionsleitung verankern | - |
| GC.9.1.1.2 Stellvertreterregelungen | Stellvertretungen für alle relevanten Rollen und Zuständigkeiten zuweisen | - |
| GC.9.1.1.3 Vermeidung von Interessenkonflikten | Maßnahmen gegen Interessenkonflikte bei der Festlegung von Rollen festlegen | - |
| GC.9.1.1.4 Sicherstellung der Qualifikation | für jeden Rollen- und Verantwortungsträger die erforderlichen Anforderungen und Fähigkeiten festlegen | - |
| GC.10.1.2 Kommunikation im Projektmanagement | bei sicherheitsrelevanten Projekten die Beteiligung [Parameter] zu festgelegten Zeitpunkten verankern | „der relevanten Sicherheitsorgane“ |
| RISK.1.3 Risikoeigentümer | die Rolle des Risikoeigentümers mit den notwendigen Aufgaben und Befugnissen verankern | - |
Die Parameter in GC.9.1.1, GC.9.1.1.1 und GC.10.1.2 legen Sie selbst fest. Wie Sie das protokollieren, zeigt Blaupausen und Parameter.
Die Rollen im Überblick
| Rolle | Aufgaben und Befugnisse nach den Quellen | Fundstelle |
|---|---|---|
| Institutionsleitung | Verantwortung für die Umsetzung des ISMS, „kann nicht delegiert werden“; trifft und gibt die relevanten Entscheidungen frei, insbesondere zu Anwendungsbereich, Schutzbedarf der Geschäftsprozesse, Reihenfolge der Abarbeitung, Ressourcen und Leitlinie; autorisiert den Rahmen der Risikobetrachtung und die Restrisiken; führt die Managementbewertung durch | 300-1 Kap. 2.10, 2.11, 4.2.3, 5.3; GC.1.2, GC.5.1.4, GC.6.1, RISK.1.5 |
| Informationssicherheitsbeauftragter (ISB) | Zuständigkeit für Informationssicherheit, unmittelbar der Leitung unterstellt, mit hinreichenden Ressourcen und direktem Vorspracherecht; wird in sicherheitsrelevante Projekte eingebunden, übernimmt aber nicht in jedem eine aktive Rolle | 300-1 Kap. 2.8; GC.9.1.1.1 ff. |
| Geschäftsprozesseigentümer | fachlich verantwortliche Person, Rolle oder Organisationseinheit eines Geschäftsprozesses; zugleich Risikoeigentümer, sofern nichts anderes festgelegt ist | 300-1 Anhang 2, Kap. 4.2.1 |
| Risikoeigentümer | jedem Risiko zugewiesen; autorisiert die Umsetzungsplanung für die beschlossenen Maßnahmen; bei Risiken über mehrere Geschäftsprozesse ein federführender Risikoeigentümer | 300-1 Kap. 4.2.1, 4.2.3; Anhang 3, Kriterien 5, 16, 31; RISK.1.3, RISK.1.10 |
| Umsetzungszuständige (fachlich und operativ) | für die Umsetzung nicht erfüllter Anforderungen eindeutig zugewiesen; bei komplexen Maßnahmen getrennt nach fachlicher und operativer Zuständigkeit | 300-1 Kap. 4.4; UMS.3.1 |
| IT-Betrieb | in 300-1 als Beispiel einer festzulegenden Rolle genannt; setzt technische Maßnahmen um und liefert technische Nachweise | 300-1 Kap. 2.8 |
| Auditteam und Auditteamleiter | objektiv und unparteiisch ausgewählt, fachlich geeignet; dem Auditteamleiter wird die Verantwortung für das einzelne interne Audit zugewiesen | 300-1 Kap. 5.2.2; PERF.3.1.3 |
| Datenschutzbeauftragter (DSB) | in 300-1 nur als Konfliktpartner des ISB genannt; Schnittstelle für Fragen zur Verarbeitung personenbezogener Daten | 300-1 Kap. 2.8 |
| Compliance-Stelle | soll beim Compliance-Management angehört werden | 300-1 Kap. 2.2; GC.3.1.2 |
| Mitarbeitende | erhalten die Leitlinie kommuniziert; sind interessierte Partei des ISMS | 300-1 Kap. 2.7, 2.4 |
Ein IS-Management-Team oder weitere Gremien schreibt 300-1 nicht vor. GC.9.1 verlangt, Gremien in die Sicherheitsorganisation einzubeziehen; welche Sie einrichten, entscheiden Sie selbst. Wie die klassische Methodik Rollen beschrieben hat, finden Sie auf BSI-Standard 200-2.
RACI-Muster für Entscheidungen und Nachweise
RACI steht für Responsible (führt aus), Accountable (entscheidet, genau eine Rolle je Zeile), Consulted (wird vorher gehört) und Informed (wird informiert). Kennzeichnung: Die A-Einträge mit Fundstelle folgen 300-1 oder dem Katalog. Alle übrigen Einträge sind ein eigener Vorschlag für eine mittelgroße Institution mit eigenem IT-Betrieb und gehören an Ihre Organisation angepasst.
| Entscheidung oder Nachweis | Leitung | ISB | Geschäftsprozess- bzw. Risikoeigentümer | IT-Betrieb | Auditteam | DSB, Compliance | Fundstelle für A |
|---|---|---|---|---|---|---|---|
| Anwendungsbereich festlegen | A | R | C | C | - | C | Kap. 2.3, 2.10; GC.6.1 |
| Geschäftsprozesse dokumentieren | I | R | A | C | - | - | eigener Vorschlag (fachliche Verantwortung nach Anhang 2) |
| Schutzbedarf der Geschäftsprozesse freigeben | A | R | C | - | - | C | Kap. 2.10; GC.7.1.2 |
| Reihenfolge der Geschäftsprozesse festlegen | A | R | C | - | - | - | Kap. 2.6, 2.10 |
| Leitlinie freigeben | A | R | C | I | - | C | Kap. 2.7; GC.5.1.4 |
| Rollen, Zuständigkeiten, Stellvertretungen festlegen | A | R | C | C | - | C | Kap. 2.7 (Sicherheitsorganisation in der Leitlinie, Freigabe durch die Leitung); GC.5.1.4; für Risikorollen Anhang 3, Kriterium 9, RISK.1.5 |
| Ressourcen freigeben | A | R | C | C | - | - | Kap. 2.10, 4.4 |
| Rahmen der Risikobetrachtung (Verfahren, Rollen, Kriterien, Risikoappetit) autorisieren | A | R | C | - | - | C | Kap. 2.11; Anhang 3, Kriterium 9; RISK.1.5 |
| Risiken identifizieren und bewerten | I | R | A | C | - | C | eigener Vorschlag (Risikoeigentümer nach Kap. 4.2.1) |
| Umsetzungsplanung aus der Risikobehandlung autorisieren | I | C | A | C | - | - | Kap. 4.2.3; Kriterium 31; RISK.1.10 |
| Restrisiken freigeben | A | R | C | - | - | - | Kap. 4.2.3; Kriterium 30 |
| Umsetzungsstatus je Anforderung ermitteln | I | A | C | R | - | - | eigener Vorschlag |
| Maßnahme umsetzen und Nachweis liefern | - | C | A (fachlich zuständig) | R | - | - | eigener Vorschlag; fachliche Zuständigkeit je Maßnahme benennen nach Kap. 4.4 und UMS.3.1 |
| Fortschritt des Umsetzungsplans verfolgen | I | A, R | I | C | - | - | eigener Vorschlag; Trennung von der Umsetzung nach Kap. 4.5 |
| Vorgehen der Umsetzung freigeben | A | R | C | C | - | - | Kap. 4.4 |
| Internes Audit durchführen, Auditbericht | I | C | C | C | A, R (Auditteamleiter) | - | Kap. 5.2.2 |
| Managementbericht erstellen | I | A, R | C | C | C | C | eigener Vorschlag; Information der Leitung nach PERF.4.2 |
| Managementbewertung durchführen | A, R | C | C | - | I | I | Kap. 5.3 |
| Beteiligung an sicherheitsrelevanten Projekten | - | C | A | R | - | C | eigener Vorschlag (Eigentümer des betroffenen Geschäftsprozesses als Auftraggeber des Projekts); Beteiligung des ISB nach Kap. 2.8 und GC.10.1.2 |
Prüfen Sie das ausgefüllte Muster mit zwei Fragen: Hat jede Zeile genau ein A? Steht in einer Zeile dieselbe Person als R für die Umsetzung und als A für deren Prüfung? Die zweite Frage führt direkt zu den Konfliktfällen im nächsten Abschnitt.
Konfliktfälle und wie Sie sie lösen
| Konfliktfall | Warum er ein Problem ist | Fundstelle | Lösung |
|---|---|---|---|
| Die IT-Leitung ist zugleich ISB | Wer den Betrieb verantwortet, prüft seine eigenen Maßnahmen und Prioritäten | 300-1 Kap. 2.8 nennt „IT-Leitung vs. ISB“; GC.9.1.1.1 verlangt eine Zuständigkeit, die unmittelbar der Leitung unterstellt ist (Parameter „einer unabhängigen Person“) | ISB außerhalb der IT-Linie ansiedeln, mit Vorspracherecht bei der Leitung (GC.9.1.1.1.2) |
| Der DSB ist zugleich ISB | Unterschiedliche Schutzziele und Berichtswege in einer Person | 300-1 Kap. 2.8 nennt „DSB vs. ISB“ | Getrennte Personen; Schnittstellen und Abstimmungstermine festlegen (Kap. 2.8) |
| Wer umsetzt, verfolgt auch den Fortschritt | Verzögerungen werden spät oder nicht sichtbar | 300-1 Kap. 4.5: Interessenkonflikt durch angemessene Rollenverteilung verhindern | Fortschrittsverfolgung beim ISB, Umsetzung beim Betrieb; für Maßnahmen des ISB prüft eine andere Rolle |
| Der ISB auditiert das ISMS, das er aufgebaut hat | Objektivität und Unparteilichkeit des Audits sind nicht gegeben | 300-1 Kap. 5.2.2; PERF.3.1.3 verlangt fachlich geeignete und unabhängige Auditoren | Internes Audit durch eine Stelle ohne Beteiligung am Aufbau, notfalls durch Externe |
| Die Leitung will die ISMS-Verantwortung an den ISB abgeben | Entscheidungen ohne Befugnis, insbesondere über Ressourcen und Restrisiken | 300-1 Kap. 2.10: Verantwortung „kann nicht delegiert werden“; Leitungsverantwortung bestand schon nach 200-2, Kap. 2.3 | ISB bereitet vor, die Leitung entscheidet; Entscheidungsvorlagen zu den Themen aus Kap. 2.10 |
| Ein Risiko betrifft mehrere Geschäftsprozesse | Unklar, wer die Behandlung autorisiert | 300-1 Kap. 4.2.1: federführender Risikoeigentümer aus dem Kreis der betroffenen Geschäftsprozesseigentümer | Federführung im Risikoregister vermerken; die übrigen Eigentümer werden gehört (C) |
| Wer genehmigt Ausnahmen? | UMS.5.1 lässt die Rolle offen (Parameter „eine zuständige Person oder Rolle“); für Risiken außerhalb der Akzeptanzkriterien verlangt Kriterium 27 die Institutionsleitung; für MUSS-Anforderungen ist eine Ausnahme nicht möglich | UMS.5.1; Anhang 3, Kriterium 27; 300-1 Kap. 4.1.2 | Parameter von UMS.5.1 auf die Institutionsleitung setzen oder klar abgrenzen, wofür eine andere Rolle zuständig ist; MUSS-Anforderungen aus jeder Ausnahmeregel herausnehmen |
| Wer gibt das Risiko einer temporär nicht erfüllten SOLLTE-Anforderung frei? | Kap. 2.11 verlangt für SOLLTE-Anforderungen, die in der Umsetzungsplanung stehen, aber noch nicht erfüllt sind, eine Restrisikobetrachtung und die Freigabe durch die Leitung; Kap. 4.1.1 verlangt, das Risiko zu identifizieren, der Leitung mitzuteilen und von ihr übernehmen zu lassen; Kap. 4.1.2 sagt, eine temporäre Nichterfüllung löse keine Risikobetrachtung aus | 300-1 Kap. 2.11, 4.1.1, 4.1.2 | Offene Auslegungsfrage. Wer auf der sicheren Seite bleiben will, lässt das Restrisiko von der Leitung freigeben und dokumentiert die Frist |
| Kleine Institution: eine Person hat mehrere Rollen | Trennungen aus Kap. 2.8 und 4.5 lassen sich nicht vollständig herstellen | GC.9.1.1.2 (Stellvertretungen), GC.9.1.1.3 (Maßnahmen gegen Interessenkonflikte) | Die Maßnahme gegen den Konflikt dokumentieren, etwa Prüfung der Nachweise durch eine andere Person oder externe Stelle; Stellvertretung für jede Rolle benennen |
Wie Sie Risikoentscheidungen mit Zuständigkeit und Überprüfung festhalten, zeigt Risikoakzeptanz und Restrisiko; wie Sie liefernde und prüfende Rolle je Nachweis eintragen, zeigt Nachweisplan.
Rollen einführen und dokumentieren
Legen Sie Rollen vor Personen fest. Für jede Rolle beschreiben Sie Aufgaben, Befugnisse, die erforderlichen Qualifikationen (GC.9.1.1.4) und die Stellvertretung (GC.9.1.1.2). Erst dann ordnen Sie Personen zu. Personen wechseln, die Rollenbeschreibung bleibt; in Prüfeinträgen halten Sie dagegen die Person fest, die tatsächlich geprüft hat, denn Kap. 4.3 verlangt „die dokumentierende beziehungsweise prüfende Person“.
Die Sicherheitsorganisation gehört in die Leitlinie. Kap. 2.7 nennt die Festlegung der Informationssicherheitsorganisation als einen der Aspekte bei der Entwicklung der Leitlinie, mit Verweis auf Kap. 2.8 für die Details. Ein eigenes Rollendokument, auf das die Leitlinie verweist, lässt sich leichter ändern als die Leitlinie selbst, die Sie nach jeder Änderung erneut von der Leitung freigeben lassen.
Die Risikorollen brauchen eine eigene Festlegung. Nach Kap. 2.11 legt die Institution auf organisatorischer Ebene die erforderlichen Rollen mit Zuständigkeiten und Befugnissen fest, insbesondere den Risikoeigentümer, und die Leitung autorisiert diese Rollendefinitionen (Anhang 3, Kriterien 5 und 9). Prüfen Sie, ob Ihre Geschäftsprozesseigentümer diese Rolle tatsächlich ausfüllen können; sonst legen Sie ausdrücklich etwas anderes fest, wie es Kap. 4.2.1 erlaubt.
Die Leitung selbst ist Zielgruppe. SENS.11.1 verlangt, die Institutionsleitung zur Bedeutung der Informationssicherheit für den Schutz der Geschäftsprozesse zu sensibilisieren (SOLLTE). Wer Entscheidungsvorlagen nach Kap. 2.10 vorlegt, sollte das mit einer kurzen Einordnung verbinden, warum gerade diese Entscheidung bei der Leitung liegt.
Weiter: Informationssicherheitsleitlinie · Grundschutz im Betrieb · Projektplanung und Ressourcen · Fallbeispiel: Erhebung und Planung. Blackfort Technology unterstützt beim Aufbau der Sicherheitsorganisation und bei den Entscheidungsvorlagen für die Leitung, siehe Beratung. Die Rolle des ISB extern zu besetzen, beschreibt Externer Informationssicherheitsbeauftragter auf https://www.blackfort-tec.de.