Prozessmanagement als Brücke zur Regulatorik

DORA und MaRisk integrieren statt doppelt dokumentieren

DORA und MaRisk erzeugen keinen Mehrwert, wenn Anforderungen in separaten Listen, Kontrollkatalogen und Einzelkonzepten verwaltet werden, ohne dass ihre operative Umsetzung nachvollziehbar ist. Entscheidend ist die Verbindung zum tatsächlichen Ablauf: Welcher Prozess ist betroffen? Welche Rolle handelt? Welche Kontrolle greift? Welches System oder welcher Dienstleister ist eingebunden?

Genau hier wird Prozessmanagement zur Brücke zwischen Fachbereich, IKT, Risikomanagement, Informationssicherheit und Governance sowie Regulatorik.

DORA verlangt unter anderem eine wirksame Governance für IKT-Risiken, einen IKT-Risikomanagementrahmen, Prozesse für die Behandlung von IKT-Vorfällen sowie ein angemessenes Management von IKT-Drittdienstleistungsrisiken. MaRisk fordert eine angemessene Aufbau- und Ablauforganisation, dokumentierte Organisationsrichtlinien, eine ausreichende technisch organisatorische Ausstattung sowie geregelte Anpassungs- und Auslagerungsprozesse.

Nicht noch ein Dokument, sondern ein gemeinsamer Bezugspunkt

In der Praxis liegen regulatorische Inhalte oft an verschiedenen Stellen:

Risiken im Risikoinventar
Kontrollen in Kontrollbeschreibungen
Rollen in Organisationshandbüchern
IKT-Systeme in technischen Übersichten
Dienstleisterinformationen in Auslagerungs- oder Vertragsakten
Notfallmaßnahmen in Notfallkonzepten
Prozessabläufe im Modellierungstool

Jedes dieser Dokumente hat seinen Zweck. Problematisch wird es, wenn die Verbindungen fehlen. Dann bleibt bei einer Prüfung, einem Vorfall oder einer wesentlichen Änderung offen, welche Prozesse, Kontrollen, Systeme und Verantwortlichkeiten tatsächlich betroffen sind.

Ein belastbares Prozessmodell ersetzt diese Artefakte nicht. Es schafft aber den gemeinsamen Ordnungsrahmen, in dem sie sinnvoll zugeordnet und miteinander verknüpft werden können.

Was gehört an den Prozess?

Nicht jede regulatorische Vorgabe muss vollständig in einem Prozessdiagramm stehen. Das würde Modelle überladen und ihre Nutzbarkeit einschränken.

Sinnvoll ist vielmehr eine klare Zuordnung der steuerungsrelevanten Elemente:

Prozess und Teilprozess: Wo wird eine Anforderung operativ umgesetzt?
Rolle und Verantwortung: Wer führt aus, wer entscheidet, wer überwacht?
Risiko: Welches operationelle, IKT bezogene oder Compliance Risiko besteht?
Kontrolle: Welche Prüfung, Freigabe oder Überwachung begrenzt das Risiko?
System und Daten: Welche Anwendung, Information oder Schnittstelle ist wesentlich?
Dienstleister: Wo wird eine externe Leistung genutzt und wer steuert sie intern?
Nachweis und Regelwerk: Wo sind Detailanforderungen, Arbeitsanweisungen oder Kontrollnachweise hinterlegt?

So bleibt das Prozessmodell verständlich. Gleichzeitig wird sichtbar, an welcher Stelle eine Anforderung tatsächlich wirksam werden muss.

Beispiel: IKT-Vorfälle steuern, statt nur melden

Nehmen wir den Prozess „IKT-Vorfälle managen“.

Ein Diagramm, das lediglich die Schritte „Vorfall aufnehmen“, „bewerten“ und „melden“ enthält, beschreibt einen Ablauf. Für eine belastbare Steuerung braucht es mehr:

Wer darf oder muss einen Vorfall klassifizieren? Und welche Vorgaben gelten dabei?
Wer entscheidet über Eskalation und externe Meldungen?
Welche Informationen müssen aus Fachbereich, Informationssicherheit, IT-Betrieb und Risikomanagement zusammengeführt werden?
Welche Zeitvorgaben und Eskalationswege gelten?
Wie werden Erkenntnisse aus dem Vorfall in Kontrollen, Notfallvorsorge oder technische Maßnahmen zurückgeführt?
Welche Abhängigkeiten zu externen IKT-Dienstleistern bestehen?

DORA fordert unter anderem einen Prozess zur Erkennung, Behandlung und Klassifizierung von IKT bezogenen Vorfällen sowie Verfahren für die Meldung schwerwiegender Vorfälle. Damit diese Anforderungen nicht abstrakt bleiben, müssen sie sich in Rollen, Entscheidungswegen, Schnittstellen und Nachweisen des konkreten Prozesses wiederfinden.

Besonders wichtig: Schnittstellen und externe Leistungen

Regulatorische Schwächen entstehen häufig nicht innerhalb eines einzelnen Arbeitsschritts, sondern an Übergaben: zwischen Fachbereich und IT, zwischen erster und zweiter Linie oder zwischen Institut und Dienstleister.

Gerade bei extern erbrachten IKT-Leistungen sollte das Prozessmodell daher sichtbar machen:

welche Leistung extern bezogen wird
welcher interne Prozess darauf angewiesen ist
welche Rolle den Dienstleister steuert
welche Qualitäts-, Informations- und Eskalationspflichten bestehen
welche Ausweich- oder Notfallmaßnahmen greifen, wenn die Leistung ausbleibt

Die Verantwortung für eine ausgelagerte oder extern bezogene Leistung bleibt nicht beim Dienstleister. MaRisk betont, dass Auslagerungen nicht zu einer Delegation der Verantwortung der Geschäftsleitung führen dürfen. DORA verlangt zudem, Risiken aus IKT-Drittdienstleistungen als Teil des IKT-Risikomanagementrahmens zu steuern.

Änderungen gezielt bewerten

Der Nutzen einer verknüpften Prozessarchitektur zeigt sich besonders bei Veränderungen.

Ein neues Kernbanksystem, eine Anpassung im Meldewesen, ein neuer Dienstleister oder eine geänderte regulatorische Anforderung betreffen selten nur ein einzelnes Dokument. Mit einer sauber gepflegten Zuordnung lässt sich strukturiert prüfen:

Welche Prozesse und Prozessschritte ändern sich?
Welche Rollen und Kompetenzen sind betroffen?
Entstehen neue Risiken oder Kontrollanforderungen?
Müssen Dienstleistervereinbarungen, Notfallregelungen oder Arbeitsanweisungen angepasst werden?
Welche Nachweise und sonstigen Dokumente sind zu aktualisieren?

MaRisk sieht für Änderungen betrieblicher Prozesse oder Strukturen angemessene Anpassungsprozesse vor. Ein Prozessmodell mit belastbaren Verknüpfungen erleichtert es, die Auswirkungen einer Änderung vollständig und nachvollziehbar zu erfassen.

Keine Doppelpflege, aber klare Pflegeverantwortung

Die Verknüpfung verschiedener Steuerungsobjekte bedeutet nicht, alles mehrfach zu dokumentieren. Sie verlangt vielmehr eine bewusste Entscheidung darüber, wo die führende Information gepflegt wird.

Beispielsweise kann:

das Prozessmodell den Ablauf, die Rollen und die Schnittstellen führen
das Risikoinventar die Risikobewertung führen
das Kontrollsystem die Ausgestaltung und Durchführung von Kontrollen führen
das IKT Asset Management technische Details führen
die Dienstleistersteuerung Vertrags, Leistungs- und Überwachungsinformationen führen

Entscheidend ist, dass diese Inhalte über eindeutige Referenzen verbunden sind und dass für jede Pflegeaufgabe eine verantwortliche Rolle benannt ist.

Fazit

Gutes Prozessmanagement macht Regulatorik nicht kleiner. Aber es macht sie beherrschbarer.

Wer DORA und MaRisk in einer gemeinsamen Prozessarchitektur verankert, schafft Transparenz über die tatsächliche Umsetzung regulatorischer Anforderungen.

Risiken, Kontrollen, Rollen, Systeme und Dienstleister werden nicht isoliert betrachtet, sondern im Zusammenhang mit dem Ablauf, in dem sie wirksam sein müssen.

So wird aus einer Vielzahl regulatorischer Dokumente ein steuerbares Gesamtbild.

Damit endet unsere Reihe zum Prozessmanagement.

Von der Prozesslandkarte über typische Modellierungsfehler bis zu Rollen, Verantwortlichkeiten und regulatorischer Anschlussfähigkeit zeigt sich ein roter Faden: Prozesse entfalten ihren Nutzen nicht durch ihre Darstellung, sondern durch ihre Nutzung in der Steuerung.