IT für Banken & Finanzdienstleister

Banken und Finanzdienstleister liefern IT unter besonderen Rahmenbedingungen: Regulatorik, hohe Verfügbarkeitsanforderungen, strikte Nachvollziehbarkeit und ein erhöhtes Bedrohungsniveau. Gleichzeitig steigen die Erwartungen an digitale Produkte, Schnittstellen und schnelle Anpassungsfähigkeit. Der Schlüssel liegt darin, Compliance nicht als „zusätzliche Dokumentation“, sondern als eigenschaft des Delivery-Systems zu bauen: Prozesse, Controls und Evidenzen sind integriert – und damit dauerhaft auditierbar.

Dieser Artikel beschreibt, wie sich typische Anforderungen aus BAIT, DORA und MaRisk praktisch umsetzen lassen: mit Change Safety, Security-by-Design, Observability, sauberer Dokumentation und einem Betriebsmodell, das Prüfbarkeit und Stabilität erhöht.

Regulatorischer Kontext: BAIT, DORA, MaRisk – und was das für IT heißt

Regulatorische Anforderungen sind im Alltag oft nicht die Herausforderung an sich, sondern ihre Übersetzung in umsetzbare technische und organisatorische Maßnahmen:

• BAIT: Anforderungen an IT-Governance, Informationssicherheit, Identitäts- und Berechtigungsmanagement, Change/Release, Auslagerungen.

• DORA: Fokus auf operative Resilienz, Incident Management, Tests, Third-Party-Risiken, evidenzbasierte Nachweise.

• MaRisk: Risikomanagement, Kontrollsysteme und organisatorische Rahmenbedingungen.

Die Konsequenz: Nicht nur „das System“ muss sicher sein, sondern auch der Weg dorthin (Änderungen, Freigaben, Tests, Betrieb, Nachweise).

Auditierbarkeit: Was Prüfer in der Praxis sehen wollen

Auditfähigkeit entsteht durch konsistente Evidenzen – nicht durch nachträgliche Rekonstruktion. Typische Erwartungshaltungen:

• Nachvollziehbare Änderungen: Wer hat was wann geändert und warum (Ticket/Change Request, Code-Review, Freigaben)?

• Trennung von Verantwortlichkeiten: z. B. Vier-Augen-Prinzip, Rollen- und Rechtekonzepte, segregierte Umgebungen.

• Revisionssichere Protokollierung: zentral, manipulationssicher, mit definierter Aufbewahrung.

• Nachweisbare Controls: Security-Checks, Quality Gates, Policy Enforcement – dokumentiert und wiederholbar.

Technisch lässt sich viel davon systematisch abbilden: Git als Quelle der Wahrheit, CI/CD als ausführbarer Kontrollrahmen, zentralisiertes Logging und standardisierte Runbooks.

Change Safety: Änderungen sicher machen (ohne Delivery zu blockieren)

Viele Probleme in regulierten Umgebungen entstehen, wenn Change- und Release-Prozesse „parallel“ zur Technik laufen. Besser: Change Safety in die Delivery-Pipeline integrieren.

Vier-Augen-Prinzip und Freigaben als Pipeline-Bestandteil

• Pull/Merge Requests mit verpflichtendem Review

• geschützte Branches/Environments

• „Promotion“-Mechanismus: Artifact wird von dev → staging → prod befördert (kein „neu bauen“ in prod)

Das reduziert Risiken und schafft Evidenz. Für den technischen Unterbau ist ein solider CI/CD-Prozess zentral:

• CI/CD-Pipeline-Aufbau

Policy-as-Code für nachvollziehbare Regeln

Anforderungen wie „nur verschlüsselte Storage“ oder „keine offenen Security Groups“ sind als Code prüfbar:

• Open Policy Agent (OPA): https://www.openpolicyagent.org/

Damit werden Policies wiederholbar, versioniert und überprüfbar – und nicht zu Excel-Listen.

Immutable Infrastructure und Drift-Vermeidung

Wo möglich, lohnt sich ein „immutable“-Ansatz: statt manuell zu patchen, werden Systeme reproduzierbar ersetzt. Das reduziert Configuration Drift und vereinfacht Nachweise:

• Infrastructure as Code

• Automatisiertes Config-Management

Security-by-Design: Identitäten, Secrets, Härtung

Ein stabiler Kontrollrahmen beginnt mit Identitäten und Berechtigungen:

• Least Privilege und regelmäßige Rezertifizierung

• Privileged Access Management für admin-nahe Tätigkeiten

• Secrets Management statt Klartext-Konfiguration

• Härtung (Baseline) für Betriebssysteme, Container, Laufzeiten

Für tiefergehende Leitplanken und Compliance-Umsetzung ist ein ganzheitlicher Blick wichtig:

• Security & Compliance Beratung

Observability und Resilienz: von Verfügbarkeit zu operativer Steuerbarkeit

Banken-IT braucht nicht nur „Up/Down“-Monitoring, sondern Steuerbarkeit im Incident-Fall:

• Metriken: Latenz, Fehlerraten, Saturation, Batch-Laufzeiten

• Logs: zentral, strukturiert, mit Korrelations-IDs

• Tracing: für verteilte Systeme (z. B. API-Ketten)

• Alerting: signalbasiert (SLO-basiert), nicht nur „CPU > 80%“

Ein geeignetes Betriebsmodell verbindet das mit klaren Zielen:

• Monitoring & Observability

• SLA, SLO & Incident Response

Typische Kennzahlen für Management und Steuerung:

• RTO/RPO für Wiederherstellung,

• MTTR (Mean Time To Restore),

• Change Failure Rate (wie oft führen Änderungen zu Incidents),

• Patch Compliance (Zeit bis kritische Patches ausgerollt sind).

Drittparteien und Auslagerungen: Integration als Kontrollthema

Finanz-IT ist selten „nur intern“. Auslagerungen, Cloud-Provider, SaaS und Dienstleister sind Teil der Wertschöpfung. Praktische Maßnahmen:

• klare Verantwortlichkeiten und SLAs/SLOs,

• technische Überwachung (Provider-Metriken, Logs, Audit-Events),

• regelmäßige Tests (z. B. DR- und Failover-Übungen),

• sichere Schnittstellen und Token-/Key-Rotation.

Beispiel-Evidenzen: was sich automatisiert nachweisen lässt

Ein wiederkehrender Engpass in Audit‑Situationen ist die Nachweisführung. Viele Evidenzen lassen sich jedoch direkt aus Engineering‑Artefakten ableiten, wenn Prozesse sauber aufgesetzt sind:

• Change Historie: Tickets/Change Requests verlinkt in Pull Requests, inklusive Review‑Nachweis (Vier‑Augen‑Prinzip) und Merge‑Zeitpunkt.

• Release‑Nachweise: Pipeline‑Logs zeigen Build/Test/Security‑Checks, freigegebene Schritte und deployte Versionen (Artefakt‑Promotion).

• Policy‑Enforcement: Policy‑as‑Code Ergebnisse (OPA) dokumentieren, warum ein Change erlaubt oder blockiert wurde.

• Zugriffsereignisse: zentrale Audit‑Logs für IAM‑Änderungen und privilegierte Aktionen (wer, wann, was).

• Betriebsnachweise: Dashboards/SLO‑Reports, Incident‑Tickets, Postmortems und DR‑Test‑Protokolle.

Das reduziert „Audit‑Hektik“, weil Nachweise nicht mehr per Hand gesammelt werden müssen, sondern aus dem System heraus entstehen.

Quick Wins, die sich in regulierten Umgebungen bewährt haben

• Git + Pull Requests als verbindlicher Change-Kanal (kein „Hotfix per SSH“)

• Standardisierte Baseline via IaC/Config Management

• zentrales Logging inkl. Retention-Policy und Zugriffskonzept

• CI/CD Quality Gates (SAST, Dependency Scans, Policy-as-Code)

• Runbooks und regelmäßige Incident-Übungen

FAQ

Wie lassen sich BAIT/DORA-Controls pragmatisch automatisieren?

Indem Controls in den Delivery‑Pfad wandern: PR‑Reviews als Standard, Policy‑as‑Code in CI, zentralisierte Audit‑Logs und reproduzierbare Deployments. So entsteht Evidenz automatisch aus dem System.

Verlangsamt Compliance nicht zwangsläufig Delivery?

Nur, wenn Controls als nachgelagerte Freigaben organisiert sind. Werden Standards und Checks früh integriert (Templates, Guardrails), sinkt Rework – und Releases werden planbarer.

Was sind typische „Low Hanging Fruits“ in Bankenumgebungen?

Zentralisiertes Logging mit Retention/Access‑Konzept, IaC für Baselines, klare Patch‑SLAs, sowie SLO‑basierte Alarmierung. Das reduziert Audit‑Stress und verbessert Incident‑Fähigkeit.

Fazit

Regulierung muss kein Innovationshemmer sein, wenn Controls und Evidenzen Teil des Engineering- und Betriebsprozesses sind. Mit integrierter Change Safety, Policy-as-Code, reproduzierbarer Infrastruktur und solider Observability werden Audits planbarer – und gleichzeitig sinken operative Risiken und Incident-Kosten.