Right-to-Test
Right-to-Test Validation Workspace
Strukturierter Arbeitsraum für die systematische Ausübung des aufsichtlichen Rechts auf eigene Prüfung und Validierung beim Provider.
8
Validierungs-Checkpoints
7
Aktive Prüfungen
6
Hohe Priorität
8
DORA-Anforderungen
111
Aufwand (Std./Monat)
🎯 Was ist der Right-to-Test?
Der Right-to-Test gemäss DORA Artikel 28 Abs. 2 gibt Finanzinstituten das Recht, ihre IKT-Drittdienstleister eigenen Prüfungen zu unterziehen. Dieses Recht umfasst die Einsichtnahme in Systeme, die Durchführung von Sicherheitstests und die Validierung von Kontrollmassnahmen.
Dieser Workspace befähigt Ihr Institut, dieses Recht strukturiert, nachweisbar und aufsichtskonform auszuüben.
⚡ Praxis-Mehrwert
🔬 Validierungstypen im Überblick
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
🗓 Umsetzungsfahrplan Right-to-Test
Drei Phasen von der vertraglichen Verankerung bis zum vollständig operativen Right-Test-Nachweis
Vertragliche Verankerung des Right-to-Test, Einrichtung Dashboard-Zugang, Definition der Prüfintervalle
Regelmässige Durchführung aller Checkpoints, Aufbau von Evidence-Struktur, erstes Reporting
Reifegradsteigerung, vollständige Evidence-Basis, Berichterstattung an Vorstand und Aufsicht
📅 Jährlicher Prüfkalender
Monatliche Übersicht aller durchzuführenden Checkpoints. Quartalsweise Asset-Validierung sowie der jährliche Pentest sind farblich hervorgehoben.
Jan
Feb
Mär
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
✅ Validierungs-Checkpoints im Detail
8 CheckpointsProvider Scan Report Review
aktiv hochPrüfung der vom Provider bereitgestellten Scan-Berichte auf Vollständigkeit und Plausibilität
Read-Only Dashboard Review
aktiv hochAnalyse der Schwachstellendaten über das Read-Only Dashboard des Providers
Unabhängiger externer Penetrationstest
geplant kritischVom Institut beauftragter Penetrationstest der Provider-Umgebung (gemäss vereinbarten Grenzen)
Stichprobenartige Asset-Validierung
aktiv hochAbgleich der vom Provider gemeldeten Assets mit institutseigenen Erkenntnissen zur Identifikation von Shadow-IT
Patch-SLA-Compliance-Validierung
aktiv hochÜberprüfung der Einhaltung der vereinbarten Patch-SLAs durch unabhängige Zeitstempelprüfung
Kompensationsmassnahmen-Review
aktiv mittelPrüfung der Wirksamkeit von Kompensationsmassnahmen für gewährte Patch-Ausnahmen
Provider-eigene Schwachstellenbewertung prüfen
aktiv mittelPrüfung der vom Provider vorgenommenen CVSS-Bewertungen auf Plausibilität und Vollständigkeit
Right-to-Test-Ausübung protokollieren
aktiv hochDokumentation der Ausübung des Right-to-Test gemäss vertraglicher Vereinbarung und aufsichtlicher Erwartung
📜 DORA-Compliance-Matrix
8 AnforderungenMapping der Right-to-Test-Checkpoints auf aufsichtliche Anforderungen mit Coverage-Bewertung und identifizierten Lücken.
Institute müssen IKT-Risiken identifizieren, bewerten und überwachen
Lücke:
Keine direkte Verknüpfung mit dem institutseigenen IKT-Risikoinventar
Massnahme:
Right-to-Test-Ergebnisse in das institutseigene IKT-Risikoinventar überführen
Regelmässige Berichterstattung über IKT-Risiken an die Geschäftsleitung
Lücke:
Reporting-Vorlagen sind definiert, aber nicht mit dem institutseigenen Berichtswesen integriert
Massnahme:
Right-to-Test-Berichte in das standardisierte IKT-Reporting aufnehmen
Angemessene und verhältnismässige IKT-Sicherheitsmassnahmen
Führung eines Registers aller IKT-Drittparteien-Vereinbarungen
Lücke:
Asset-Validierung prüft nur die Asset-Seite, nicht die vertragliche Registrierung
Massnahme:
Asset-Validierung um Prüfung der Informationsregister-Einträge erweitern
Vertragliche Vereinbarung des Rechts auf Prüfung und Inspektion
Überwachung und Steuerung von IKT-Drittparteienrisiken
Lücke:
Nur Patch-SLA wird überwacht, weitere Drittparteienrisiken (Verfügbarkeit, Integrität) nicht
Massnahme:
Monitoring um weitere Leistungskennzahlen (Verfügbarkeit, Reaktionszeiten) erweitern
Steuerung und Überwachung von Auslagerungen gemäss MaRisk
Dokumentierte Risikoakzeptanzentscheidungen für verbleibende Risiken
⚖️ Vertragsklauseln (zur direkten Übernahme)
Geprüfte Formulierungsvorschläge für die vertragliche Verankerung des Right-to-Test. Vor Übernahme durch die Rechtsabteilung prüfen lassen.
Right-to-Test (Prüfungsrecht)
DORA Art. 28 Abs. 2Vertragliche Verankerung des aufsichtlichen Prüfungsrechts
Formulierungsvorschlag:
Der Dienstleister gewährt dem Institut das Recht, jederzeit eigene Prüfungen der IKT-Systeme und -Prozesse durchzuführen oder durch Dritte durchführen zu lassen. Dies umfasst insbesondere: (a) Einsichtnahme in alle relevanten Systeme, Logs und Konfigurationen, (b) Durchführung von Sicherheitstests einschliesslich Penetrationstests, (c) Validierung von Kontrollmassnahmen und (d) Überprüfung von Schwachstellenmanagement-Prozessen.
Read-Only Dashboard (Zugang)
DORA Art. 28 Abs. 2Einrichtung eines kontinuierlichen Lesezugriffs auf Schwachstellendaten
Formulierungsvorschlag:
Der Dienstleister stellt dem Institut einen jederzeit verfügbaren Read-Only-Dashboard-Zugang zur Verfügung, der mindestens folgende Daten in Echtzeit (maximale Datenverzögerung 4 Stunden) abbildet: aktuelle Schwachstellen nach Schweregrad, Patch-Status aller Assets, SLA-Einhaltungsquoten, offene Ausnahmen und Trendentwicklungen.
Penetrationstests (Recht auf eigene Tests)
DORA Art. 28 Abs. 2Regelung der Durchführung externer Sicherheitstests
Formulierungsvorschlag:
Der Dienstleister gestattet dem Institut oder von ihm beauftragten Dritten die Durchführung von Penetrationstests und Sicherheitsbewertungen in den vertraglich vereinbarten Testumgebungen. Die Tests sind mindestens 30 Tage im Voraus anzukündigen. Der Dienstleister stellt die erforderlichen Testumgebungen und Zugänge innerhalb von 10 Werktagen nach Ankündigung bereit.
Berichterstattung und Datenbereitstellung
DORA Art. 28, 30, MaRisk AT 9Regelmässige Bereitstellung von Prüfberichten und Metriken
Formulierungsvorschlag:
Der Dienstleister verpflichtet sich zur monatlichen Bereitstellung folgender Berichte und Daten: (a) vollständiger Schwachstellen-Scan-Report, (b) SLA-Compliance-Report, (c) Asset-Inventar (vierteljährlich), (d) Bericht über offene und geschlossene Ausnahmen (monatlich). Alle Berichte sind maschinenlesbar (JSON/CSV) und in einem vom Institut vorgegebenen Format bereitzustellen.
Sanktionen und Eskalation
DORA Art. 30, MaRisk AT 9Festlegung von Eskalationsstufen und vertraglichen Sanktionen
Formulierungsvorschlag:
Bei Überschreitung der vereinbarten Patch-SLAs um mehr als 50 % der jeweiligen Frist gelten folgende Eskalationsstufen: (1) Schriftliche Mahnung mit Fristsetzung von 5 Werktagen, (2) Vertragskonferenz mit Geschäftsführung beider Parteien innerhalb von 10 Werktagen, (3) Vertragliche Konventionalstrafe in Höhe von [Betrag] pro angefangenem Tag der Überschreitung, (4) Ausserordentliches Kündigungsrecht des Instituts bei Überschreitung der maximalen Eskalationsstufe.
🔍 Findings-Register (Beispiele)
5 FindingsErkannt in: Provider Scan Report Review
Beim monatlichen Abgleich der Scan-Berichte wurde eine kritische Schwachstelle (CVSS 9.8) identifiziert, die vom Provider nicht im vereinbarten Berichtsformat aufgeführt war.
Empfohlene Massnahme:
Sofortige Klärung mit Provider CISO, Nachforderung des vollständigen Scan-Berichts, Überprüfung der Reporting-Pflichten im Vertrag.
DORA Art. 28 Abs. 2 — Recht auf eigene Prüfung
Erkannt in: Read-Only Dashboard Review
Das Read-Only Dashboard des Providers zeigt Schwachstellendaten mit 48h Verzögerung, was eine zeitnahe Risikobewertung erschwert.
Empfohlene Massnahme:
Vertragliche Nachbesserung: maximal 4h Datenverzögerung, alternativ API-basierte Echtzeitanbindung.
DORA Art. 28 Abs. 2, Art. 5 — IKT-Risikomanagement
Erkannt in: Stichprobenartige Asset-Validierung
Beim Stichprobenabgleich wurden 3 Assets identifiziert, die im providergemeldeten Inventar nicht aufgeführt waren, jedoch vom Institut genutzt werden.
Empfohlene Massnahme:
Gemeinsame Bereinigung des Asset-Inventars, Einrichtung eines automatischen Abgleichs, vertragliche Nachschärfung der Meldepflichten.
DORA Art. 28 Abs. 1 — Informationsregister, MaRisk AT 9
Erkannt in: Patch-SLA-Compliance-Validierung
Ein kritischer Patch (CVSS 9.0) wurde 14 Stunden nach Ablauf der vereinbarten 48h-SLA eingespielt. Der Provider nannte interne Abstimmungsprozesse als Grund.
Empfohlene Massnahme:
Eskalation an Provider-Management, vertragliche Konventionalstrafe prüfen, Notfallprozess für kritische Patches definieren.
DORA Art. 30 — IKT-Drittparteienrisiko, MaRisk AT 9
Erkannt in: Kompensationsmassnahmen-Review
Für eine gewährte Patch-Ausnahme (90 Tage) konnte der Provider die Wirksamkeit der Kompensationsmassnahmen nicht durch aktuelle Log-Auswertungen belegen.
Empfohlene Massnahme:
Nachforderung der Wirksamkeitsnachweise innerhalb von 14 Tagen, bei Nichterfüllung Aussetzung der Ausnahme.
DORA Art. 6 — Risikoakzeptanz, MaRisk AT 7.3
📊 Reporting-Struktur
| Bericht | Zielgruppe | Frequenz | Inhalte | DORA-Bezug |
|---|---|---|---|---|
| Monatliches Right-to-Test-Reporting | CISO / IKT-Risikomanagement | monatlich | Durchgeführte Prüfungen, offene Findings, SLA-Einhaltung, Trendentwicklung | DORA Art. 5, 28 |
| Quartalsbericht Provider Governance | Auslagerungsmanagement / Risikokomitee | quartalsweise | Status aller Checkpoints, kritische Findings, Eskalationen, Massnahmenstatus | DORA Art. 28, 30, MaRisk AT 9 |
| Jährlicher Right-to-Test-Bericht | Vorstand / Aufsichtsrat / Revision | jährlich | Gesamtübersicht, Wirksamkeit der Prüfungen, Reifegrad, Verbesserungsmassnahmen, DORA-Konformität | DORA Art. 28 Abs. 2, Art. 5 Abs. 2 |
| Ad-hoc-Eskalationsbericht | CISO / Vorstand (bei kritischen Findings) | ad-hoc | Sofortmeldung bei kritischen Abweichungen mit Risikobewertung und Massnahmenplan | DORA Art. 28, Art. 30 |
📈 Kennzahlen & Programmsteuerung
7 KPIsMessgrössen zur Steuerung der Right-to-Test-Organisation mit Ampelschema (Grün/Gelb/Rot) und Zielwerten.
Anzahl durchgeführter Checkpoints pro Monat
Monatliche Auswertung der Prüfprotokolle
≥ 6 von 8 Checkpoints
monatlichSLA-Einhaltungsquote (kritische Patches)
Anteil der Patches, die innerhalb der vereinbarten SLA eingespielt wurden
≥ 98 %
monatlichFindings-Erledigungsquote (kritisch/hoch)
Anteil der kritischen/hohen Findings, die innerhalb von 30 Tagen geschlossen wurden
≥ 90 % innerhalb von 30 Tagen
monatlichØ Reaktionszeit bei kritischen Findings
Durchschnittliche Zeit von Identifikation bis zur ersten Reaktion/Eskalation
< 4 Stunden
monatlichRight-to-Test-Dokumentationsquote
Anteil der durchgeführten Prüfungen mit vollständiger Dokumentation
100 %
monatlichReporting-Fristeinhaltung
Anteil der fristgerecht erstellten Berichte (monatlich/quartalsweise/jährlich)
100 %
quartalsweiseAnzahl offener Findings (kritisch/hoch)
Gesamtanzahl ungelöster kritischer und hoher Findings
≤ 3
wöchentlich💰 Budgetplanung (Schätzung)
| Position | Kostenart | Std./Monat | Jahreskosten (€) |
|---|---|---|---|
| Interne Personalkapazität (CISO/SOC/IKT-Risiko) | Personal | 32 | 48.000 |
| Externer Penetrationstest (jährlich) | Dienstleistung | 0 | 35.000 |
| Right-to-Test-Software/Lizenzkosten | Lizenz | 0 | 12.000 |
| Schulung & Qualifikation Prüfteam | Qualifikation | 4 | 8.000 |
| Reporting & Dokumentation | Personal | 8 | 12.000 |
| Qualitätssicherung / Interne Revision | Personal | 4 | 6.000 |
| Gesamtkosten (geschätzt) | 121.000 € | ||
Die tatsächlichen Kosten variieren je nach Provider, Vertragskonstellation und institutsspezifischer Ausgestaltung.
🚨 Eskalations-Workflow
Dreistufiger Eskalationsprozess mit definierten Triggern, Reaktionszeiten und Verantwortlichkeiten.
Auslöser: Mittleres Finding, geringe SLA-Abweichung (< 24h)
Reaktionszeit: ≤ 24 Stunden
Verantwortlich: IKT-Risikomanagement
Massnahme: Dokumentation im Findings-Register, Information an CISO, Planung der Massnahme
Eskalation an: CISO (wöchentlich)
Auslöser: Hohes Finding, SLA-Überschreitung (> 24h), wiederholte Abweichung
Reaktionszeit: ≤ 8 Stunden
Verantwortlich: CISO / Information Security
Massnahme: Sofortmassnahme einleiten, Provider-Kontakt aufnehmen, vertragliche Eskalation prüfen
Eskalation an: Risikokomitee (innerhalb 48h)
Auslöser: Kritisches Finding, Ausfall kritischer Funktionen, systematisches Provider-Versagen
Reaktionszeit: ≤ 2 Stunden
Verantwortlich: CISO / Vorstand
Massnahme: Aktivierung Notfallplan, Vorstandsinformation, aufsichtliche Meldung (bei Wesentlichkeit), Vertragskündigung prüfen
Eskalation an: Vorstand / Aufsichtsrat (ad-hoc)
📋 Praxistools & Vorlagen
8 VorlagenCheckliste monatlicher Scan-Report-Review
PDF / ExcelSchritt-für-Schritt-Prüfliste für die Durchsicht der Provider-Scan-Berichte inkl. Abweichungsanalyse
Vorlage Abweichungsanalyse
Excel / DOCXStrukturierte Vorlage zur Dokumentation und Bewertung von Abweichungen zwischen Provider-Meldung und institutseigener Prüfung
Dashboard-Review-Protokoll (wöchentlich)
PDF / DOCXStandardisiertes Protokoll für die wöchentliche Sichtung des Read-Only-Dashboards mit Ampelschema
Right-to-Test-Jahresbericht Vorlage
PDF / DOCXUmfassende Berichtsvorlage für die jährliche Berichterstattung an Vorstand und Aufsichtsrat über die Ausübung des Right-to-Test
Asset-Validierungsprotokoll
ExcelVorlage zur Dokumentation der quartalsweisen Stichprobenvalidierung des Provider-Asset-Inventars
SLA-Compliance-Monitoring-Dashboard
Excel (Makro-frei)Excel-basiertes Monitoring-Tool zur Verfolgung der Patch-SLA-Einhaltung mit automatischer Ampelfunktion
Pentest-Scoping-Vorlage
DOCXStandardisiertes Scoping-Dokument für die Beauftragung externer Penetrationstests beim Provider
Right-to-Test-Ausübungsnachweis
PDF / DOCXFormular zur lückenlosen Dokumentation jeder Ausübung des Right-to-Test gemäss DORA Art. 28 Abs. 2
Hinweis zur Nutzung
Diese Vorlagen sind generische Arbeitshilfen. Passen Sie sie an Ihre institutsspezifischen Gegebenheiten, Vertragskonstellationen und das tatsächliche Risikoprofil des Providers an. Lassen Sie alle Vorlagen vor der ersten Nutzung durch Ihre Rechtsabteilung prüfen.
✅ Right-to-Test Praxis-Checkliste
Vollständige 60-Tage-Checkliste für den Aufbau der Right-to-Test-Organisation. Status und Verantwortlichkeiten eintragen.
Vertragliche Grundlagen
Right-to-Test-Klausel im Provider-Vertrag geprüft
Prüfrechte und -intervalle vertraglich definiert
Kostentragung für externe Tests geregelt
Vertraulichkeitsvereinbarung (NDA) aktualisiert
Technische Voraussetzungen
Read-Only-Dashboard-Zugang eingerichtet
API-Zugang für automatisierte Datenabfrage geprüft
Data-Loss-Prevention (DLP) für Dashboard-Zugang konfiguriert
Test-Umgebung für Penetrationstests abgestimmt
Organisatorische Vorbereitung
Prüfteam benannt (CISO, SOC, IKT-Risiko, Provider Management)
Prüfplan für alle Checkpoints erstellt
Eskalationsprozess für kritische Findings definiert
Reporting-Vorlagen erstellt und abgestimmt
Erste Schulung des Prüfteams durchgeführt
📝 Notizen
Keine Notizen. Erstellen Sie Ihre erste Notiz.