Die Sache mit der Verantwortlichkeit – wenn niemand „Owner“ sein will

VonJulian Bednara

Ein Satz, den ich regelmäßig höre…

„Dafür bin ich nicht zuständig.“
Manchmal klingt es wie eine Verteidigung. Manchmal wie ein Reflex. Und manchmal ist es einfach ehrlich gemeint – aber das macht es nicht besser.

In vielen Projekten zur Informationssicherheit stoße ich genau an diesem Punkt auf Widerstand. Nicht laut. Nicht kämpferisch. Sondern eher als Leerstelle. Niemand fühlt sich zuständig. Oder besser: Niemand will zuständig sein.
Ob es um ein Risikoregister geht, um Business-Impact-Analysen oder die Pflege eines Maßnahmenplans – es bleibt zu oft unklar, wer das Thema wirklich trägt.

Gerade in kleinen und mittleren Unternehmen, wo viele Themen „nebenbei“ laufen, sind ISMS Verantwortlichkeiten oft ein heißes Pflaster. Denn wer als Owner im ISMS gilt, soll auch liefern – und genau das schreckt oft ab.

Diese Beobachtung ist nicht neu. Aber sie bleibt aktuell. Und sie verdient einen genaueren Blick.

Warum das immer wieder passiert

Eigentlich ist es eine einfache Frage: Wer ist dafür verantwortlich?
 Doch in der Realität erlebe ich immer wieder, wie genau diese Frage für betretenes Schweigen sorgt. Oder für Diskussionen, die an der Sache vorbeigehen.

Was auf den ersten Blick wie ein Abstimmungsproblem wirkt, ist in Wahrheit ein strukturelles Muster in der ISMS Rollenverteilung – besonders in Organisationen, in denen Informationssicherheit kein fester Bestandteil der Unternehmenskultur ist. Oft ist nicht klar, wer welche Rolle spielt. Oder schlimmer: Die Rollen existieren nur auf dem Papier.

Ein paar typische Konstellationen:

  • IT sagt: „Das ist eher was für Compliance.“
  • Compliance sagt: „Das betrifft doch die IT.“
  • Geschäftsführung sagt: „Dafür haben wir doch jemanden.“
  • Und dieser jemand sagt: „Davon höre ich gerade zum ersten Mal.“

Hinter dieser Unklarheit steckt selten böser Wille. Viel häufiger ist es eine Mischung aus:

  • Unsicherheit: Was bedeutet „Owner sein“ eigentlich?
  • Angst: Wer Verantwortung übernimmt, muss auch liefern – oder fürchtet rechtliche oder persönliche Haftung. Gerade im Kontext von Datenschutz (DSGVO) oder IT-Risiken kann unklare Verantwortlichkeit zu ernsthaften Konsequenzen führen, z. B. bei Verstößen gegen Art. 32 DSGVO (Sicherheit der Verarbeitung).
  • Überlastung: Zwischen Alltagsgeschäft, Projekten und Meetings bleibt kaum Luft für „zusätzliche“ Themen.
  • Fehlende Kommunikation: Es wird erwartet, aber nicht besprochen.

Das Problem ist: Wenn ISMS Verantwortlichkeiten nicht klar geregelt sind, übernimmt niemand Verantwortung – und es wird nichts entschieden. Risiken bleiben unbeachtet. Maßnahmen werden aufgeschoben. Und das ISMS oder BCM entwickelt sich zum Papiertiger – schön anzusehen, aber nutzlos in der Praxis.

Diese Leerstelle ist gefährlich. Denn unklare Verantwortlichkeiten in der Informationssicherheit untergraben nicht nur die Wirksamkeit der Sicherheitsmaßnahmen, sondern auch das Vertrauen in das gesamte System.

Deshalb lohnt es sich, genauer hinzuschauen: Wie kann Verantwortung entstehen – ohne Überforderung?

Was in der Praxis wirklich hilft

Verantwortung lässt sich nicht zuweisen wie ein Paket mit Lieferschein. Sie muss wachsen – aus Klarheit, Relevanz und Vertrauen. Genau das versuche ich in Projekten anzustoßen. Nicht mit neuen Stellenbeschreibungen oder großen Reorganisationen, sondern mit einfachen, manchmal fast banalen Fragen:

  • „Wer würde es merken, wenn das schiefläuft?“
  • „Wer muss als Erstes reagieren?“
  • „Wer hat den größten Einfluss darauf, dass es funktioniert?“

Diese Fragen bringen oft mehr Klarheit als jede Matrix. Denn sie orientieren sich nicht an Abteilungen, sondern an Wirkung.

Ein Beispiel aus einem Kundenprojekt:
Es ging um das Thema Schwachstellenmanagement. IT-Sicherheit war „irgendwie“ die Aufgabe des Systemadministrators. Doch der wusste weder, welche Systeme geschäftskritisch sind, noch welche Updates wann genehmigt werden müssen. Die Fachbereiche hingegen wollten keine Verantwortung übernehmen – schließlich „verstehen sie ja nichts von Technik“. Ergebnis: Niemand fühlte sich verantwortlich, Updates blieben aus, Risiken stauten sich.

Statt die Rollen künstlich neu zu verteilen, haben wir das Problem gemeinsam sichtbar gemacht – mit einem einfachen Wirkmodell:
Wer kennt die Systeme? Wer entscheidet über Änderungen? Wer trägt die Konsequenzen?
So ergab sich die Verantwortlichkeit nicht aus dem Organigramm, sondern aus der Praxis. Plötzlich war klar: Der Admin ist nicht der „Owner“, sondern Umsetzer. Die eigentliche Verantwortung liegt beim Fachbereich – weil dort entschieden wird, was kritisch ist.

Was ebenfalls hilft:

  • Einfach visualisieren: RACI-Modelle, aber nicht als PowerPoint-Monster – sondern auf einem Whiteboard, gemeinsam skizziert.
  • Szenarien durchspielen: „Was passiert, wenn…?“ ist oft wirksamer als „Wer ist zuständig für…?“
  • Ownership ermöglichen: Verantwortung braucht Handlungsspielraum – und Rückendeckung von oben. Wer immer nur melden, aber nie entscheiden darf, wird nie wirklicher Owner.

Wichtig ist: Verantwortung ist nicht immer eine Frage der Hierarchie, sondern oft der Nähe zur Realität. Die besten „Owner“ sind oft nicht die mit dem größten Titel, sondern die mit dem größten Praxisbezug.

Und: Verantwortung darf nicht nur ein Risiko sein, sondern auch ein Gestaltungsspielraum. Wer sich verantwortlich fühlt, will gestalten. Aber nur, wenn er oder sie das auch darf.

Was ich gelernt habe:
Verantwortung entsteht nicht durch Zuweisung, sondern durch Relevanz. Wenn Menschen verstehen, warum sie wichtig sind – und spüren, dass ihre Rolle gesehen wird – dann übernehmen sie Verantwortung. Aus sich heraus. Und das ist die stärkste Form von Ownership, die ein ISMS oder BCM haben kann.

Drei Dinge, die Du mitnehmen kannst

1. Verantwortung braucht Kontext.
 „Owner“ zu sein ist kein Titel, sondern eine Rolle im Zusammenspiel. Wer betroffen ist, Einfluss hat und die Folgen tragen muss, sollte auch Verantwortung übernehmen – aber mit Klarheit und Handlungsspielraum.

2. Rollenklärung ist keine einmalige Übung.
 Verantwortlichkeiten verändern sich mit Projekten, Personalwechseln oder neuen Anforderungen. Was heute funktioniert, kann morgen schon wieder offen sein. Deshalb: regelmäßig reflektieren und nachjustieren.

3. Sichtbarkeit schlägt Formalismus.
 Eine sauber gepflegte Rollenmatrix bringt wenig, wenn niemand sich angesprochen fühlt. Viel wirksamer ist eine offene Diskussion: Wer entscheidet was? Wer hat Zugriff? Wer trägt welches Risiko?

Was Du konkret tun kannst:

  • In Projekten und Routinen regelmäßig fragen: „Wer ist hier der Owner – und weiß diese Person das auch?“
  • Bei Unsicherheiten lieber klein starten: mit einem Prozess, einer Maßnahme, einem klaren Szenario.
  • Verantwortung ermöglichen, nicht erzwingen – durch Vertrauen, Rückhalt und gemeinsame Reflexion.

Wie ist das bei Euch?

  • Welche Themen bleiben bei Euch immer wieder ohne klaren Owner?
  • Wie sichtbar sind Verantwortlichkeiten in Eurem Alltag?
  • Was würde passieren, wenn jemand kurzfristig ausfällt – wäre die Verantwortlichkeit trotzdem klar?

Wenn Dir das bekannt vorkommt: Es gibt Wege, das aufzulösen – ohne Schuldzuweisung, aber mit Wirkung.

Praktisches Beispiel: RACI-Matrix zum Einstieg

Wenn Du Dir unter einer RACI-Matrix noch wenig vorstellen kannst – kein Problem. Ich habe ein kompaktes Beispiel vorbereitet, das zeigt, wie typische Verantwortlichkeiten in einem Informationssicherheitskontext aussehen können.

Das Beispiel zeigt:

  • Welche Rollen typischerweise beteiligt sind (z. B. IT, Geschäftsführung, Fachbereich)
  • Wie sich Zuständigkeiten (Responsible), Verantwortung (Accountable), Mitwirkung (Consulted) und Information (Informed) verteilen
  • Warum eine solche Übersicht oft mehr Klarheit bringt als seitenlange Aufgabenlisten

Hier geht’s zur Beispiel-RACI-Matrix als Excel-Download:
RACI-Beispiel öffnen (Link bitte durch tatsächlichen Dateipfad oder internen Download ersetzen)

Wenn Du so etwas für Dein Unternehmen adaptieren möchtest, reicht oft schon ein Whiteboard oder ein Excel-Blatt – entscheidend ist nicht die Form, sondern das gemeinsame Verständnis.

Was Du jetzt tun kannst

Quick-Check:
Gibt es Prozesse oder Themen, die immer wieder „zwischen den Stühlen“ landen?
Ist klar dokumentiert, wer wofür verantwortlich ist?
Hat der „Owner“ auch die Befugnis, Entscheidungen zu treffen?

Regekwerksbezug: Relevanz u. a. aus ISO 27001:2022 (A.5.1, A.6.1.1), DSGVO Art. 32 und NIS2 Art. 21 – alle fordern klare, dokumentierte Verantwortlichkeiten für Informationssicherheit.

Starte mit einem einfachen RACI-Board oder Whiteboard-Session, um Verantwortlichkeiten sichtbar zu machen – ohne Excel-Monster oder Meetings, die im Sande verlaufen.

Hinweis zur Einordnung

Dieser Erfahrungsartikel basiert auf realen Beobachtungen und typischen Praxismustern. Die beschriebenen Maßnahmen können Orientierung bieten – sie ersetzen jedoch keine vollständige Umsetzung regulatorischer Anforderungen (z. B. gemäß NIS2, ISO 27001 oder branchenspezifischer Standards).
Wenn Dein Unternehmen unter die NIS2-Richtlinie fällt, sind zusätzliche strukturierte Analysen, dokumentierte Verfahren und ein systematischer Aufbau der Sicherheitsorganisation erforderlich.

Ähnliche Beiträge