DORA in der Praxis: Eine (neue) Logik hinter SFO, BASO und Soll-Soll-/Soll-Ist-Abgleichen

Liebe DORA-Community, Auf unserem Weg in Richtung DORA-Compliance gibt es nach wie vor echte konzeptionelle und methodische Herausforderungen. Eine davon ist das Zusammenspiel von schriftlich fixierter Ordnung (SFO), Bankensollmaßnahmenkatalog (BASO) und den sogenannten Soll-Soll- und Soll-Ist-Abgleichen.

Liebe DORA-Community,

Auf unserem Weg in Richtung DORA-Compliance gibt es nach wie vor echte konzeptionelle und methodische Herausforderungen. Eine davon ist das Zusammenspiel von schriftlich fixierter Ordnung (SFO), Bankensollmaßnahmenkatalog (BASO) und den sogenannten Soll-Soll- und Soll-Ist-Abgleichen.

Gerade die Logik hinter diesen Abgleichen führt in der Praxis immer wieder zu Verwirrung. Spätestens wenn Soll-Soll- und Soll-Ist-Abgleiche gleichzeitig auf interne Regelwerke, externe regulatorische Vorgaben und Dienstleisterverträge angewendet werden sollen, entsteht schnell ein Gefühl von Unübersichtlichkeit.

Genau hier setzt mein heutiger Beitrag an: Er soll Ordnung in die Begrifflichkeiten bringen und die dahinterliegende Logik systematisch erklären.

Starten wir mit einigen Beispielen…

Während der BaFin-Veranstaltung „IT-Aufsicht im Finanzsektor – das erste Jahr DORA“ habe ich in der vergleichsweise kurzen Vortragszeit mindestens vier verschiedene Abgleiche gehört:

1. Soll-Soll Abgleiche zwischen Artikel 30 DORA uns den Regelungen in den IKT-Verträgen,
2. Soll-Ist-Abgleiche zwischen den externen DORA-Anforderungen und der tatsächlichen Umsetzung im IST,
3. Soll-Ist-Abgleiche zwischen den internen Soll-Vorgaben und der betrieblichen Realität, und
4. Soll-Ist-Abgleiche zwischen den inventarisierten IKT-Dienstleistungen im Informationsregister und der Realität in der IT-Anwendungslandschaft.

Über diese von der BaFin ausdrücklich genannten Beispiele hinaus existiert eine Vielzahl weiterer Abgleiche, die im Rahmen von DORA relevant werden, so beispielsweise

1. Soll-Soll-Abgleiche zwischen DORA-Vorgaben und internen Soll-Vorgaben des Finanzunternehmens
2. Soll-Soll-Abgleiche zwischen internen Soll-Vorgaben und vertraglichen Vorgaben in den IKT-Verträgen
3. Soll-Ist-Abgleiche zwischen vorgeschriebenen und den tatsächlich umgesetzten IKT-Sicherheitsmaßnahmen in den IT-Anwendungen
4. Operative Soll-Ist-Abgleiche im Rahmen der Rezertifizierung von Benutzerrechten oder Firewall-Regeln oder zwischen Soll- und Ist-Konfiguration unserer IT-Systeme
5. … und so weiter und so fort…

Diese Beispiele zeigen: Wir sprechen ständig über Soll-Soll- und Soll-Ist-Abgleiche – aber oft ohne klar zu sagen, welche Bezugsobjekte wir eigentlich miteinander vergleichen.

Warum Finanzunternehmen Abgleiche durchführen müssen

Die zentrale Frage lautet zunächst:

Warum führen wir diese Abgleiche überhaupt durch?

Diese Frage lässt sich erstaunlich einfach beantworten. Es geht darum herauszufinden, ob wir „compliant“ sind – also ob wir regelkonform arbeiten. Diese Regelkonformität kann sich dabei auf sehr unterschiedliche Aspekte beziehen: Konformität mit Gesetzen, Normen, aufsichtlichen Leitlinien, internen Vorschriften, Anforderungen aus Herstellerdokumentationen oder vertraglichen Vereinbarungen mit Dienstleistern.

Finanzunternehmen bewegen sich damit in einer äußerst komplexen Vorgabelandschaft – es sind hunderte Anforderungen, zu denen wir uns regelkonform verhalten müssen, um qualitativ hochwertige Produkte und Dienstleistungen anzubieten, unsere Risiken zu begrenzen und natürlich auch, um nicht bei der nächsten Prüfung Mängel attestiert zu bekommen.

Gleichzeitig ist klar: Vollständige Compliance in jedem Detail ist weder realistisch noch wirtschaftlich sinnvoll. Non-Compliance wird damit zu einem unternehmerischen Risiko, das bewusst gesteuert werden muss.

Genau hier kommen Soll-Soll- und Soll-Ist-Abgleiche ins Spiel. Sie liefern die Grundlage, um bewerten zu können, wo Handlungsbedarf besteht und wo Risiken bewusst akzeptiert werden können (oder müssen).

Doch wogegen vergleichen wir eigentlich? Dazu müssen wir einen Schritt zurückgehen und uns die zugrunde liegende Vorgabelandschaft ansehen.

Externe Vorgaben

Beginnen wir mit den externen Vorgaben eines Unternehmens. Sie umfassen alle externen Anforderungen, die den übergeordneten normativen Rahmen des unternehmerischen Handelns bestimmen.

Die Bedeutung dieser Vorgaben lässt sich in einem pyramidenähnlichen Aufbau darstellen, bei dem Relevanz und Verbindlichkeit von oben nach unten abnehmen.

1. EU-Recht: Als Mitgliedstaat der Europäischen Union unterliegt Deutschland einer Vielzahl europäischer Vorgaben, die vom europäischen Gesetzgeber erlassen werden. Hierzu zählen insbesondere europäische Verordnungen wie die DORA-Verordnung, die in allen Mitgliedstaaten unmittelbare Bindungswirkung entfalten und daher die oberste Ebene der Pyramide bilden.
2. Nationales Recht: Ergänzt werden diese Vorgaben durch nationale Gesetze, Verordnungen und Erlasse, die vom deutschen Gesetzgeber erlassen werden und die europäischen Anforderungen konkretisieren, flankieren oder zusätzliche nationale Belange regeln.
3. Aufsichtliche Leitlinien und Verwaltungsvorschriften: Darüber hinaus sind nationale und europäische Aufsichtsbehörden, wie etwa die BaFin oder die EBA, befugt, ergänzende Verwaltungsvorschriften sowie aufsichtliche Leitlinien zu veröffentlichen, beispielsweise die MaRisk oder die EBA-Guidelines zum Outsourcing. Diese Vorgaben präzisieren die rechtlichen Anforderungen aus aufsichtsrechtlicher Sicht.
4. Anerkannte Normen und Standards: Zusätzlich entfalten in bestimmten Fällen auch anerkannte Normen wie ISO 27001 oder der BSI-Grundschutz sowie Standards und Best Practices (z. B. ITIL oder COBIT) eine Bindungswirkung. Obwohl diese Regelwerke nicht unmittelbar gesetzlich vorgeschrieben sind, werden sie in der Prüfungspraxis häufig als Maßstab der prüferischen Erwartungshaltung herangezogen, gestützt durch gesetzliche und regulatorische Vorgaben, die ausdrücklich deren Berücksichtigung verlangen.

Wichtig ist jedoch: Die Unternehmen können grundsätzlich selbst entscheiden, welchen Normen oder Standards sie folgen und in welchem Umfang sie das tun. Sie können beispielsweise auch nur ausgewählte Teile bestehender Normen umsetzen – müssen den Prüfern gegenüber jedoch nachvollziehbar darlegen, dass die gewählten Ansätze geeignet sind, um die Anforderungen zu erfüllen.

Soviel zur Theorie. In der Praxis ergibt sich unter DORA jedoch bereits an dieser Stelle eine zentrale Herausforderung, denn mit der Verordnung durchkreuzt der europäische Gesetzgeber diese vermeintlich klar abgegrenzten Ebenen externer Vorgaben.

Anstatt das Gesetz auf ein Mindestmaß abstrakter, prinzipienorientierter Anforderungen zu beschränken, übernimmt der Gesetzgeber ausgewählte Anforderungen aus anerkannten Standards in die Verordnung auf und erklärt sie damit ausdrücklich zum normativen und verpflichtenden Mindeststandard.

Dies bringt für Unternehmen einerseits Vorteile, da klar definiert ist, welche Anforderungen mindestens zu erfüllen sind. Andererseits entstehen strukturelle Unsicherheiten und es stellt sich die Frage, wie mit Anforderungen umzugehen ist, die nicht in den gesetzlichen Mindeststandard übernommen wurden: Können diese offiziell als nicht relevant eingeordnet werden, oder dürfen Prüfer weiterhin darüberhinausgehende Erwartungen formulieren und einfordern?

Interne Vorgaben in der schriftlich fixierten Ordnung

Die sogenannte schriftlich fixierte Ordnung des Unternehmens (SFO) – auch als Anweisungswesen bezeichnet – bildet die interne Vorgabeebene des Unternehmens. Sie entsteht, indem die maßgeblichen externen Vorgaben in unternehmensinterne Regelungen übersetzt werden.

Der Internalisierungsprozess externer Vorgaben folgt dabei einem strukturierten Kreislauf. Relevante externe Anforderungen werden üblicherweise im Rahmen eines Rechts- und Compliance-Monitorings identifiziert und kontinuierlich beobachtet. Bei Bedarf werden sie fachlich interpretiert und in interne Regelungen in der SFO überführt. Anschließend werden diese Vorgaben operationalisiert und in den Arbeitsalltag integriert. Die Einhaltung wird regelmäßig durch Soll-Ist-Abgleiche überprüft, während ergänzende Soll-Soll-Abgleiche sicherstellen, dass die internen Regelungen auch bei Änderungen externer Vorgaben vollständig und aktuell bleiben.

Die SFO wird in der Regel in verschiedenen Formaten dokumentiert, die – ähnlich wie externe Vorgaben – eine unterschiedliche Bindungswirkung entfalten und verschiedenen formalen Anforderungen unterliegen.

Auch die SFO ist hierarchisch aufgebaut und wird häufig in Form einer Dokumentenpyramide dargestellt. Dabei wird regelmäßig zwischen einem verbindlichen Kern der SFO und ergänzenden, mitgeltenden Regelwerken (dem „Anhang zur SFO“) unterschieden.

Strategien

Strategien bilden die oberste inhaltliche Ebene der internen Vorgaben und geben die langfristige Ausrichtung des Unternehmens vor. Sie legen fest, welche unternehmerischen Schwerpunkte gesetzt werden, welche Ziele damit verfolgt werden und welche Leitplanken dabei gelten. Im Kontext der digitalen operationalen Resilienz zählen hierzu insbesondere die DOR-Strategie sowie die Strategie zum IKT-Drittparteienrisiko. Sie sind vom Leitungsorgan zu verabschieden und dienen als verbindlicher Orientierungsrahmen für nachgelagerte Dokumente in der SFO.

Leitlinien und Richtlinien

Leitlinien und Richtlinien sind in ihrer Funktion mit nationalen und europäischen Gesetzen im externen Umfeld vergleichbar. Sie enthalten in der Regel thematisch strukturierte und prinzipienorientierte Mindestvorgaben, die bei der Ausgestaltung von Organisationsstrukturen, Abläufen und IT-Systemen zu berücksichtigen sind.

Sie überführen externe gesetzliche und regulatorische Anforderungen in das interne Regelwerk des Unternehmens und legen verbindlich fest, was zulässig ist und was nicht. Leitlinien und Richtlinien definieren damit den normativen Rahmen für das Handeln im Unternehmen und werden vom Leitungsorgan verantwortet. Im Kontext der DORA-Verordnung werden diese Vorgaben einheitlich als IKT-Sicherheitsrichtlinien bezeichnet.

Verfahrensanweisungen und Prozessbeschreibungen:

Im klassischen Anweisungswesen werden die normativen Vorgaben aus Leit- und Richtlinien durch Prozessbeschreibungen und Verfahrensanweisungen konkretisiert, die beschreiben, wie diese Anforderungen im Unternehmen umzusetzen sind. Auch sie zählen zu den Soll-Vorgaben des Unternehmens, da sie Abläufe im angestrebten Soll-Zustand festlegen und konkretisieren, welche Rollen welche Arbeitsschritte zur Umsetzung der übergeordneten Anforderungen übernehmen.

In der Praxis – insbesondere im IKT-Umfeld – lässt sich diese inhaltliche Trennung zwischen Leit- und Richtlinien als Beschreibung des „Was“ und Prozessbeschreibungen sowie Verfahrensanweisungen als Beschreibung des „Wie“ jedoch häufig nicht konsequent aufrechterhalten. Dies resultiert daraus, dass IKT-Sicherheitsrichtlinien organisationsweit gelten und daher bewusst fachlich vereinfacht, abstrakt und technologieneutral formuliert werden.

Vor diesem Hintergrund bedürfen die Vorgaben aus den IKT-Sicherheitsrichtlinien einer weitergehenden inhaltlichen und fachlichen Konkretisierung. Ein Teil des normativen „Was“ verlagert sich daher zwangsläufig in die nachgelagerten Ebenen des Anweisungswesens, insbesondere in Verfahrensanweisungen und Prozessbeschreibungen. Dort werden die Soll-Vorgaben regelmäßig um zusätzliche technische, methodische oder fachliche Festlegungen ergänzt, etwa durch konkrete Kriterien, Schwellenwerte oder ergänzende Mindestanforderungen.

Der Sollmaßnahmenkatalog

Der Sollmaßnahmenkatalog – im Bankenumfeld häufig als Bankensollmaßnahmenkatalog (BASO) bezeichnet – zählt seit jeher zu den schwer greifbaren Elementen des betrieblichen Anweisungswesens. Schon immer wurde in den Unternehmen über seine Bedeutung, seine Inhalte, seine Bindungswirkung sowie über die richtige Einordnung in die Dokumentenpyramide diskutiert.

Der Begriff wurde ursprünglich von der deutschen Finanzaufsicht im Rahmen der sogenannten xAIT geprägt, etwa in der BAIT oder VAIT. In diesem Kontext waren Finanzunternehmen verpflichtet, einen Katalog vorzuhalten, der sämtliche Anforderungen beschreibt, die zur Erreichung des jeweiligen Schutzbedarfs ihrer IKT-Assets umzusetzen sind. Der Sollmaßnahmenkatalog sollte dabei als interner Anforderungskatalog fungieren, der festlegt, was zum Schutz von Informationen und IT-Systemen getan werden muss, ohne konkrete technische Umsetzungen im Sinne eines „Wie“ vorzugeben. Häufig wurden hierzu Anforderungen aus etablierten Sicherheitsstandards wie dem BSI-Grundschutz oder der ISO-27001-Reihe übernommen und als interner Soll-Standard deklariert.

Mit dem Wegfall der xAIT und der Einführung einer einheitlichen europäischen Regulierung durch die DORA-Verordnung ist der Begriff des Sollmaßnahmenkatalogs formal aus der IT-Regulatorik verschwunden. Dies bedeutet jedoch keineswegs, dass das zugrunde liegende Konzept im nationalen Umfeld obsolet geworden ist. Stattdessen fragen Prüfer in Jahresabschlussprüfungen sowie in §-44-DORA-Prüfungen regelmäßig nach einem Katalog der IKT-Sicherheitsmaßnahmen.

Finanzunternehmen sind damit weiterhin faktisch gezwungen, sich mit der systematischen Bündelung ihrer Soll-Vorgaben zur IKT-Sicherheit zu befassen – auch wenn ein BASO gesetzlich nicht explizit gefordert wird.

Doch warum ist dieses Thema eigentlich so kompliziert?

In der früheren xAIT-Welt waren die gesetzlichen Vorgaben zur IKT-Sicherheit stark prinzipienorientiert und abstrakt ausgestaltet. Um dennoch vergleichbare Sicherheitsstandards sicherzustellen, forderten die xAIT die Einhaltung „gängiger Standards“ wie BSI-Grundschutz oder der ISO-270xx-Reihe und erklärten diese zur aufsichtlichen Erwartungshaltung. Da diese Standards fortlaufend weiterentwickelt werden, ergab sich eine dynamische Auslegung der Mindestanforderungen an die IKT-Sicherheit.

Mit DORA verändert sich diese Grundlogik jedoch erheblich. Der europäische Gesetzgeber beschränkt sich nicht mehr darauf, die Einhaltung anerkannter Standards einzufordern, sondern formuliert selbst unmittelbar verbindliche und teilweise sehr konkrete Mindestanforderungen an die IKT-Sicherheit.

Zahlreiche Inhalte aus Sicherheitsframeworks wie der ISO-27000-Reihe oder dem NIST-Framework werden dabei direkt in Gesetzesform überführt und ausdrücklich zum normativen Mindeststandard erklärt. Gleichzeitig werden Finanzunternehmen verpflichtet, diese Mindestanforderungen in konkrete IKT-Sicherheitsrichtlinien, Verfahrensanweisungen und Prozessbeschreibungen zu überführen, um die Einhaltung von DORA nachweisen zu können. Das führt im Wesentlichen zu zwei Problemen:

1. DORA durchbricht mit seiner Vorgabe von verbindlichen Mindestinhalten in konkreten Dokumententypen (z. B. den IKT-Sicherheitsrichtlinien) die bisher gewohnte Struktur und Ordnung in der SFO. Inhalte, die früher im Anweisungswesen klar getrennt waren, werden nun vermischt. Vorgaben dazu, was grundsätzlich einzuhalten ist, stehen nicht mehr nur in Leit- und Richtlinien, sondern teilweise auch in Verfahrensanweisungen. Gleichzeitig enthalten IKT-Sicherheitsrichtlinien nun auch konkrete Vorgaben dazu, wie etwas umzusetzen ist. Die bisher klare Trennung zwischen Vorgabenebene und Umsetzungsebene verliert damit an Schärfe.
2. Andererseits hat ein eigenständiger Sollmaßnahmenkatalog in der neuen, durch DORA geprägten Logik der Dokumentenpyramide eigentlich keinen festen Platz mehr. Der europäische Gesetzgeber geht davon aus, dass alle normativen Soll-Vorgaben bereits vollständig in den einschlägigen IKT-Sicherheitsrichtlinien sowie in Verfahrensanweisungen und Prozessbeschreibungen dokumentiert sind. Ergänzende technische oder organisatorische Maßnahmen sollen lediglich risikoorientiert und einzelfallbezogen im Rahmen der IKT-Risikobehandlung festgelegt werden. Dabei handelt es sich ausdrücklich nicht um pauschale Mindestmaßnahmen, sondern um individuelle, bedarfsorientierte Maßnahmen zur Risikosteuerung.

Leider hat sich diese Sichtweise bislang jedoch weder in den Finanzunternehmen noch bei nationalen Aufsichtsbehörden vollständig etabliert. Stattdessen fordern interne Funktionsträger, Prüfungsverbände und nationale Aufsichtsbehörden weiterhin einen strukturierten Katalog der IKT-Sicherheitsmaßnahmen – faktisch also einen Sollmaßnahmenkatalog in „neuem Gewand“.

Hierdurch entstehen erhebliche Unsicherheiten in der Ausgestaltung interner Soll-Vorgaben sowie Redundanzen in der SFO, denn in vielen Häusern ist der BASO weiterhin eine weitgehende Abschrift von ISO- und BSI-Controls, deren Inhalte zumindest teilweise bereits gesetzlich normiert und in den übergeordneten internen Vorgabedokumenten verarbeitet sind.

Ein Ausweg aus dem Dilemma

Um zukünftig Redundanzen und Inkonsistenzen im internen Anweisungswesen zu vermeiden, müssen wir also umdenken!

Mein Vorschlag dazu? Mut zur Vereinfachung und zum Umbau des BASO!

Aus meiner Sicht sollte der Sollmaßnahmenkatalog künftig nicht mehr als eigenständiges normatives Regelwerk, sondern vielmehr als Kontroll- und Referenzkatalog verstanden werden. Er sollte keine zusätzlichen originären Soll-Vorgaben definieren, sondern sich darauf beschränken, bestehende (gesetzliche Mindest-) Anforderungen aus IKT-Sicherheitsrichtlinien, Verfahrensanweisungen und Prozessbeschreibungen strukturiert zusammenzuführen, bei Bedarf zu erläutern und für Kontroll- und Abgleichszwecke aufzubereiten.

In dieser Ausgestaltung entfaltet der BASO eine Bündelungs- und Transparenzwirkung und kann in der Praxis als zentrales Arbeitsinstrument für Soll-Soll- und Soll-Ist-Abgleiche genutzt werden. Er wird damit zu einer funktionalen Erweiterung der internen Soll-Vorgaben, der sich vollständig aus den IKT-Sicherheitsrichtlinien, Verfahrensanweisungen und Prozessbeschreibungen der Unternehmen speist. In der Dokumentenpyramide würde er sich folgerichtig bei den mitgeltenden Unterlagen verorten lassen, die dynamisch und bedarfsgerecht angepasst und konkretisiert werden können.

Und was ist, wenn die gesetzlichen Mindestanforderungen nicht ausreichen?

Sollten im BASO tatsächlich einzelne technische oder organisatorische Maßnahmen fehlen oder zusätzlicher Regelungsbedarf bestehen, bestünde das Gap eigentlich auf der übergeordneten Regelungsebene und es müssten vielmehr Anpassungen an den IKT-Sicherheitsrichtlinien sowie an Verfahrensanweisungen und Prozessbeschreibungen vorgenommen werden. Diese Anpassungen sind hinsichtlich ihrer Auswirkungen und Machbarkeit zu analysieren und schließlich vom Leitungsorgan des Unternehmens zu beschließen. Damit stellen wir auch eine angemessene Einbindung des Leitungsorgans sicher. Anschließend können die neuen Vorgaben für Abgleichszwecke in den BASO übernommen werden.

Weitere mitgeltende Dokumente

Neben dem BASO existiert eine Vielzahl weiterer mitgeltender Dokumente, die häufig auch als „Anhang zur SFO“ bezeichnet werden. Hierzu zählen beispielsweise Sicherheitskonzepte, Berechtigungskonzepte, Betriebshandbücher, Notfallpläne oder Exitpläne.

Diese Dokumente beschreiben die konkrete Implementierung und Ausgestaltung der normativen Vorgaben. Sie werden häufig auf Basis vorgegebener Formulare und Templates sowie mithilfe von Checklisten durch die zuständigen Fachbereiche oder die jeweiligen Asset-Verantwortlichen erstellt, gepflegt und verantwortet.

Soll-Ist- und Soll-Abgleiche unter DORA

Kommen wir nun zu den geforderten Abgleichen, die unter DORA auf unterschiedlichen Ebenen und mit unterschiedlicher Zielsetzung erfolgen. Grundsätzlich lassen sich Soll-Soll-Abgleiche und Soll-Ist-Abgleiche unterscheiden, die jeweils intern und extern durchgeführt werden.

Ebene 1: Soll-Soll-Abgleich (extern)

Der externe Soll-Soll-Abgleich diente in der früheren xAIT-Welt dazu zu prüfen, ob die im BASO definierten IKT-Sicherheitsmaßnahmen vollständig und korrekt die externen gesetzlichen und regulatorischen Anforderungen abbilden.

Durch die Umgestaltung des BASOs zu einem reinen Referenz- und Kontrollinstrument muss jedoch auch der Soll-Soll-Abgleich angepasst werden. Im neuen Format würden anstelle des BASOs die internen IKT-Sicherheitsrichtlinien, Verfahrensanweisungen und Prozessbeschreibungen überprüft, inwieweit diese vollständig und korrekt die gesetzlichen und regulatorischen Anforderungen abbilden.

Verglichen werden also

• Soll 1 (extern): DORA sowie relevante Standards und Normen (z. B. ISO-270xx)
• Soll 2 (intern): IKT-Sicherheitsrichtlinien, Verfahrensanweisungen und Prozessbeschreibungen

Das Finanzunternehmen erhält im Ergebnis einen Überblick, ob es alle externen gesetzlichen, regulatorischen und normativen Anforderungen vollständig und korrekt in den internen Soll-Vorgaben des Anweisungswesens abgebildet hat.

Ebene 2: Soll-Soll-Abgleich (Intern)

Der interne Soll-Soll-Abgleich diente früher dazu zu prüfen, ob die Soll-Vorgaben aus dem BASO in den nachgelagerten Umsetzungsdokumenten der Fachbereiche berücksichtigt wurden.

Wenn der BASO zukünftig jedoch nur noch als Referenz- und Kontrollinstrument genutzt wird, verändert sich auch dieser Abgleich. Der Fokus liegt nun auf der formalen Vollständigkeit und Konsistenz des Referenzkatalogs selbst. Zielsetzung ist also die Sicherstellung, dass der BASO die relevanten internen Soll-Vorgaben vollständig, korrekt und konsistent abbildet und als verlässlicher Referenzkatalog für weitere Abgleiche genutzt werden kann.

Verglichen werden also:

• Soll 1 (Intern) : IKT-Sicherheitsrichtlinien, Verfahrensanweisungen und Prozessbeschreibungen
• Soll 2 (Intern): BASO

Ebene 3: Soll-Soll-Abgleich (IKT-Verträge)

Ziel dieses Soll-Soll-Abgleichs der IKT-Veträge ist die Identifikation von Abweichungen zwischen den internen Soll-Vorgaben des Finanzunternehmens und den vertraglichen Regelungen mit IKT-Dienstleistern.

Die vertraglichen Soll-Vorgaben ergeben sich dabei aus dem BASO bzw. dem für die jeweilige IKT-Dienstleistung relevanten Teilaspekt sowie den Mindestvertragsanforderungen gemäß Artikel 30 DORA. Diese Anforderungen müssen in die Verträge mit IKT-Dienstleistern integriert werden und hinsichtlich der Vollständigkeit über Soll-Soll-Abgleiche überprüft werden.

Verglichen werden also:

• S oll 1 (intern): Dienstleistungsspezifische (oft reduzierte) Auswahl relevanter Soll-Vorgaben aus dem BASO
• Soll 2 (IKT-Verträge): Auslagerungsverträge, Leistungsbeschreibungen, Informationssicherheits- oder Notfallmanagement-Anlagen.

Im Ergebnis erhält das Finanzunternehmen Transparenz darüber, welche internen Soll-Vorgaben sachgerecht und vollständig in den IKT-Verträgen berücksichtigt sind und wo ggf. auch Lücken bestehen, die im Rahmen des IKT-Drittparteienrisikomanagements zu berücksichtigen sind.

Ebene 4: Soll-Ist-Abgleich (Intern)

Ziel des internen Soll-Ist-Abgleichs ist es festzustellen, ob die im BASO referenzierten Soll-Vorgaben im Unternehmen tatsächlich umgesetzt sind. Dabei wird zwischen übergreifenden und asset-spezifischen Soll-Ist-Abgleichen unterschieden.

1. Übergreifende interne Soll-Ist-Abgleiche: Sie prüfen unternehmensweit geltende organisatorische und technische Sicherheitsvorgaben, insbesondere Strukturen, Prozesse und zentrale Steuerungsmechanismen der IKT-Sicherheit.
2. Asset-spezifische Soll-Ist-Abgleiche: Sie prüfen die konkrete Umsetzung der Sicherheitsvorgaben für einzelne IKT-Assets wie Anwendungen, Systeme oder Infrastrukturelemente.

Ebene 5: Soll-Ist-Abgleich (Extern)

Ziel des externen Soll-Ist-Abgleichs ist es zu prüfen, ob die mit dem IKT-Dienstleister vereinbarten Soll-Vorgaben auch tatsächlich im operativen Betrieb umgesetzt sind – und nicht nur vertraglich existieren. Auch hier wird zwischen übergreifenden und asset-spezifischen Abgleichen unterschieden.

1. Übergreifende externe Soll-Ist-Abgleiche: Sie prüfen die generelle Sicherheits- und Governance-Struktur des Dienstleisters, etwa ISMS, Rollenmodelle, Risikomanagement, physische Sicherheit und Notfallmanagement.
2. Asset-spezifische externe Soll-Ist-Abgleiche: Sie beziehen sich auf einzelne IKT-Dienstleistungen und prüfen, ob die für diese Dienstleistung geltenden Sicherheits-, Reaktions- und Wiederherstellungsanforderungen umgesetzt sind.

Damit bin ich am Ende meines heutigen Beitrags angekommen. Vielleicht wirkt der Blick auf SFO, BASO und Abgleiche nach dieser Lektüre ein wenig sortierter – oder wirft gerade neue Fragen auf. Beides ist ausdrücklich willkommen.

Ich freue mich wie immer auf eure Gedanken, Perspektiven und Praxisbeispiele in den Kommentaren.

Habt einen guten Start in die neue Woche und bis bald.