Zum Inhalt springen

Full-Scope Outsourcing

Full-Scope-Outsourcing Vulnerability Oversight

Strukturierte Governance-, Risiko- und Evidence-Architektur für das Schwachstellenmanagement bei vollständig ausgelagerten IKT-Services gemäss DORA Art. 5-8, 28-30 und MaRisk AT 9.

Hinweis: Diese Inhalte sind generische Umsetzungshilfen und ersetzen keine Rechtsberatung, keine aufsichtsrechtliche Auslegung, keine technische Sicherheitsprüfung und keine institutsspezifische Prüfung.

4

Sicherheitszonen

10

Provider-Assets

9

Scan-Typen

4

SLA-Stufen

4

Ausnahmen

17

Evidence-Items

🎯 Problemstellung

Finanzinstitute, die kritische Funktionen im Full-Scope-Outsourcing betreiben, stehen vor einem grundlegenden Dilemma:

Sie sind regulatorisch für das Schwachstellenmanagement verantwortlich — aber die operative Infrastruktur liegt vollständig beim Provider.

Der Provider betreibt Scanner, Patch-Management und ITSM-Prozesse. Das Institut muss dennoch sicherstellen, dass Schwachstellen erkannt, priorisiert, behoben und nachgewiesen werden können.

⚖️ Regulatorischer Rahmen

DORA Art. 5-8

IKT-Risikomanagement — Identifikation, Schutz, Erkennung, Reaktion, Wiederherstellung

DORA Art. 28-30

IKT-Drittparteienrisiko — Informationsregister, Due Diligence, Vertragsklauseln, Right-to-Test

MaRisk AT 9

Auslagerung — Wesentlichkeit, Risikoanalyse, Steuerung, Kontrolle, Dokumentation

ECB/SSM AI Letter (2026)

Beschleunigtes Patch-Management, Third-Party-Readiness-Prüfung, Management Body Oversight

🔑 Governance-Zone statt Blindflug

Die Plattform trennt konsequent zwischen Provider-Zone und Institut-Governance-Zone:

Provider

Assets · Scanner · operative Tickets · Patching · Staging · technische Remediation

Finanzinstitut

Informationsregister · Kontroll-Dashboard · SLA-Überwachung · Ausnahmefreigaben · Evidence · Eskalation

📋 Datenfluss & Kontrollarchitektur

Provider-Scanner → Secure API Gateway → Institut-Dashboard
Provider-ITSM → Ticket Mirror → Governance-Workspace
DORA Risk Score → SLA Breach Monitor → Eskalation
Right-to-Test → Independent Validation → Evidence Pack

🏛️ Zonenarchitektur für Full-Scope-Outsourcing

Vier Sicherheitszonen mit unterschiedlichen Zugriffsrechten, Kontrollebenen und Datenflüssen

Provider Operative Zone

Betrieb und Management der vom Provider betriebenen Systeme und Infrastruktur

hoch
📍 Beim Provider (Rechenzentrum/Cloud) 👤 Control Owner: Provider CISO / Provider Security Team 🔑 Nur Read-Only über Secure Integration Layer
provider_assets provider_scan_tools provider_itsm

Secure Integration Layer

Geschützte Kommunikations- und Datenaustauschschicht zwischen Provider und Institut

sehr hoch
📍 Hybrid (Provider-seitig mit institutsseitiger Kontrolle) 👤 Control Owner: Gemeinsam (Provider Operations + Institut Information Security) 🔑 Vollständig kontrolliert
secure_api_gateway information_register read_only_vulnerability_dashboard

Financial Institution Governance Zone

Institutseigene Governance, Risikobewertung und Entscheidungsfindung

sehr hoch
📍 Im Institut (On-Premise oder institutseigene Cloud) 👤 Control Owner: Institut (CISO, IKT-Risikomanagement, Auslagerungsmanagement) 🔑 Vollständig
governance_workspace evidence_repository

Evidence & Reporting Layer

Zentrale Sammlung, Aufbereitung und Bereitstellung von Nachweisen für Prüfung und Aufsicht

sehr hoch
📍 Im Institut 👤 Control Owner: Institut (Compliance, Interne Revision, CISO) 🔑 Vollständig
evidence_repository
Provider Operative Zone API / strukturierte Daten

Provider Asset Inventory

Vollständiges Inventar aller vom Provider betriebenen Assets

Provider Operative Zone API / Berichte

Provider Vulnerability Scanner

Schwachstellenscanner des Providers für infrastrukturelle und anwendungsspezifische Scans

Provider Operative Zone API / Webhook

Provider ITSM / Ticket-System

Ticket-System des Providers für Nachverfolgung von Schwachstellen

Secure Integration Layer REST API / GraphQL

Secure API Gateway

API-Gateway mit Authentisierung, Autorisierung und Verschlüsselung für Provider-Daten

Secure Integration Layer Datenbank / API

Information Register (kwF)

Register der kritischen und wichtigen Funktionen gemäss DORA

Secure Integration Layer Web-Dashboard / API

Read-Only Vulnerability Dashboard

Institutseigener, read-only Zugriff auf Schwachstellendaten des Providers

Financial Institution Governance Zone Web-Applikation

Governance Workspace

Arbeitsbereich für Risikobewertung, Entscheidungsfindung und Governance

Financial Institution Governance Zone Dokumentenmanagement-System

Evidence Repository

Zentrales Repository für Prüfungsnachweise und Dokumentation

📦 Provider-Asset-Synchronisation

Jedes Asset muss einer kritischen oder wichtigen Funktion zugeordnet werden

10 Assets
Asset (Placeholder) Typ Exposure Kritische Funktion DORA-Criticality CIF-Zuordnung Shadow-IT
PRV-DB-001 Datenbank intern Kernbankenplattform kritisch
PRV-APP-001 Anwendung extern Kundenportal kritisch
PRV-SRV-001 Server intern Transaktionsverarbeitung kritisch
PRV-NET-001 Netzwerkgerät intern Netzwerkinfrastruktur hoch
PRV-CNT-001 Container intern Microservice-Plattform hoch
PRV-STO-001 Storage intern Datenhaltung Kernbanksystem kritisch
PRV-DEV-001 Entwicklungsumgebung intern Softwareentwicklung niedrig ⚠️ Fehlt ⚠️
PRV-IAM-001 Identity & Access Management extern Berechtigungsmanagement kritisch
PRV-BKUP-001 Backup-System intern Notfallwiederherstellung hoch
PRV-API-001 API / Schnittstelle extern Open-Banking-Schnittstelle kritisch

🔬 Provider Scan Coverage Register

9 Scan-Typen
Scan-Typ Covered Assets Frequenz Letzter Scan Nächster Scan Exclusions Read-Only
Authenticated Infrastructure Scan Server, Datenbanken, Netzwerkgeräte wöchentlich Keine dokumentierten Ausschlüsse
External Perimeter Scan Externe IP-Bereiche, DMZ-Systeme wöchentlich Keine dokumentierten Ausschlüsse
Web App / API DAST Webanwendungen, APIs, Kundenportal monatlich Keine dokumentierten Ausschlüsse
SAST (Static Analysis) Quellcode eigener Anwendungen bei jedem Build Keine dokumentierten Ausschlüsse
SCA (Software Composition Analysis) Open-Source-Bibliotheken, Dependencies bei jedem Build Keine dokumentierten Ausschlüsse
Container Image Scan Docker-Images, Kubernetes-Container bei jedem Build & wöchentlich Keine dokumentierten Ausschlüsse
SBOM Review Software-Komponenten, Abhängigkeiten quartalsweise Keine dokumentierten Ausschlüsse
Cloud Configuration Review Cloud-Ressourcen, IAM-Richtlinien, Netzwerkkonfigurationen monatlich Keine dokumentierten Ausschlüsse
Identity & Privileged Access Review Administrative Accounts, Service-Accounts, IAM-Rollen monatlich Keine dokumentierten Ausschlüsse

📊 DORA Risk Score — Formel

DRS = CVSS × Asset-Kritikalität × Threat Intelligence × Exposure × Provider-Dependency

Asset-Kritikalitätsfaktor

Kritische Funktion (kwF)3
Hohe Kritikalität2
Mittlere Kritikalität1.5
Niedrige Kritikalität1

Threat-Intelligence-Faktor

Active Exploitation bekannt2
PoC verfügbar1.5
Kein Exploit bekannt1

Exposure-Faktor

Internet-exponiert2
Netzwerk-exponiert1.5
Isoliert / nicht-exponiert1

Provider-Dependency-Faktor

Vollständige Provider-Abhängigkeit2
Eingeschränkte Eingriffsmöglichkeit1.5
Gemeinsame Verantwortung1

📊 Klassifikation

>= 15 Sofortmassnahme innerhalb 4 Stunden
10 – 14.9 Massnahme innerhalb 24 Stunden
4 – 9.9 Massnahme innerhalb 7 Tagen
< 4 Im regulären Patch-Zyklus

⏱ Patch SLA Default-Profil

4 SLA-Stufen
Severity DRS Range Deadline Emergency Change Bank Approval Breach Escalation
critical >= 15 (Emergency) 24 Stunden ⚠️ Erforderlich Nachträgliche Genehmigung durch CISO Sofort an CISO + IKT-Risikomanagement + Management Body
high 10 – 14.9 (High) 7 Tage Nicht erforderlich, aber Dokumentation im Governance Workspace Nach 7 Tagen an CISO + Provider Manager
medium 4 – 9.9 (Medium) 30 Tage Nicht erforderlich Nach 30 Tagen an Provider Manager
low < 4 (Low) Regulärer Patch-Zyklus (90 Tage) Nicht erforderlich Nach 90 Tagen an Provider Manager (informativ)

⚠️ Diese Werte sind Defaults und erfordern institutsspezifische Kalibrierung.

🔄 Provider Ticket Mirror — Status-Mapping

New / Open Identified
Under Investigation Under Review
Identified / Confirmed Confirmed
In Progress Remediation in Progress
Resolved / Fixed Remediated
Verified by Provider Verified
Exception / Deferred Exception Granted
Closed / Done Closed
Reopened Reopened

🚨 SLA Breach Monitor — Eskalationsstufen

SLA Warning SLA-Zeitfenster zu 80 % ausgeschöpft
⬆️ Automatische Benachrichtigung an Provider Manager und zuständigen Fachbereich 🔁 Bestätigung der SLA-Einhaltung innerhalb von 4 Stunden 📢
SLA Breach (First Alert) SLA-Zeitfenster überschritten (bis zu 24h über Deadline)
⬆️ Automatische Eskalation an CISO und IKT-Risikomanagement. Anforderung eines Lageberichts vom Provider. 🔁 Lagebericht und aktualisierter Behebungsplan innerhalb von 24 Stunden 📢
SLA Breach (Second Alert) SLA-Überschreitung > 24 Stunden bis 7 Tage
⬆️ Eskalation an Management Body. Einleitung von Vertragsstrafen gemäss SLA-Vereinbarung. 🔁 Schriftlicher Massnahmenplan und Eskalation innerhalb des Providers erforderlich 📢 1
SLA Breach (Critical) SLA-Überschreitung > 7 Tage oder kritische Schwachstelle nicht behoben
⬆️ Sofortige Vorlage im Risikoausschuss. Prüfung von Exit-Optionen gemäss DORA Artikel 28. 🔁 Ad-hoc-Bericht an den Vorstand. Einberufung des Krisenstabs. 📢 1
Systematic Failure Wiederholte SLA-Verstösse (> 3 in 90 Tagen) oder systematisches Versagen des Provider-Patch-Managements
⬆️ Vorlage im Gesamtvorstand. Prüfung der ausserordentlichen Kündigung. Meldung an die Aufsicht gemäss DORA Artikel 15. 🔁 Strategischer Massnahmenplan. Evaluierung alternativer Provider. 📢 1

⚠️ Patch Exception Register

4 Ausnahmen

PVG-EX-001: CVE-2026-XXXX

Asset: PRV-DB-001 (Kernbanken-Datenbank) · DORA Risiko: 16.5

Review:

Grund: Patch verursacht Inkompatibilität mit kundenspezifischer Anpassung, vollständige Regressionstests erforderlich

Kompensierende Kontrolle: Netzwerksegmentierung der Datenbank auf isoliertes VLAN, WAF-Regel zur Blockade bekannter Exploit-Vektoren, Erhöhtes Monitoring (24×7) der Datenbankzugriffe, Intrusion-Detection-Signatur für CVE-spezifische Angriffsmuster aktiviert, Manuelle tägliche Prüfung der Zugriffslogs auf Anomalien

👤 CISO (nach Rücksprache mit IKT-Risikomanagement) 🔁 Dauer: 30 Tage

PVG-EX-002: CVE-2026-YYYY

Asset: PRV-SRV-001 (Legacy-Transaktionsserver) · DORA Risiko: 12.3

Review:

Grund: Betriebssystemversion wird vom Hersteller nicht mehr supported, Migration auf neue Version in Planung

Kompensierende Kontrolle: Strikte Netzwerksegmentierung (nur noch Kommunikation mit autorisierten Systemen), Application-Level-Whitelisting aktiviert, Erhöhtes Monitoring auf bekannte Angriffsmuster, Wöchentliches Vulnerability-Scanning des isolierten Segments, Beschleunigte Migration auf supported Version (Projekt mit definiertem Meilenstein)

👤 CISO 🔁 Dauer: 90 Tage

PVG-EX-003: CVE-2026-ZZZZ

Asset: PRV-APP-001 (Kundenportal Drittanbieter-Komponente) · DORA Risiko: 8.1

Review:

Grund: Patch muss vom Softwarehersteller bereitgestellt werden, Veröffentlichung für Q3/2026 angekündigt

Kompensierende Kontrolle: WAF-Regel zur Blockade bekannter Exploit-Vektoren, Regelmässiger Austausch mit Hersteller zum Patch-Status, Manuelle Überprüfung der betroffenen Funktionalität

👤 CISO 🔁 Dauer: 120 Tage

PVG-EX-004: CVE-2026-AAAA

Asset: PRV-NET-001 (Netzwerk-Firewall) · DORA Risiko: 11

Review:

Grund: Hersteller hat End-of-Life angekündigt, kein Patch mehr verfügbar. Hardware-Austausch in Planung.

Kompensierende Kontrolle: Ersatzbeschaffung eingeleitet (Projekt mit Meilensteinplan), Erhöhte Überwachung der Firewall-Logs, Regelmässige manuelle Konfigurationsprüfung, Segmentierung hinter weiterer Firewall-Ebene (Defence-in-Depth)

👤 CISO (mit Vorlage im Risikoausschuss) 🔁 Dauer: 180 Tage

✅ Right-to-Test Prüfpunkte

Provider Scan Report Review

Prüfung der vom Provider bereitgestellten Scan-Berichte auf Vollständigkeit und Plausibilität

Read-Only Dashboard Review

Analyse der Schwachstellendaten über das Read-Only Dashboard des Providers

Unabhängiger externer Penetrationstest

Vom Institut beauftragter Penetrationstest der Provider-Umgebung (gemäss vereinbarten Grenzen)

Stichprobenartige Asset-Validierung

Abgleich der vom Provider gemeldeten Assets mit institutseigenen Erkenntnissen zur Identifikation von Shadow-IT

Patch-SLA-Compliance-Validierung

Überprüfung der Einhaltung der vereinbarten Patch-SLAs durch unabhängige Zeitstempelprüfung

Kompensationsmassnahmen-Review

Prüfung der Wirksamkeit von Kompensationsmassnahmen für gewährte Patch-Ausnahmen

Provider-eigene Schwachstellenbewertung prüfen

Prüfung der vom Provider vorgenommenen CVSS-Bewertungen auf Plausibilität und Vollständigkeit

Right-to-Test-Ausübung protokollieren

Dokumentation der Ausübung des Right-to-Test gemäss vertraglicher Vereinbarung und aufsichtlicher Erwartung

🔬 Validierungsarten

Dokumentenprüfung

Prüfung der vom Provider bereitgestellten Dokumente und Berichte auf Vollständigkeit und Plausibilität

Technische Prüfung

Technische Überprüfung von Schwachstellendaten, Logs oder Konfigurationen (Read-Only)

Externer Test

Vom Institut beauftragte unabhängige Sicherheitstests beim Provider

Abgleich / Reconciliation

Systematischer Abgleich von Provider-Daten mit institutseigenen Datenquellen

Datenanalyse

Automatisierte oder manuelle Analyse von Performance-Daten, SLA-Einhaltung und Trends

Dokumentation

Systematische Dokumentation der Ausübung von Prüfungs- und Kontrollrechten

📁 Provider Vulnerability Evidence Pack

17 Evidence-Items

Provider Vulnerability Scope Definition

Nachweis der definierten Scope-Abgrenzung fuer das Schwachstellenmanagement beim Provider inkl. Verantwortungsmatrix

DORA Artikel 28, MaRisk AT 9
📋 Auslagerungsmanagement 🔄 Jaehrlich oder bei Vertragsaenderung

Provider Asset Inventory (synchronisiert)

Nachweis des vollstaendigen, synchronisierten Asset-Inventars des Providers inkl. CIF-Zuordnung und Shadow-ICT-Erkennung

DORA Artikel 6, MaRisk AT 7.3
📋 Provider Manager 🔄 Laufend (automatisierte Synchronisation)

Provider Scan Coverage Report

Nachweis der vollstaendigen Scan-Abdeckung aller relevanten Provider-Assets inkl. Ausschluessen und Begruendungen

DORA Artikel 9, MaRisk AT 7.3
📋 Provider Manager / Information Security 🔄 Monatlich

DORA Risk Score Berechnungen (alle aktuellen Findings)

Nachweis der risikobasierten Priorisierung aller aktuellen Provider-Schwachstellen nach DORA Risk Score 2.0

DORA Artikel 6, 7, MaRisk AT 7.3
📋 IKT-Risikomanagement 🔄 Bei jeder neuen Schwachstelle oder Aenderung

Provider Patch SLA Compliance Report

Nachweis der Einhaltung der vereinbarten Patch-SLAs durch den Provider inkl. Abweichungsanalyse

DORA Artikel 28, 29, MaRisk AT 7.3
📋 Provider Manager 🔄 Monatlich

Ticket Mirror Status Log

Nachweis der Synchronisation und Nachverfolgung aller Provider-Schwachstellen-Tickets inkl. Status-Mapping

DORA Artikel 9, MaRisk AT 7.3
📋 IT Operations / Provider Manager 🔄 Kontinuierlich (Echtzeit)

SLA Breach Escalation Protocol

Nachweis der ordnungsgemaessen Eskalation bei allen SLA-Verstoessen des Providers inkl. Zeitstempel und Entscheidungen

DORA Artikel 28, MaRisk AT 7.3
📋 Provider Manager 🔄 Ereignisgesteuert

Patch Exception Register (aktuell)

Nachweis der kontrollierten Ausnahmeverwaltung fuer Patch-Vorgaben beim Provider inkl. Kompensationsmassnahmen

DORA Artikel 6, 7, MaRisk AT 7.3
📋 IKT-Risikomanagement / CISO 🔄 Laufend (bei jeder Ausnahme)

Compensating Control Effectiveness Report

Nachweis der Wirksamkeit von Kompensationsmassnahmen fuer gewaehrte Patch-Ausnahmen

DORA Artikel 6, 7, MaRisk AT 7.3
📋 Information Security 🔄 Monatlich

Right-to-Test Ausuebungsnachweis

Nachweis der systematischen Ausuebung des aufsichtlichen Rechts auf eigene Pruefung beim Provider

DORA Artikel 28 Abs. 2, MaRisk AT 9
📋 Provider Manager / Interne Revision 🔄 Jaehrlich (mit Nachweisen der kontinuierlichen Ausuebung)

Independent Validation / Pentest Report

Nachweis der unabhaengigen Validierung der Provider-Sicherheitslage durch institutsbeauftragte Dritte

DORA Artikel 28 Abs. 2, MaRisk AT 7.3
📋 CISO / Interne Revision 🔄 Jaehrlich

Provider Vulnerability Governance Report (Management)

Strukturierter Bericht fuer das Management ueber den Status des Provider-Schwachstellenmanagements

DORA Artikel 5, MaRisk AT 4.3.1
📋 CISO / IKT-Risikomanagement 🔄 Quartalsweise

Provider Vulnerability Audit Pack

Vollstaendiger Pruefungsordner fuer externe und interne Pruefungen des Provider-Schwachstellenmanagements

DORA Artikel 5, 6, 28, 29, MaRisk AT 4.3.3
📋 Interne Revision / Compliance 🔄 Bei Pruefungsanlass

Architecture & Data Flow Diagram (Provider Integration)

Nachweis der Zonenarchitektur und Datenfluesse zwischen Provider und Institut

DORA Artikel 9, MaRisk AT 7.3
📋 IT-Architect 🔄 Jaehrlich oder bei Architekturaenderung

Provider Vulnerability Management Policy (institutseigen)

Nachweis der institutseigenen Richtlinie fuer das Schwachstellenmanagement beim Provider

DORA Artikel 9, MaRisk AT 7.3
📋 CISO 🔄 Jaehrliche Ueberpruefung

Provider SLA-Vertragsklauseln (Schwachstellenmanagement)

Nachweis der vertraglichen Verankerung von Patch-SLAs und Schwachstellenmanagement im Provider-Vertrag

DORA Artikel 28, 29, MaRisk AT 9
📋 Auslagerungsmanagement / Legal 🔄 Bei Vertragsschluss oder -aenderung

Management Escalation & Decision Log

Nachweis der dokumentierten Entscheidungen des Managements zu Provider-Schwachstellen und Eskalationen

DORA Artikel 5, MaRisk AT 4.3.1
📋 IKT-Risikomanagement 🔄 Ereignisgesteuert