Braucht jede Rolle eine eigene Person?

Nicht grundsätzlich. In kleinen Teams können Personen mehrere Rollen übernehmen. Befugnisse und nötige unabhängige Prüfungen müssen trotzdem klar bleiben.

Ist die Administration auch für Risikoentscheidungen zuständig?

Technische Administratorrechte sind keine fachliche Entscheidungsbefugnis. Legt gesondert fest, wer Risiken beurteilen und über die Behandlung entscheiden darf.

Wie lässt sich Kopexa vor der Einführung testen?

Kopexa bietet eine begleitete Testphase von zwei Wochen. Wählt einen eigenen Prüffall und erprobt den Arbeitsablauf mit den beteiligten Personen. Im Erstgespräch wird der Testbedarf besprochen.

GRC-Software einführen: Wer übernimmt welche Verantwortung?

Bei der Einführung einer GRC-Software sollte für jedes wichtige Ergebnis feststehen, wer es fachlich verantwortet, wer daran arbeitet und wer entscheiden darf. Ein Benutzerkonto oder ein Name an einer Aufgabe ersetzt diese Klärung nicht.

Beginnt mit einem Arbeitsablauf, den ihr im Alltag braucht. Zum Beispiel: Eine offene Anforderung wird bewertet, eine Maßnahme zugeordnet und ihre Umsetzung mit einem Nachweis geprüft. An diesem Ablauf erkennt ihr, welche Rollen fehlen.

Was muss vor der Einrichtung geklärt sein?

Legt fest, welches Problem die Einführung zuerst lösen soll. Wollt ihr Nachweise verlässlich finden, Risiken behandeln oder mehrere Gesellschaften gemeinsam steuern? Ohne diese Entscheidung wird jede vorhandene Tabelle zum vermeintlich notwendigen Import.

Haltet drei Dinge fest: den ersten Anwendungsfall, die beteiligten Teams und das Ergebnis, an dem ihr den Einstieg bewertet. „Software eingerichtet“ ist dafür zu wenig. „Die verantwortliche Person kann eine offene Maßnahme bis zum geprüften Nachweis verfolgen“ ist konkreter. Bei der Auswahl hilft ein Anforderungskatalog für eure ISMS-Software.

NIST CSF 2.0 fordert in GV.RR klar etablierte und kommunizierte Verantwortlichkeiten und Befugnisse. Auch die Bereitstellung angemessener Ressourcen gehört dazu. Das folgende Rollenmodell ist unsere praktische Umsetzungshilfe, keine von NIST vorgeschriebene Projektorganisation. NIST CSF 2.0

Welche Rollen braucht die Einführung?

Rolle	Verantwortet insbesondere	Darf nicht stillschweigend vorausgesetzt werden
Auftraggeber aus der Leitung	Ziel, Prioritäten, Ressourcen und Eskalationsweg	Dass das Projekt neben dem Tagesgeschäft ohne Kapazität gelingt
Fachliche ISMS-/GRC-Verantwortung	Begriffe, Methoden, Arbeitsabläufe und fachliche Abnahme	Dass jede operative Aufgabe bei dieser Person landet
Prozess- oder Informationsverantwortliche	Fachliche Angaben, Auswirkungen und passende Behandlung im eigenen Bereich	Dass die IT die geschäftliche Bedeutung allein beurteilt
Maßnahmenverantwortliche	Umsetzung, Status und erforderliche Belege	Dass ein Abschlussstatus bereits geprüfte Wirksamkeit bedeutet
Technische Administration	Zugänge, technische Anbindungen und abgestimmte Berechtigungen	Dass Adminrechte auch Risikoentscheidungen erlauben
Projektkoordination	Termine, Abhängigkeiten, offene Fragen und Übergabe	Dass Koordination fachliche Entscheidungen ersetzen kann

In kleinen Unternehmen kann eine Person mehrere Rollen übernehmen. Haltet trotzdem fest, in welcher Rolle sie handelt. Wo eine unabhängige Prüfung erforderlich ist, muss die Rollenverteilung diese ermöglichen.

Trenne Projektaufgaben vom späteren Betrieb

Übertragt die Rollen auf einzelne Aufgaben. Diese Beispielmatrix ist ein Startpunkt, keine gesetzliche Zuständigkeitsverteilung:

Aufgabe	Entscheidungsverantwortlich	Ausführend	Prüfend	Informiert
Pilotumfang festlegen	Auftraggeber	Projektkoordination	Fachliche GRC-Verantwortung	Beteiligte Teams
Fachliche Daten übernehmen	Verantwortliche des Datenbereichs	Migrationsverantwortliche	Fachkundige prüfende Person	GRC-Verantwortung
Technische Maßnahme umsetzen	Zuständige Bereichsverantwortung	Betrieb	Für die Abnahme benannte Person	ISMS-Verantwortung
Betrieb übernehmen	Fachliche GRC-Verantwortung	Künftige Verantwortliche	Auftraggeber anhand der vereinbarten Abnahme	Anwender und Support

Während der Einführung müssen Daten übernommen, Begriffe vereinheitlicht und Zugriffe eingerichtet werden. Für bestehende Tabellen beschreibt unser Leitfaden zur Migration von Excel ins ISMS, wie ihr die Übernahme vorbereitet. Nach dem Start braucht ihr andere Routinen: neue Mitarbeitende einweisen, Zuständigkeiten bei Wechseln ändern und fachliche Angaben überprüfen.

Erstellt deshalb zu jeder einmaligen Aufgabe die passende Betriebsfrage:

Import: Wer pflegt neue und geänderte Datensätze nach dem Start?
Berechtigungen: Wer prüft einen Wechsel der Funktion oder Organisationseinheit?
Richtlinien: Wer bearbeitet eine neue Version und wer gibt sie frei?
Kennzahlen: Wer prüft, ob die Datenquelle weiterhin vollständig und richtig liefert?
Maßnahmen: Wer übernimmt Vertretung und Eskalation bei ausbleibender Bearbeitung?

Eine Übergabe ist erst brauchbar, wenn diese Personen ihren Ablauf kennen und tatsächlich ausführen können.

Beispiel: Die Plattform ist fertig, die Arbeit bleibt liegen

Fiktiver Fall: Ein Unternehmen importiert seine Maßnahmenliste. Alle Einträge haben Termine. Als Verantwortlicher steht überall der Informationssicherheitsbeauftragte.

Beim Pilotlauf zeigt sich: Für technische Änderungen braucht es den Betrieb, für Lieferantennachweise den Einkauf und für Richtlinien die jeweiligen Fachbereiche. Der ISB kann die Arbeit koordinieren, aber nicht jede Maßnahme selbst umsetzen oder freigeben.

Das Team ordnet die Umsetzung den zuständigen Personen zu und klärt den Eskalationsweg. Anschließend prüft es mit einer echten Maßnahme, ob Rückfragen, Nachweis und fachliche Prüfung bis zum Abschluss funktionieren. Erst dieser Ablauf zeigt, ob die neue Verteilung trägt.

Prüfe die Zuständigkeit an einem vollständigen Fall

Nehmt einen überschaubaren, bereinigten Fall und geht ihn gemeinsam durch. Wie ihr diesen Versuch eingrenzt und auswertet, zeigt der Leitfaden zum ISMS-Pilotprojekt:

Wer erkennt den Handlungsbedarf?
Wer beurteilt seine Bedeutung?
Wer entscheidet über den nächsten Schritt und die nötige Kapazität?
Wer setzt die Maßnahme um und stellt den Nachweis bereit?
Wer prüft das Ergebnis?
Wer handelt, wenn das Ergebnis nicht ausreicht oder der Termin verstreicht?

Notiert jede Stelle, an der eine Antwort fehlt. Das sind Aufgaben für die Einführung, keine Gründe für weitere Pflichtfelder.

Wie ihr den Einstieg mit Kopexa prüfen könnt

Kopexa bietet eine begleitete Testphase von zwei Wochen. Nutzt sie, um einen solchen Ablauf mit den tatsächlich beteiligten Personen zu prüfen.

In Kopexa liegen Nachweise an Maßnahmen, die auf Controls gemappt werden. Für Richtlinien lassen sich Dokumentversionen mit Freigaben und die Verteilung über den Workforce Hub betrachten. Den vollständigen Arbeitsweg erklärt der Beitrag zu Richtlinienversionen, Freigabe und Kenntnisnahme. Wählt für den Test den Ablauf, der euer aktuelles Problem am besten abbildet.

Entscheidend ist, ob euer Team damit arbeiten kann: Finden die Beteiligten ihre Aufgabe? Wissen sie, was als Nachweis erwartet wird? Bleibt nach einer Rückfrage klar, wer weiterarbeitet?

Was gehört in die Übergabe?

Haltet den produktiven Anwendungsfall, die zuständigen Personen samt Vertretung, offene Grenzen und den ersten gemeinsamen Überprüfungstermin fest. Dokumentiert auch, welche Daten oder Bereiche noch nicht übernommen wurden.

Damit endet die Einführung nicht beim Import. Sie endet dort, wo das Team den vereinbarten Ablauf eigenständig weiterführen kann.