DORA-Sandboxen helfen Finanzunternehmen, digitale Prozesse kontrolliert zu testen – ersetzen aber weder Compliance noch Aufsicht.

Im DORA-Rahmen kann eine Sandbox Banken und Finanzunternehmen dabei helfen, neue digitale Prozesse kontrolliert zu erproben, bevor sie umfassend eingesetzt werden. Sie schafft einen abgegrenzten Testbereich, in dem sich Risiken, Kontrollen und Verantwortlichkeiten anhand konkreter Szenarien prüfen lassen. Eine Sandbox ersetzt weder die Anforderungen der EU-Verordnung über die digitale operationale Resilienz im Finanzsektor (DORA) noch die Aufsicht durch zuständige Behörden. Sie unterstützt Unternehmen vielmehr dabei, ihre Lösungen nachvollziehbar zu entwickeln und belastbare Nachweise für ihre Entscheidungen zu erstellen.

DORA gilt seit dem 17. Januar 2025 und verpflichtet erfasste Finanzunternehmen, Risiken der Informations- und Kommunikationstechnologie (IKT) systematisch zu steuern. Dazu gehören unter anderem ein IKT-Risikomanagement, die Meldung schwerwiegender IKT-Vorfälle, Tests der digitalen operationalen Resilienz sowie die Überwachung von Risiken aus der Nutzung von IKT-Drittdienstleistern. Die Verordnung ist die EU-Verordnung 2022/2554. Eine Sandbox kann helfen, die praktischen Folgen solcher Anforderungen frühzeitig zu untersuchen, sie ist aber kein eigener DORA-Konformitätsstatus.

Für Banken ist diese Abgrenzung wichtig: Ein erfolgreich abgeschlossener Sandbox-Test belegt nicht automatisch, dass ein Verfahren im produktiven Betrieb regelkonform ist. Er liefert vielmehr dokumentierte Erkenntnisse darüber, wie ein Prozess, eine technische Änderung oder ein neuer Dienst unter definierten Bedingungen funktioniert. Entscheidend ist, dass die Testannahmen, Ergebnisse, Abweichungen und Freigaben so festgehalten werden, dass sie in das reguläre Risikomanagement und die interne Kontrolle einfließen können.

Eine interne Sandbox kann beispielsweise genutzt werden, um Änderungen an einem Zahlungsprozess, einer Auslagerung oder einem Kontrollablauf zu prüfen. Das Team kann dafür eine repräsentative Testumgebung, klar definierte Rollen und realistische Störungsszenarien festlegen. So lässt sich untersuchen, ob Verantwortliche einen Vorfall erkennen, eskalieren und fristgerecht bearbeiten können, ohne unmittelbar in kritische Produktionssysteme einzugreifen.

• Prozessänderungen: Prüfen, wie neue oder geänderte Abläufe Kontrollen, Genehmigungen und Nachweispflichten beeinflussen.
• Technische Änderungen: Auswirkungen auf Verfügbarkeit, Integrität und Wiederherstellbarkeit anhand festgelegter Testszenarien bewerten.
• Dienstleister und Auslagerungen: Rollen, Informationsflüsse und Eskalationswege im Zusammenspiel mit externen IKT-Anbietern nachvollziehen.
• Kontrollnachweise: Dokumentieren, welche Prüfungen durchgeführt wurden, welche Ergebnisse vorlagen und wer Entscheidungen freigegeben hat.

Der praktische Wert entsteht vor allem durch die Verbindung von Test und Steuerung. Ein Experiment sollte nicht als isolierter Technikversuch enden, sondern konkrete Erkenntnisse für Risikobewertung, Kontrollgestaltung und Betriebsfreigabe liefern. Dafür braucht es vor Beginn ein überprüfbares Ziel: etwa die Frage, ob eine Wiederherstellung innerhalb der festgelegten Zeit gelingt oder ob ein Kontrollteam eine Abweichung anhand verfügbarer Daten rechtzeitig erkennt.

Bei der Planung sollten Sie Umfang und Grenzen des Tests festlegen. Dazu gehören die betroffenen Systeme und Prozesse, die verwendeten Daten, die beteiligten internen und externen Parteien sowie Kriterien für Abbruch und Erfolg. Ebenso wichtig ist die Entscheidung, welche Ergebnisse gespeichert werden und wie sie den zuständigen Funktionen zugänglich sind. Eine saubere Dokumentation macht den Test wiederholbar und erleichtert es, Erkenntnisse in bestehende Governance-Strukturen zu überführen.

Eine digitale Prozess- oder Systemabbildung kann dabei helfen, Abhängigkeiten sichtbar zu machen. Werden Prozesse, Anwendungen, Kontrollen und Verantwortlichkeiten miteinander verknüpft, lassen sich Änderungen und potenzielle Auswirkungen leichter nachvollziehen. Ein Regulatorischer Digital Twin kann beispielsweise den Soll-Prozess samt Kontrollpunkten abbilden und mit Betriebs- oder Testdaten verknüpfen. Er ersetzt keine rechtliche Bewertung und ist nicht automatisch ein offizieller Nachweis der DORA-Konformität. Sein Nutzen liegt darin, Informationen strukturiert zusammenzuführen und Prüfschritte nachvollziehbar zu machen.

In Verbindung mit einer Workflow-Plattform wie BPM ITEROP Cloud Bank können Testabläufe, Freigaben und Maßnahmen in einem kontrollierten Prozess organisiert werden. Dabei lässt sich etwa festlegen, wer ein Szenario genehmigt, welche Nachweise erforderlich sind und wie festgestellte Lücken an die zuständige Stelle gelangen. Die konkrete Eignung hängt jedoch von der jeweiligen Systemarchitektur, den Sicherheitsmaßnahmen, den Vertragsbedingungen und der Einbindung in die Bankprozesse ab. Entscheidend ist nicht allein die verwendete Plattform, sondern ob die gesamte Lösung den Anforderungen des Instituts entspricht.

DORA regelt außerdem die Zusammenarbeit mit IKT-Drittdienstleistern. Finanzunternehmen bleiben für die Einhaltung ihrer regulatorischen Pflichten verantwortlich, auch wenn sie Leistungen auslagern. Eine Sandbox kann deshalb helfen, die Übergaben zwischen Bank und Dienstleister zu testen: Wer meldet eine Störung? Welche Informationen werden weitergegeben? Wer entscheidet über Eskalation und Wiederanlauf? Solche Fragen sollten anhand der konkreten Verträge, Zuständigkeiten und Notfallverfahren geprüft werden, statt sich auf allgemeine Aussagen zur Leistungsfähigkeit eines Anbieters zu verlassen.

Für Cloud-Szenarien müssen Sie zusätzlich die einschlägigen Vorgaben zur Auslagerung und zum IKT-Drittparteienrisiko berücksichtigen. Die BaFin behandelt Cloud-Nutzung im Kontext ihrer Anforderungen an Auslagerungen und IT-Risiken; DORA enthält eigene Vorgaben zur Steuerung von IKT-Drittdienstleistern und zu kritischen IKT-Dienstleistern. Eine Sandbox hebt diese Pflichten nicht auf. Sie kann aber dabei unterstützen, technische und organisatorische Kontrollen vor einer Einführung oder wesentlichen Änderung zu erproben und die daraus gewonnenen Erkenntnisse in die dokumentierte Risikobewertung einzubeziehen.

Ein belastbarer Sandbox-Ansatz braucht daher einen klaren Übergang in den regulären Betrieb. Vor der Freigabe sollten die zuständigen Stellen beurteilen, ob Testergebnisse ausreichen, ob erkannte Schwächen behoben wurden und ob verbleibende Risiken akzeptiert werden dürfen. Ebenso ist festzulegen, welche Kontrollen im laufenden Betrieb fortgeführt werden. Werden diese Entscheidungen mit Verantwortlichen, Begründungen und Belegen dokumentiert, kann der Test die Nachvollziehbarkeit verbessern, ohne fälschlich als Ersatz für laufende Überwachung oder unabhängige Prüfung behandelt zu werden.

Für Banken, die 3DEXPERIENCE Banking oder andere digitale Prozessumgebungen evaluieren, empfiehlt sich ein enger, messbarer Einstieg. Wählen Sie einen konkreten Ablauf mit klar erkennbaren Kontrollpunkten und begrenzen Sie den Test auf einen überschaubaren Umfang. Definieren Sie vorab, welche Daten genutzt werden dürfen, wie Zugriffe geregelt sind und welche Ergebnisse eine produktive Einführung unterstützen würden. So wird die Sandbox zu einem Instrument für fundierte Entscheidungen – nicht zu einem parallelen Betrieb ohne klare Zuständigkeiten.

Anforderungen an digitale Resilienz

DORA verlangt von Finanzunternehmen, ihre digitale operationale Resilienz dauerhaft zu steuern und nachzuweisen. Dazu gehören nicht nur technische Schutzmaßnahmen, sondern auch klare Verantwortlichkeiten, belastbare Prozesse zur Behandlung von IKT-Vorfällen, regelmäßige Tests und eine wirksame Kontrolle von Drittparteien. Die Anforderungen gelten für das Institut auch dann, wenn Systeme oder Prozesse von externen Dienstleistern betrieben werden. Eine Sandbox kann helfen, einzelne Kontrollen und Abläufe unter definierten Bedingungen zu erproben; die Verantwortung für die Einhaltung bleibt jedoch beim Finanzunternehmen.

Das IKT-Risikomanagement bildet den organisatorischen Rahmen. DORA verpflichtet Finanzunternehmen, IKT-Risiken zu identifizieren, zu klassifizieren und zu überwachen sowie geeignete Schutz- und Präventionsmaßnahmen einzurichten. Dazu müssen sie ihre Informationswerte und IKT-Assets kennen, Abhängigkeiten verstehen und Risiken regelmäßig bewerten. Die konkreten Pflichten richten sich nach dem jeweiligen Unternehmen und den einschlägigen DORA-Vorgaben; die Verordnung enthält zudem Verhältnismäßigkeitsregelungen für bestimmte Unternehmen.

Eine belastbare Bestandsaufnahme geht über eine Liste von Anwendungen hinaus. Sie sollte zeigen, welche Geschäftsprozesse von welchen Systemen, Daten, internen Teams und externen Anbietern abhängen. So lässt sich beurteilen, welche Auswirkungen ein Ausfall oder eine fehlerhafte Änderung auf kritische oder wichtige Funktionen haben könnte. Für eine Bank kann diese Sicht beispielsweise Zahlungsabwicklung, Kreditentscheidungen, Kundenkommunikation und die dafür benötigten Datenflüsse miteinander verbinden.

Operative Resilienz zeigt sich besonders dann, wenn der Normalbetrieb gestört ist. Institute benötigen Verfahren, mit denen sie IKT-Vorfälle erkennen, klassifizieren, eskalieren und bearbeiten können. DORA sieht außerdem Meldepflichten für schwerwiegende IKT-Vorfälle vor. Damit diese Abläufe funktionieren, müssen Zuständigkeiten, Entscheidungspunkte und Informationswege vorab festgelegt und regelmäßig überprüft werden. Eine Simulation kann aufdecken, ob die zuständigen Teams die benötigten Informationen erhalten und ob Eskalationen ohne unnötige Verzögerungen erfolgen.

Auch Wiederanlauf und Wiederherstellung müssen in die Planung einbezogen werden. Notfall- und Kontinuitätsverfahren sollten zu den betroffenen Geschäftsprozessen passen und anhand geeigneter Szenarien getestet werden. Die Tests können etwa prüfen, ob ein System innerhalb der festgelegten Wiederherstellungsziele verfügbar gemacht werden kann oder ob ein Ersatzverfahren ausreichend dokumentiert ist. Die Ergebnisse sollten einschließlich festgestellter Schwächen, Maßnahmen und Freigaben nachvollziehbar gespeichert werden.

• Erkennen: Überwachung und Meldewege müssen relevante Störungen zeitnah sichtbar machen.
• Reagieren: Rollen, Eskalationsstufen und Entscheidungsbefugnisse sollten für unterschiedliche Vorfalltypen feststehen.
• Wiederherstellen: Notfallverfahren und Wiederanlaufpläne müssen zur Kritikalität der betroffenen Funktionen passen.
• Nachweisen: Tests, Entscheidungen, Abweichungen und Verbesserungsmaßnahmen sollten revisionsfähig dokumentiert sein.

DORA verlangt zudem ein Programm für Tests der digitalen operationalen Resilienz. Welche Tests angemessen sind, hängt unter anderem von Art, Größe und Risikoprofil des Instituts ab. Tests sollten nicht nur bestätigen, dass eine technische Komponente verfügbar ist, sondern auch prüfen, ob organisatorische Verfahren unter realistischen Bedingungen funktionieren. Dazu können Szenarien gehören, in denen ein Dienstleister nicht erreichbar ist, Daten fehlerhaft übertragen werden oder ein kritischer Prozess auf einen alternativen Betriebsweg wechseln muss.

Für die Steuerung von IKT-Drittdienstleistern ist eine vollständige Sicht auf Verträge, Leistungen und Abhängigkeiten erforderlich. DORA sieht unter anderem ein Informationsregister zu vertraglichen Vereinbarungen über die Nutzung von IKT-Dienstleistungen vor. Banken müssen beurteilen, welche Leistungen kritische oder wichtige Funktionen unterstützen, und angemessene Kontroll- und Überwachungsmechanismen einrichten. Bei Cloud-Diensten sollten Sie deshalb nicht nur technische Leistungswerte betrachten, sondern auch Zugriffsrechte, Unterauftragnehmer, Datenverarbeitung, Prüf- und Informationsrechte sowie Ausstiegs- und Übergangspläne prüfen.

Die BaFin weist in ihren Vorgaben zur Auslagerung und zur Nutzung von Cloud-Diensten auf die Bedeutung einer angemessenen Risikoanalyse, vertraglicher Sicherungen und wirksamer Kontrollmöglichkeiten hin. DORA ergänzt den europäischen Rahmen für das Management von IKT-Drittparteienrisiken. Maßgeblich sind die konkreten gesetzlichen und aufsichtsrechtlichen Anforderungen sowie die individuelle Risikobewertung des Instituts. Eine pauschale Anbieterzusage, etwa zur Verfügbarkeit oder Sicherheit, genügt daher nicht als Ersatz für die eigene Prüfung.

Ein Regulatorischer Digital Twin kann die für diese Steuerung benötigten Zusammenhänge in einer strukturierten digitalen Abbildung zusammenführen. Verknüpfen Sie Prozessschritte mit Anwendungen, Daten, Kontrollen, Verantwortlichen und externen Abhängigkeiten, lässt sich leichter nachvollziehen, welche Bereiche von einer Änderung oder einem Ausfall betroffen sein könnten. Werden relevante Betriebs- und Testinformationen ergänzt, kann diese Abbildung eine aktuelle Sicht auf Risiken und Kontrollstatus unterstützen. Sie ist jedoch nur so verlässlich wie die Daten, Aktualisierungsprozesse und Verantwortlichkeiten, auf denen sie beruht.

Für Digital Twin Banking Compliance ist deshalb wichtig, zwischen einem Modell und einem Nachweis zu unterscheiden. Ein Digital Twin kann Informationen auffindbar machen und Prüfpfade unterstützen; er belegt nicht automatisch die Einhaltung von DORA, BaFin-Vorgaben oder anderen Regelwerken. Das Institut muss weiterhin festlegen, welche Kontrollen gelten, wie ihre Wirksamkeit geprüft wird und wer Abweichungen bewertet. Werden diese Entscheidungen im Modell mit Quelle, Zeitstempel und zuständiger Funktion verknüpft, verbessert das die Nachvollziehbarkeit, ohne die fachliche oder rechtliche Prüfung zu ersetzen.

Eine workflowgestützte Umsetzung kann helfen, wiederkehrende Kontroll- und Freigabeprozesse einheitlich auszuführen. Mit BPM ITEROP Cloud Bank lassen sich beispielsweise Aufgaben, Zuständigkeiten, Fristen und erforderliche Dokumente in einem Prozessablauf abbilden. In einer Sandbox können Sie prüfen, ob ein solcher Ablauf bei einer Störung die richtigen Teams informiert und ob die erforderlichen Nachweise erfasst werden. Die konkrete Eignung muss anhand der Architektur, des Sicherheitskonzepts, der Vertragsbedingungen und der Einbindung in die bestehenden Bankprozesse bewertet werden.

Für Cloud-Lösungen sind außerdem Fragen der Datenresidenz, Mandantentrennung und Zugriffskontrolle zu klären. Eine Angabe wie „Daten werden in der EU gespeichert“ beantwortet nicht automatisch, wer auf sie zugreifen kann, wie Unterauftragnehmer eingebunden sind oder wie Daten nach Vertragsende behandelt werden. Prüfen Sie diese Punkte anhand von Verträgen, technischen Unterlagen und den eigenen Anforderungen an Auslagerungssteuerung und Informationssicherheit. Zertifizierungen wie ISO 27001 können dabei ein Prüfbaustein sein, ersetzen aber weder die eigene Risikoanalyse noch die Kontrolle der konkreten Lösung.

Die Wirksamkeit der Maßnahmen sollte anhand geeigneter Kennzahlen beobachtet werden. Beispiele sind die Zeit bis zur Erkennung und Eskalation eines Vorfalls, die Dauer bis zur Wiederherstellung, der Anteil fristgerecht abgeschlossener Kontrollen und die Zahl offener Maßnahmen aus Tests. Kennzahlen sind nur aussagekräftig, wenn Definition, Datenquelle und Messzeitraum transparent sind. In einer Sandbox können Sie vorab prüfen, ob die benötigten Daten tatsächlich verfügbar sind und ob die Kennzahlen eine sinnvolle Steuerungsentscheidung ermöglichen.

Umsetzung und Aufsicht in der Praxis

In der Praxis wird DORA wirksam, wenn Aufsichtserwartungen in überprüfbare Zuständigkeiten, Kontrollen und Nachweise übersetzt werden. Für Sie bedeutet das: Anforderungen müssen den betroffenen Geschäftsprozessen zugeordnet, ihre Umsetzung muss regelmäßig überwacht und jede wesentliche Entscheidung nachvollziehbar dokumentiert werden. Eine Sandbox unterstützt diese Arbeit, indem sie neue Abläufe kontrolliert erproben lässt; sie ersetzt weder die interne Governance noch die Prüfung durch Aufsicht und Abschlussprüfer.

Die Verantwortung beginnt beim Leitungsorgan. DORA weist den Leitungsorganen die Verantwortung für die Festlegung, Genehmigung und Überwachung des IKT-Risikomanagementrahmens zu. In der Praxis sollten Sie daher sicherstellen, dass Zuständigkeiten für Risiken, Kontrollen und Eskalationen eindeutig geregelt sind und dass wesentliche Erkenntnisse die zuständigen Entscheidungsträger erreichen. Fachbereiche, IT, Informationssicherheit, Risikomanagement, Compliance und interne Revision benötigen dabei klar definierte Rollen, ohne dass die unabhängige Kontrollfunktion durch operative Aufgaben verwischt wird.

Ein praktikabler Umsetzungsansatz beginnt mit einer Zuordnung von Anforderungen zu konkreten Prozessen und Belegen. Statt eine umfangreiche Regelwerksliste isoliert zu verwalten, können Sie für jede relevante Pflicht festhalten, welche Funktion verantwortlich ist, welcher Kontrollschritt sie erfüllt und welcher Nachweis die Durchführung belegt. Ein solcher Zusammenhang erleichtert sowohl die laufende Steuerung als auch die Vorbereitung auf Prüfungen.

• Anforderung: Welche DORA-Pflicht oder interne Vorgabe ist relevant?
• Prozess und Kontrolle: Wo wird sie umgesetzt, und wie wird die Kontrolle ausgeführt?
• Verantwortung: Wer führt aus, prüft, genehmigt und eskaliert?
• Nachweis: Welche Aufzeichnung belegt Zeitpunkt, Ergebnis und gegebenenfalls Abweichung?
• Maßnahme: Wie werden Mängel priorisiert, behoben und geschlossen?

Für die Aufsicht ist nicht nur entscheidend, ob eine Richtlinie existiert, sondern ob sie im Betrieb angewendet wird. Ein dokumentierter Ablauf sollte deshalb zeigen, wie Risiken bewertet, Kontrollen durchgeführt und Ausnahmen behandelt werden. Werden Ergebnisse ausschließlich in E-Mails oder persönlichen Ablagen festgehalten, kann die Nachvollziehbarkeit bei Personalwechseln oder Prüfungen leiden. Ein zentral gesteuerter Workflow kann Verantwortlichkeiten, Fristen und Belege konsistent erfassen, sofern Zugriffsrechte und Aufbewahrung passend geregelt sind.

Bei der Nutzung einer Sandbox sollten Sie die Testumgebung und ihre Grenzen ausdrücklich dokumentieren. Dazu zählen Zweck und Umfang des Versuchs, betroffene Systeme, verwendete Daten, beteiligte Dienstleister, Erfolgskriterien sowie Abbruchbedingungen. Wenn personenbezogene oder vertrauliche Informationen genutzt werden, sind zusätzlich die einschlägigen Datenschutz- und Sicherheitsanforderungen zu berücksichtigen. Wo möglich, sollten synthetische oder minimierte Daten eingesetzt werden, damit der Test nicht mehr Informationen verarbeitet als notwendig.

Ein Sandbox-Ergebnis sollte in einen formellen Entscheidungsprozess münden. Werden Schwächen erkannt, braucht es eine verantwortliche Stelle, eine priorisierte Maßnahme und einen Termin zur erneuten Prüfung. Vor einer produktiven Einführung sollten Sie außerdem bewerten, ob die Testbedingungen den realen Betrieb ausreichend abbilden. Abweichungen zwischen Test- und Produktionsumgebung – etwa bei Zugriffsrechten, Datenvolumen oder Dienstleisterkonfigurationen – müssen als Einschränkung des Ergebnisses kenntlich gemacht werden.

Auch die Zusammenarbeit mit externen IKT-Anbietern muss praktisch überprüfbar sein. DORA verlangt, dass Finanzunternehmen ihre Risiken aus IKT-Drittparteien steuern und vertragliche Vereinbarungen sowie Abhängigkeiten angemessen erfassen. In einer Übung können Sie prüfen, ob ein Anbieter die vereinbarten Informationen rechtzeitig bereitstellt, ob Eskalationskontakte funktionieren und ob Prüf- und Zugriffsrechte praktisch nutzbar sind. Die Übung ersetzt keine Vertragsprüfung; sie kann jedoch zeigen, ob festgelegte Rechte und Verfahren im konkreten Ablauf tatsächlich greifen.

Bei Cloud-Outsourcing sollten Sie die Anforderungen aus DORA gemeinsam mit den einschlägigen BaFin-Vorgaben und der individuellen Auslagerungsbewertung betrachten. Prüfen Sie insbesondere Leistungsumfang, Datenstandorte, Unterauftragnehmer, Kontrollmöglichkeiten, Vorfallmeldungen, Geschäftskontinuität und Beendigungsregelungen. Eine Zertifizierung oder ein standardisierter Prüfbericht kann Informationen liefern, sollte aber daraufhin bewertet werden, ob Umfang, Zeitraum und geprüfte Kontrollen zu Ihrer konkreten Nutzung passen. Die Verantwortung für die eigene Risikobewertung verbleibt beim Institut.

Digitale Prozessmodelle können die Aufsichtsvorbereitung unterstützen, wenn sie aktuell und mit belastbaren Quellen verknüpft sind. Ein Regulatorischer Digital Twin kann beispielsweise darstellen, welche Kontrollen einen bestimmten Prozess absichern, welche Systeme beteiligt sind und welche Nachweise bei einer Prüfung verfügbar sein sollten. Werden Änderungen an Prozessen oder Anwendungen nachvollziehbar dokumentiert, lässt sich deren Auswirkung auf Kontrollen gezielter bewerten. Die Darstellung ist jedoch kein automatischer Konformitätsnachweis: Fachverantwortliche müssen Inhalte validieren und Änderungen zeitnah einpflegen.

Mit BPM ITEROP Cloud Bank lassen sich regulatorische Abläufe als strukturierte Workflows organisieren, etwa für Kontrollbestätigungen, Ausnahmen, Maßnahmenverfolgung oder Freigaben. Eine passende Konfiguration kann festlegen, welche Angaben erforderlich sind, wer bei Fristüberschreitungen informiert wird und wie Belege einem Vorgang zugeordnet werden. Vor dem Einsatz sollten Sie unter anderem Rollen- und Berechtigungskonzepte, Protokollierung, Aufbewahrung, Schnittstellen und Betriebsverantwortung prüfen. Die Plattform allein gewährleistet keine DORA-Konformität; maßgeblich ist die kontrollierte Gesamtlösung im jeweiligen Institut.

Ein wirksamer Audit-Trail sollte erkennen lassen, wer eine Handlung vorgenommen hat, wann sie erfolgte, welche Informationen zugrunde lagen und ob nachträgliche Änderungen vorgenommen wurden. Für den Prüfungsfall ist außerdem wichtig, dass Belege auffindbar und verständlich sind und nicht nur als technische Protokolle ohne Prozesskontext vorliegen. Legen Sie daher fest, welche Aufzeichnungen aufzubewahren sind, wer darauf zugreifen darf und wie lange sie benötigt werden. Die konkreten Fristen und Anforderungen sollten Sie aus den jeweils anwendbaren gesetzlichen, regulatorischen und internen Vorgaben ableiten.

Für die Steuerung im laufenden Betrieb eignen sich wenige, klar definierte Kennzahlen besser als umfangreiche Dashboards ohne Handlungsbezug. Sie können etwa die fristgerechte Durchführung von Kontrollen, die Zahl überfälliger Maßnahmen, die Dauer der Vorfalleskalation oder den Anteil getesteter Wiederanlaufverfahren beobachten. Wichtig sind eine einheitliche Definition, eine verlässliche Datenquelle und ein festgelegter Schwellenwert, bei dessen Überschreitung eine Prüfung oder Eskalation ausgelöst wird. So werden Kennzahlen zu Steuerungsinformationen statt zu bloßen Berichtswerten.

Bei der Einführung einer Lösung für 3DEXPERIENCE Banking sollten Sie den Nutzen deshalb anhand eines abgegrenzten Anwendungsfalls prüfen. Wählen Sie einen Prozess mit klaren Verantwortlichkeiten und messbarem Aufwand, etwa die Bearbeitung einer Kontrollabweichung oder die Freigabe einer wesentlichen Prozessänderung. Erheben Sie vor dem Pilotbetrieb Ausgangswerte für Durchlaufzeit, Nacharbeitsaufwand und Vollständigkeit der Nachweise. Aussagen wie eine mögliche Reduktion der Prüfungszeit oder geringere Änderungskosten sollten erst dann als Ergebnis kommuniziert werden, wenn sie mit vergleichbaren internen Daten belegt sind.

Für die Abstimmung mit Aufsicht und Prüfern hilft eine konsistente Dokumentation der wesentlichen Entscheidungen. Halten Sie fest, welche Risiken bewertet wurden, welche Kontrollen gewählt oder angepasst wurden, welche Einschränkungen bestehen und wer die verbleibenden Risiken akzeptiert hat. Bei neuen Technologien oder geänderten Auslagerungen sollten Sie außerdem nachvollziehbar begründen, wie die Auswirkungen auf kritische oder wichtige Funktionen beurteilt wurden. So können Sie konkrete Fragen anhand eines zusammenhängenden Nachweispfads beantworten, statt Informationen nachträglich aus verschiedenen Systemen zusammensuchen zu müssen.

lut

–
Bereit für den nächsten Schritt?
Hier erfahren Sie mehr: Tolerant Software