ISO 27001 regelt Sicherheitsrollen über zwei Anforderungen: Abschnitt 5.3 verpflichtet das Top-Management, Verantwortlichkeiten und Befugnisse zuzuweisen und zu kommunizieren; Annex A Control 5.2 verlangt, dass Informationssicherheitsrollen in der gesamten Organisation definiert und zugeteilt werden. Zusammen verpflichten sie Sie dazu, zu benennen, wer welchen Control verantwortet, dies zu dokumentieren und nachzuweisen, dass die Mitarbeitenden ihre Aufgaben kennen. Diese Verpflichtung gilt unabhängig von Unternehmensgröße, Branche oder der Anzahl der Rollen, die eine Person gleichzeitig innehat.
TL;DR:
- Die dokumentierte Rollenzuständigkeit muss den tatsächlichen Risiken und betrieblichen Anforderungen entsprechen, unabhängig von Stellenbezeichnungen oder Organisationsgröße.
- Kleine Organisationen kombinieren häufig Rollen wie ISMS-Manager und IT-Manager, müssen jedoch kompensierende Controls dokumentieren, um die Unabhängigkeit zu wahren.
- Auditoren prüfen, ob Verantwortliche, Rechenschaftspflichtige und Befugnisebenen klar zugewiesen, kommuniziert und durch Nachweise wie Schulungs- und Genehmigungsaufzeichnungen belegt sind.
- Rollenbeschreibungen sollten Zweck, Aufgaben, Befugnis, Kompetenz und Nachweisablage umfassen und rollenbasierte Bezeichnungen anstelle von Personennamen verwenden.
- Die häufigsten Auditfehler entstehen durch veraltete RACI-Matrizen, Rollen, die Einzelpersonen statt Positionen zugeordnet sind, und fehlende dokumentierte Verantwortlichkeiten für alle Mitarbeitenden.
Inhaltsverzeichnis
- Was ISO 27001 für Rollen tatsächlich verlangt
- Kernrollen in ISO 27001 und ihre Verantwortlichkeiten
- Rollen dokumentieren: RACI-Matrizen und Stellenbeschreibungen
- Kompetenznachweis für jede Rolle
- Kann eine Person mehrere Rollen innehaben?
- Rollenvorlagen und eine anpassbare RACI-Muster
- Rollenabdeckung in einen Personalplan umwandeln
- Was Implementierer bei Rollen falsch machen
- Quellen
Was ISO 27001 für Rollen tatsächlich verlangt
Abschnitt 5.3 legt die Verantwortung eindeutig beim Top-Management. Die Führung muss sicherstellen, dass Verantwortlichkeiten und Befugnisse für Sicherheitsrollen zugewiesen und kommuniziert werden, und muss jemanden benennen, der rechenschaftspflichtig für die Berichterstattung zur ISMS-Performance ist. Dieser zweite Punkt stolpert viele Implementierer: Der Abschnitt geht nicht nur um die Zuweisung von Aufgaben, sondern um die Schaffung einer direkten Verbindungslinie zur Führungsebene. Jemand muss dem Top-Management berichten, wie das ISMS tatsächlich funktioniert – nicht nur, dass es existiert.
Annex A 5.2 ergänzt Abschnitt 5.3, fokussiert jedoch auf die Control-Ebene. Er verpflichtet Organisationen, Informationssicherheitsrollen und -verantwortlichkeiten entsprechend ihren eigenen betrieblichen Bedürfnissen zu definieren und zuzuweisen – nicht nach einer generischen Vorlage. Ein Auditor, der diesen Control prüft, schaut nicht, ob Sie eine Rollenliste aus einem Leitfaden kopiert haben. Er prüft, ob die von Ihnen definierten Rollen tatsächlich zu den Risiken und Prozessen Ihrer Organisation passen.
Auditoren bewerten hier drei Aspekte: Zuweisung (gibt es einen dokumentierten Verantwortlichen für jede Aufgabe?), Kommunikation (wissen die Personen in diesen Rollen, dass sie sie innehaben?) und Befugnis (kann der Rolleninhaber tatsächlich die Entscheidungen treffen, die die Rolle erfordert, oder ist es ein Titel ohne Handlungsmacht?). Ein Control-Verantwortlicher, der kein Sanierungsbudget genehmigen kann, ist kein echter Control-Verantwortlicher.
Eine wissenswerte Flexibilität: ISO 27001 schreibt keine bestimmte Bezeichnung für Rollen vor. Sie können jemanden „Informationssicherheitskoordinator", „ISMS-Leitung" oder „Compliance-Beauftragter" nennen und den Standard gleichermaßen erfüllen – solange die zugrundeliegende Verantwortlichkeit dokumentiert und verstanden ist. Es zählt der Inhalt, nicht die Berufsbezeichnung auf der Visitenkarte.
Kernrollen in ISO 27001 und ihre Verantwortlichkeiten
Jedes ISMS benötigt eine kleine Anzahl abgedeckter Rollentypen – ob Sie ein 12-köpfiges Start-up oder ein multinationaler Konzern sind. Hier sehen Sie, was jede Rolle im Tagesgeschäft tatsächlich leistet.
Top-Management. Das ist keine zeremonielle Rolle. Die Führung legt die Informationssicherheitsleitlinie fest, akzeptiert formal Restrisiken, die außerhalb der Risikobereitschaft der Organisation liegen, und stellt das Budget und die Personalkapazität bereit, die das ISMS zum Funktionieren benötigt. Außerdem überprüfen sie die ISMS-Performance nach einem festgelegten Zeitplan – in der Regel im Rahmen eines Management-Reviews – und dieses Review muss dokumentierte Entscheidungen hervorbringen, nicht nur Besprechungsnotizen mit dem Vermerk „besprochen".
ISMS-Manager oder CISO. Diese Rolle, manchmal als Informationssicherheitsmanager bezeichnet, verantwortet das ISMS-Dokumentationspaket: die Erklärung zur Anwendbarkeit (Statement of Applicability), den Risikobehandlungsplan und die internen Richtlinien. Sie führen oder koordinieren Risikobewertungen, treiben die Control-Implementierung abteilungsübergreifend voran und berichten den Status an das Top-Management. In kleineren Unternehmen übernimmt diese Person oft auch den täglichen Sicherheitsbetrieb; in größeren ist es eine dedizierte Stelle mit einem Team darunter.
Asset-Owner versus System-Owner. Diese werden ständig verwechselt, und Auditoren bemerken es. Ein Asset-Owner ist verantwortlich für Klassifizierungs- und Schutzentscheidungen eines bestimmten Informations-Assets, etwa Kundendaten oder Quellcode-Repositories. Ein System-Owner ist für die technische Konfiguration, Zugangskontrollen und operative Sicherheit des Systems verantwortlich, das dieses Asset verarbeitet. Eine Datenbank kann einen fachlichen Verantwortlichen (Asset-Owner) haben, der entscheidet, wer Kunden-PII abfragen darf, und einen IT-Verantwortlichen (System-Owner), der die Firewall-Regeln und den Patch-Zeitplan konfiguriert. Diese Trennung ist besonders wichtig in Organisationen, in denen Fachbereich und IT tatsächlich als separate Funktionen agieren.
Risikoverantwortliche und Control-Verantwortliche. Ein Risikoverantwortlicher entscheidet, wie ein bestimmtes Risiko behandelt wird: akzeptieren, mindern, transferieren oder vermeiden. Ein Control-Verantwortlicher stellt sicher, dass der spezifische Control, der mit diesem Risiko verknüpft ist, tatsächlich implementiert wird und operativ bleibt. Diese können dieselbe Person sein, bei bereichsübergreifenden Risiken – etwa einem Lieferantenrisiko, das Einkauf, Recht und IT berührt – werden sie jedoch oft getrennt, damit die Verantwortlichkeit nicht zwischen Abteilungen verloren geht.
Interne Revision. Die interne Revision muss von den Abläufen, die sie prüft, unabhängig bleiben. Deshalb darf die Person, die einen Control auditiert, nicht dieselbe sein, die ihn betreibt. Interne Auditoren benötigen Kenntnisse der ISO 27001-Auditanforderungen, einen dokumentierten Auditplan und -zeitplan sowie eine Berichtslinie, über die Befunde das Top-Management ungefiltert erreichen – ohne dass die geprüfte Abteilung sie abmildern kann.
Alle Mitarbeitenden. Jede Mitarbeiterin und jeder Mitarbeiter trägt eine grundlegende Sicherheitsverantwortung: zugewiesene Schulungen absolvieren, vermutete Sicherheitsvorfälle umgehend melden und die Nutzungs- und Datenhandhabungsrichtlinien einhalten, die für ihre Rolle gelten. Dies ist die nach Köpfen größte Rollenkategorie und die, die am häufigsten schlecht dokumentiert wird – obwohl menschliches Versagen nach wie vor eine der häufigsten Ursachen von Sicherheitsvorfällen ist. Das macht die Verantwortlichkeit auf Mitarbeiterebene zu einer der wirkungsvollsten Rollen, die es richtig zu gestalten gilt.
Eine kurze Zusammenfassung, wer was verantwortet:
- Top-Management: Richtliniengenehmigung, Risikoakzeptanz, Ressourcenbereitstellung, Performance-Review.
- ISMS-Manager/CISO: Dokumentation, Koordination der Risikobewertung, Berichterstattung nach oben.
- Asset-Owner: Klassifizierung und Schutz eines bestimmten Informations-Assets.
- System-Owner: Technische Konfiguration und operative Sicherheit der Systeme, die das Asset verarbeiten.
- Risikoverantwortlicher: Behandlungsentscheidungen für zugewiesene Risiken.
- Control-Verantwortlicher: Implementierung und laufender Betrieb eines bestimmten Controls.
- Interner Auditor: Unabhängige Prüfung, Auditplanung, Befundberichterstattung.
- Alle Mitarbeitenden: Schulungsabschluss, Vorfallmeldung, Richtlinieneinhaltung.
Rollen dokumentieren: RACI-Matrizen und Stellenbeschreibungen
Eine Rolle, die nur im Gedächtnis einer Person existiert, existiert für Auditoren nicht. Sie muss schriftlich fixiert und einer Position statt einer Person zugeordnet sein, damit das Dokument Personalwechsel übersteht.
- Prozesse und Controls auflisten. Beginnen Sie mit Ihrer Erklärung zur Anwendbarkeit und Ihren wesentlichen Betriebsprozessen und arbeiten Sie sich zu einer granularen Liste vor – nicht „IT-Sicherheit", sondern „Endpoint-Patch-Management", „Lieferanten-Onboarding-Prüfung" und so weiter.
- Responsible, Accountable, Consulted, Informed für jeden Punkt zuordnen. Das ist der RACI-Schritt, und Praxisleitfäden empfehlen dieses Format einhellig, weil es Sie zwingt, genau eine rechenschaftspflichtige Partei pro Zeile zu benennen – was das Versagensmuster „alle dachten, jemand anderes ist verantwortlich" beseitigt.
Ihre Stellenbeschreibungen und ISMS-Handbucheinträge sollten jeweils den Zweck der Rolle, ihre spezifischen Aufgaben, die damit verbundene Befugnis (Budgetgenehmigungsgrenzen, Freigaberechte), die erforderliche Kompetenz sowie den Ablageort für Aktivitätsnachweise enthalten.
Auditoren werden nach Belegen fragen, dass die RACI die Realität abbildet: Kommunikationsnachweise, die zeigen, dass Personen über ihre Zuweisung informiert wurden, die Managementgenehmigung der Matrix selbst, Schulungsprotokolle je Rolle und Risikoakzeptanznachweise, die vom tatsächlichen Risikoverantwortlichen unterzeichnet sind – nicht von einer Vertretung ohne dokumentierte Befugnis.
Praxistipp: Führen Sie Ihre RACI-Matrix und Ihre Stelleninhaber-Liste in zwei getrennten Dateien. Aktualisieren Sie die Stelleninhaber-Liste am Tag, an dem jemand die Stelle wechselt; aktualisieren Sie die RACI-Matrix nur dann, wenn sich die Verantwortlichkeit selbst ändert. Die Vermischung beider Dokumente ist der häufigste Grund dafür, dass Auditnachweise veralten.
Kompetenznachweis für jede Rolle
Eine Rolle zuzuweisen reicht nicht. Sie benötigen Nachweise, dass die Person darin die Aufgabe tatsächlich bewältigen kann. Auditoren akzeptieren eine Mischung aus formalen Qualifikationen und betrieblichen Nachweisen: Zertifizierungen wie CISSP oder CISM für Sicherheitsführungsrollen, ISO 27001 Lead Implementer- oder Lead Auditor-Qualifikationen für ISMS-Manager und interne Auditoren sowie dokumentierte Berufserfahrung für engere operative Rollen wie Control-Verantwortliche.
Entwickeln Sie rollenspezifische Schulungen mit einem Auffrischungszyklus – mindestens jährlich für Policy-Awareness, häufiger für technische Rollen in den Bereichen Zugriffskontrolle oder Incident Response. Dokumentieren Sie jede festgestellte Lücke und die ergriffene Abhilfemaßnahme. Stellenausschreibungen für ISO 27001-Implementierungsleitungen beschreiben typischerweise Zertifizierungsprojektzeiträume von sechs bis neun Monaten – das liefert Ihnen einen realistischen Richtwert dafür, wie viel Vorlauf eine neu zugewiesene Rolle bis zur Auditreife benötigt.
Kann eine Person mehrere Rollen innehaben?
Ja, und in kleinen Organisationen ist das normal. Ein ISMS-Manager, der gleichzeitig als IT-Manager fungiert, ist ein gängiges, vertretbares Setup – solange das Risiko der Aufgabentrennung dokumentiert und nicht ignoriert wird.
Die Grenze, die Auditoren ziehen, betrifft unabhängigkeitssensible Kombinationen. Ein interner Auditor, der gleichzeitig die Controls betreibt, die er prüfen soll, ist die klassische problematische Paarung, da sie die Objektivität aufhebt, die die Rolle gewährleisten soll. Ein Control-Verantwortlicher, der seine eigenen Risikoausnahmen genehmigt, läuft in dasselbe Problem.
Wenn eine Konsolidierung unvermeidbar ist, dokumentieren Sie einen kompensierenden Control: einen unabhängigen Zweitprüfer, eine vierteljährliche Managementkontrolle der Entscheidungen der kombinierten Rolle oder einen externen Auditor für den spezifischen Bereich, in dem interne Unabhängigkeit nicht gewährleistet werden kann. Dokumentieren Sie den Genehmigungsnachweis für diesen kompensierenden Control genauso wie die Rollenzuweisung selbst.
Rollenvorlagen und eine anpassbare RACI-Muster
Jede Rollenbeschreibung sollte fünf Elemente umfassen: Zweck (warum die Rolle existiert), Aufgaben (was sie tut), Befugnis (was sie genehmigen oder blockieren kann), Kompetenz (was jemanden qualifiziert, sie innezuhaben) und Nachweise (wo Belege ihrer Aktivität abgelegt werden).
Für Audit-Checklisten benötigen die meisten Rollen drei bis fünf Prüfpunkte: eine dokumentierte Zuweisung, Nachweis der Kommunikation an den Rolleninhaber, mindestens einen Beleg für die Ausübung der Rolle, Schulungs- oder Kompetenznachweise sowie einen Management-Review-Verweis, der zeigt, dass die Ergebnisse der Rolle die Führungsebene erreicht haben.
| Control-Bereich | Verantwortlich (R) | Rechenschaftspflichtig (A) | Konsultiert (C) | Informiert (I) |
|---|---|---|---|---|
| Zugriffsprüfung | System-Owner | ISMS-Manager | IT-Manager | Interne Revision |
| Risikobehandlungsplan | Risikoverantwortlicher | Top-Management | ISMS-Manager | Control-Verantwortliche |
| Incident Response | Incident Manager | ISMS-Manager | Recht, HR | Alle Mitarbeitenden |
Diese Struktur funktioniert für jeden Control-Satz, sobald Sie Ihre eigenen Prozessbezeichnungen einsetzen – einschließlich der in einer vollständigen Zertifizierungs-Checkliste behandelten.
Rollenabdeckung in einen Personalplan umwandeln
Rollen auf dem Papier zu definieren ist eine Übung. Herauszufinden, wie viele Personen, Stunden und Kosten diese Rollenabdeckung tatsächlich verursacht, ist eine andere – und hier unterschätzen die meisten Implementierer das Projekt. Readiness-Tools können das Rollen- und Reifebild, das Sie gerade erstellt haben, in eine konkrete Aufwandsschätzung umwandeln.
Einige Kalkulatoren passen ihre Ausgabe anhand weniger Eingaben an, die direkt auf die Rollenabdeckung zurückzuführen sind:
- Unternehmensgröße, die beeinflusst, wie viele Personen rollenspezifische Schulungen benötigen im Vergleich zu einem einzigen kombinierten ISMS-Verantwortlichen.
- Branche, da regulierte Sektoren typischerweise eine stärkere Trennung zwischen Risikoverantwortlichen und Control-Verantwortlichen erfordern.
- Aktuelle Sicherheitsreife über die vier bewerteten Annex A-Control-Themen, die bestimmt, wie viel Ihrer Rollenstruktur bereits vorhanden ist im Vergleich zu dem, was neu aufgebaut werden muss.
Das Ergebnis lässt sich direkt in Planungsbegriffe übersetzen: eine empfohlene Rollenanzahl für Ihre Größe und Branche, ein geschätztes Schulungsbudget, das an die Zertifizierungen und Kompetenznachweise dieser Rollen geknüpft ist, sowie ein in Implementierungsphasen gegliederter Zeitplan in einer Gantt-Ansicht. Sie können ein Szenario speichern, eine Variable wie die Mitarbeiterzahl anpassen und die resultierende Personalverschiebung nebeneinander vergleichen – dann die Schätzung als PDF für Planungsgespräche exportieren.
Praxistipp: Führen Sie den kostenlosen 2-Minuten-Readiness-Check vor Ihrem ersten Management-Review durch. Er liefert Ihnen eine grobe Rollenabdeckungslücke, die Sie mit in die Besprechung nehmen können – anstatt mit einer offenen Budgetanfrage hineinzugehen.
Was Implementierer bei Rollen falsch machen
Dieselben drei Fehler tauchen in fast jedem gescheiterten Auditbefund zu Rollen auf. Eine RACI-Matrix, die seit ihrer Erstellung vor zwei Jahren nicht mehr angefasst wurde. Verantwortlichkeiten, die gegen den Namen einer Person statt gegen eine Position geschrieben sind, sodass das Dokument in dem Moment bricht, in dem jemand das Unternehmen verlässt. Und Schulungsunterlagen, die für den ISMS-Manager existieren, aber nirgendwo sonst – was die Rolle „Alle Mitarbeitenden" undokumentiert lässt, obwohl sie den Großteil des menschlichen Fehlerrisikos trägt.
Beheben Sie diese drei Punkte zuerst. Sie sind am kostengünstigsten zu korrigieren und verursachen die meisten Befunde. Führen Sie dann eine Readiness-Bewertung durch, um zu sehen, wo Ihre aktuelle Rollenstruktur tatsächlich im Vergleich zum Branchenmaßstab steht – bevor ein externer Auditor es Ihnen mitteilt.
— Martin
Quellen
- ISO-Normenübersicht (ISO)
- ISO 27001 Annex A 5.2 Rollen und Verantwortlichkeiten + Vorlage (HighTable)
- ISO 27001-Sicherheitsrollen und Verantwortlichkeiten (Risk3Sixty)
- IAPP: Daten zeigen menschliches Versagen als häufigste Ursache von Datenschutzverletzungen und Vorfällen