[ { "id": "DORA-GOV-001", "title": "Leitungsorgan verankert Resilienzstrategie im Jahreszielprozess", "theme": "Governance & Verantwortung", "requirement_type": "Governance-Verfahren", "control_objective": "Resilienzprioritäten werden vom Leitungsorgan gesteuert und budgetwirksam beschlossen.", "target_state": "Strategie, Risikoappetit und Umsetzungsziele sind pro Jahr formal freigegeben und nachverfolgbar.", "implementation_steps": [ "Resilienzstrategie als festen Tagesordnungspunkt im Leitungsorgan verankern.", "Jahresziele mit Risikoindikatoren und Budgetpositionen verknüpfen.", "Quartalsweise Zielerreichung inklusive Abweichungsbehandlung berichten." ], "evidence_examples": [ "Beschlussprotokoll des Leitungsorgans mit Zielkatalog.", "Budgetfreigabe mit Zuordnung zu Resilienzinitiativen." ], "iso_control_anchors": [ "5.1", "5.4", "5.36" ], "dora_reference": "DORA Kapitel II (Governance)", "marisk_reference": "MaRisk AT 4.3.1", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-GOV-002", "title": "Rollenmodell für Three-Lines-Resilienzsteuerung", "theme": "Governance & Verantwortung", "requirement_type": "Governance-Verfahren", "control_objective": "Verantwortlichkeiten für Umsetzung, Überwachung und Prüfung sind eindeutig abgegrenzt.", "target_state": "Ein verbindliches Rollenmodell definiert Aufgaben, Eskalationsrechte und Stellvertretung.", "implementation_steps": [ "RACI-Matrix für Business, IT, Compliance und Revision erstellen.", "Eskalationsschwellen und Entscheidungswege je Kontrollprozess festlegen.", "Rollenmodell in Richtlinie und Schulung verbindlich machen." ], "evidence_examples": [ "Freigegebene RACI-Matrix mit Versionshistorie.", "Schulungsnachweise für Rolleninhaber." ], "iso_control_anchors": [ "5.2", "5.3", "5.37" ], "dora_reference": "DORA Kapitel II (Interne Organisation)", "marisk_reference": "MaRisk AT 4.4.1", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-GOV-003", "title": "Management-Reporting mit Frühwarnindikatoren", "theme": "Governance & Verantwortung", "requirement_type": "Governance-Verfahren", "control_objective": "Leitungsentscheidungen basieren auf konsistenten Resilienzkennzahlen und Trends.", "target_state": "Monatliches Reporting mit KRI, Schwellwerten und Maßnahmenstatus ist etabliert.", "implementation_steps": [ "KRI-Katalog mit Ampellogik und Datenquellen definieren.", "Datenqualitätsprüfung für Kennzahlen automatisieren.", "Management-Deck mit Risiken, Ursachen und Gegenmaßnahmen standardisieren." ], "evidence_examples": [ "Monatsreport mit KRI-Entwicklung.", "Nachweis über Schwellwertverletzungen und Eskalationen." ], "iso_control_anchors": [ "5.7", "5.35", "8.16" ], "dora_reference": "DORA Kapitel II (Steuerungsinformationen)", "marisk_reference": "MaRisk BT 3.1", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-GOV-004", "title": "Resilienzkompetenz für Entscheidungsträger ausbauen", "theme": "Governance & Verantwortung", "requirement_type": "Governance-Verfahren", "control_objective": "Entscheidungsträger verstehen operationale Risiken, Abhängigkeiten und regulatorische Wirkung.", "target_state": "Kompetenzprofile und Trainingspfad für Leitungsorgan und Schlüsselrollen sind umgesetzt.", "implementation_steps": [ "Kompetenzlueckenanalyse für relevante Rollen durchführen.", "Pflichttrainings mit Fallbeispielen aus dem Institut aufsetzen.", "Wirksamkeit per Wissenscheck und Entscheidungsqualitaet nachhalten." ], "evidence_examples": [ "Trainingsplan mit Teilnahmequote.", "Auswertung der Kompetenzchecks je Rolle." ], "iso_control_anchors": [ "6.3", "6.4", "5.36" ], "dora_reference": "DORA Kapitel II (Ressourcen und Fähigkeiten)", "marisk_reference": "MaRisk AT 7.1", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-RISK-001", "title": "Institutsspezifische IKT-Risikotaxonomie etablieren", "theme": "IKT-Risikomanagement", "requirement_type": "Risikosteuerung", "control_objective": "IKT-Risiken werden einheitlich erfasst und vergleichbar bewertet.", "target_state": "Taxonomie, Bewertungslogik und Risikokriterien sind konzernweit konsistent dokumentiert.", "implementation_steps": [ "Risikokategorien für Verfügbarkeit, Integrität, Vertraulichkeit und Lieferketten definieren.", "Einheitliche Bewertungsskala für Eintritt, Auswirkung und Restrestrisiko festlegen.", "Taxonomie in Risiko-Tool und Kontrollprozesse integrieren." ], "evidence_examples": [ "Freigegebene Risikotaxonomie mit Definitionen.", "Beispielbewertung inkl. Begruendung je Kategorie." ], "iso_control_anchors": [ "5.9", "5.12", "8.2" ], "dora_reference": "DORA Kapitel II (IKT-Risikomanagementrahmen)", "marisk_reference": "MaRisk AT 4.3.2", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-RISK-002", "title": "Risikobewertung für kritische Geschaeftsservices priorisieren", "theme": "IKT-Risikomanagement", "requirement_type": "Risikosteuerung", "control_objective": "Steuerungsmaßnahmen orientieren sich an den kritischsten Serviceketten.", "target_state": "Jeder kritische Service besitzt dokumentiertes Risikoexposure und priorisierte Maßnahmen.", "implementation_steps": [ "Kritische Services mit maximaler tolerierbarer Ausfallzeit bestimmen.", "Abhängigkeiten zu Anwendungen, Daten und Providern erfassen.", "Maßnahmen nach Risikoauswirkung priorisieren und terminieren." ], "evidence_examples": [ "Servicekritikalitaetsliste mit Schwellenwerten.", "Maßnahmenbacklog mit Priorität und Verantwortlichen." ], "iso_control_anchors": [ "5.30", "8.9", "8.13" ], "dora_reference": "DORA Kapitel II (Kritische Funktionen)", "marisk_reference": "MaRisk AT 7.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-RISK-003", "title": "Kontrollüberwachung auf Wirksamkeit statt nur Vollständigkeit ausrichten", "theme": "IKT-Risikomanagement", "requirement_type": "Risikosteuerung", "control_objective": "Kontrollen reduzieren reale Risiken nachweisbar im Betrieb.", "target_state": "Kontrollen sind mit Wirksamkeitsmetriken, Testfrequenz und Verbesserungszyklen versehen.", "implementation_steps": [ "Top-Kontrollen je Risiko mit erwarteter Wirkung definieren.", "Regeltest mit klaren Pass/Fail-Kriterien einführen.", "Defizite in einen verbindlichen Verbesserungsprozess überfuehren." ], "evidence_examples": [ "Kontrollkatalog mit Wirksamkeitskennzahl.", "Abweichungsprotokoll mit Korrekturmaßnahmen." ], "iso_control_anchors": [ "5.35", "8.16", "10.2" ], "dora_reference": "DORA Kapitel II (Kontrollrahmen)", "marisk_reference": "MaRisk AT 4.4.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-RISK-004", "title": "Risikoreviews mit Change-Management koppeln", "theme": "IKT-Risikomanagement", "requirement_type": "Risikosteuerung", "control_objective": "Wesentliche Architektur- und Prozessaenderungen werden risikobasiert freigegeben.", "target_state": "Jeder High-Impact-Change beinhaltet eine aktualisierte Risikoanalyse vor Go-live.", "implementation_steps": [ "Triggerkriterien für risikorelevante Changes definieren.", "Risikoprüfung als Pflichtschritt im Freigabeworkflow hinterlegen.", "Post-Implementation-Review mit Soll-Ist-Abgleich durchführen." ], "evidence_examples": [ "Change-Tickets mit Risiko-Checkliste.", "Freigabeprotokolle inklusive Restrestrisiko." ], "iso_control_anchors": [ "8.32", "8.33", "8.34" ], "dora_reference": "DORA Kapitel II (Aenderungssteuerung)", "marisk_reference": "MaRisk AT 8.2", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-PDR-001", "title": "Schutzbedarfsgerechte Härtung kritischer Systeme", "theme": "Schutz, Erkennung & Reaktion", "requirement_type": "Operative Sicherheitskontrolle", "control_objective": "Kritische Systeme werden nach verbindlichen Sicherheitsbaselines betrieben.", "target_state": "Baselines, Ausnahmen und Nachhaertungen sind technisch nachvollziehbar gesteuert.", "implementation_steps": [ "Systemklassen und zugehoerige Hardening-Standards definieren.", "Automatisierte Baseline-Prüfung in den Betriebsprozess integrieren.", "Ausnahmen zeitlich befristen und aktiv nachverfolgen." ], "evidence_examples": [ "Hardening-Standard pro Systemklasse.", "Compliance-Report mit offenen Abweichungen." ], "iso_control_anchors": [ "8.9", "8.20", "8.21" ], "dora_reference": "DORA Kapitel II (Schutzmaßnahmen)", "marisk_reference": "MaRisk AT 7.2", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-PDR-002", "title": "Detektion mit Use-Case-gestuetztem Monitoring verbessern", "theme": "Schutz, Erkennung & Reaktion", "requirement_type": "Operative Sicherheitskontrolle", "control_objective": "Sicherheitsrelevante Anomalien werden früh erkannt und priorisiert bearbeitet.", "target_state": "Monitoring-Use-Cases sind risikobasiert priorisiert und mit Reaktionsfristen versehen.", "implementation_steps": [ "Top-Risikoszenarien in überwachte Detection-Use-Cases überfuehren.", "Alarmqualitaet über False-Positive-Rate und Erkennungszeit messen.", "Use-Cases quartalsweise anhand neuer Bedrohungen aktualisieren." ], "evidence_examples": [ "Use-Case-Backlog mit Priorisierung.", "SOC-Kennzahlenreport zu MTTD und Alarmqualitaet." ], "iso_control_anchors": [ "8.16", "8.7", "5.7" ], "dora_reference": "DORA Kapitel II (Erkennungsfähigkeiten)", "marisk_reference": "MaRisk BT 3.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-PDR-003", "title": "Reaktionsplaybooks für priorisierte Angriffspfade", "theme": "Schutz, Erkennung & Reaktion", "requirement_type": "Operative Sicherheitskontrolle", "control_objective": "Sicherheitsvorfälle werden wiederholbar und innerhalb definierter Fristen bearbeitet.", "target_state": "Playbooks mit Rollen, Entscheidungspunkten und Kommunikationswegen sind geuebt.", "implementation_steps": [ "Playbooks für Ransomware, Datenabfluss und Lieferantenausfall entwickeln.", "Freigabe durch Technik, Fachbereich und Kommunikation einholen.", "Halbjährliche Übungen mit Lessons Learned durchführen." ], "evidence_examples": [ "Versionierte Incident-Playbooks.", "Uebungsprotokolle mit Nachverfolgung der Findings." ], "iso_control_anchors": [ "5.24", "5.26", "5.29" ], "dora_reference": "DORA Kapitel II (Reaktionsfähigkeit)", "marisk_reference": "MaRisk BT 3.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-PDR-004", "title": "Wiederherstellung mit priorisierten Recovery-Routen absichern", "theme": "Schutz, Erkennung & Reaktion", "requirement_type": "Operative Sicherheitskontrolle", "control_objective": "Kritische Services werden in tolerierbarer Zeit wiederhergestellt.", "target_state": "Recovery-Routen, technische Abhängigkeiten und Wiederanlaufkriterien sind testbar dokumentiert.", "implementation_steps": [ "Recovery-Ziele je Service verbindlich festlegen.", "Abhängigkeiten für Daten, Infrastruktur und externe Dienste dokumentieren.", "Wiederherstellungstests nach priorisierten Szenarien durchführen." ], "evidence_examples": [ "Service-Recovery-Blueprints mit RTO/RPO.", "Testberichte mit Ist-Zeiten und Maßnahmenplan." ], "iso_control_anchors": [ "5.30", "8.14", "8.13" ], "dora_reference": "DORA Kapitel II (Wiederherstellung)", "marisk_reference": "MaRisk AT 7.3", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-INC-001", "title": "Klassifikation für IKT-Vorfälle mit Meldebezug", "theme": "IKT-Vorfälle", "requirement_type": "Vorfallverfahren", "control_objective": "Vorfälle werden einheitlich eingestuft und regulatorisch korrekt behandelt.", "target_state": "Klassifikation enthält Schweregrade, Meldefristen und Eskalationspfade.", "implementation_steps": [ "Kriterien für signifkante Vorfälle und Beinahevorfälle definieren.", "Meldepflichtlogik in den Incident-Prozess integrieren.", "Eskalationszeiten je Schweregrad verbindlich machen." ], "evidence_examples": [ "Incident-Klassifikationsschema mit Entscheidungshilfe.", "Historie eskalierter Vorfälle." ], "iso_control_anchors": [ "5.24", "5.25", "5.26" ], "dora_reference": "DORA Kapitel III (IKT-bezogene Vorfälle)", "marisk_reference": "MaRisk BT 3.2", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-INC-002", "title": "Vollständige Vorfallsdokumentation über den Lebenszyklus", "theme": "IKT-Vorfälle", "requirement_type": "Vorfallverfahren", "control_objective": "Entscheidungen und Maßnahmen sind für Aufsicht und Revision transparent.", "target_state": "Jeder wesentliche Vorfall besitzt Timeline, Ursachenanalyse und Abschlussbewertung.", "implementation_steps": [ "Pflichtfelder für Incident-Tickets definieren.", "Post-Incident-Review mit Root-Cause-Methodik standardisieren.", "Abschlussfreigabe an Nachweis der Gegenmaßnahmen koppeln." ], "evidence_examples": [ "Abgeschlossene Incident-Tickets mit Vollständigkeitsscore.", "Root-Cause-Reports mit Verantwortlichen." ], "iso_control_anchors": [ "5.28", "5.35", "10.2" ], "dora_reference": "DORA Kapitel III (Dokumentation und Analyse)", "marisk_reference": "MaRisk AT 4.4.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-INC-003", "title": "Aufsichtsreporting für Vorfälle fristgenau orchestrieren", "theme": "IKT-Vorfälle", "requirement_type": "Vorfallverfahren", "control_objective": "Erst-, Zwischen- und Abschlussmeldungen erfolgen konsistent und termingerecht.", "target_state": "Meldeprozess ist mit klaren Freigaben, Datenquellen und Vertretungen hinterlegt.", "implementation_steps": [ "Meldekalender und Trigger für Meldephaasen definieren.", "Freigabeprozess zwischen Technik, Recht und Compliance abstimmen.", "Qualitätskontrolle für meldepflichtige Inhalte einführen." ], "evidence_examples": [ "Meldeprozessdiagramm mit Rollen.", "Archiv fristgerechter Meldungen." ], "iso_control_anchors": [ "5.5", "5.6", "5.24" ], "dora_reference": "DORA Kapitel III (Meldepflichten)", "marisk_reference": "MaRisk BT 3.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-INC-004", "title": "Vorfallschleifen in nachhaltige Verbesserungen überfuehren", "theme": "IKT-Vorfälle", "requirement_type": "Vorfallverfahren", "control_objective": "Wiederkehrende Ursachen werden systematisch reduziert.", "target_state": "Lessons Learned sind priorisiert, terminiert und auf Wirksamkeit geprüft.", "implementation_steps": [ "Vorfallcluster nach Ursache und Wirkung analysieren.", "Top-Ursachen in ein institutweites Verbesserungsprogramm überfuehren.", "Wirksamkeit über Trend-KPI und Revisionsfeedback messen." ], "evidence_examples": [ "Lessons-Learned-Backlog mit Reifegradstatus.", "Trendbericht wiederkehrender Ursachen." ], "iso_control_anchors": [ "10.1", "10.2", "5.27" ], "dora_reference": "DORA Kapitel III (Kontinuierliche Verbesserung)", "marisk_reference": "MaRisk AT 4.4.2", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TST-001", "title": "Risikobasierte Teststrategie für digitale Resilienz", "theme": "Digitale Resilienztests", "requirement_type": "Testverfahren", "control_objective": "Tests decken die kritischsten Ausfallszenarien und Angriffspfade ab.", "target_state": "Mehrjahres-Testplan ist risikobasiert priorisiert und mit Governance abgestimmt.", "implementation_steps": [ "Testinventar nach Szenario, Tiefe und Frequenz strukturieren.", "Priorisierung anhand Kritikalität, Bedrohung und Veraenderungsdynamik durchführen.", "Abweichungen und Verschiebungen mit Managementfreigabe dokumentieren." ], "evidence_examples": [ "Freigegebener Resilienz-Testplan.", "Priorisierungsmatrix mit Bewertungslogik." ], "iso_control_anchors": [ "8.8", "5.30", "9.1" ], "dora_reference": "DORA Kapitel IV (Testprogramm)", "marisk_reference": "MaRisk AT 4.3.5", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TST-002", "title": "Szenariobasierte Übungen für technische und fachliche Teams", "theme": "Digitale Resilienztests", "requirement_type": "Testverfahren", "control_objective": "Zusammenspiel von Fachbereich, IT und Krisenorganisation wird realitätsnah validiert.", "target_state": "Uebungsszenarien umfassen technische Stoerung, Lieferantenausfall und Kommunikationsdruck.", "implementation_steps": [ "Szenarien mit institutsspezifischen Angriffspfaden entwickeln.", "Uebungsteam und Beobachterrollen verbindlich benennen.", "Ergebnisse mit klaren Umsetzungsfristen nachverfolgen." ], "evidence_examples": [ "Uebungsdrehbuch und Teilnehmerliste.", "Maßnahmenprotokoll aus der Uebungsnachbereitung." ], "iso_control_anchors": [ "5.29", "5.30", "5.24" ], "dora_reference": "DORA Kapitel IV (Szenariobasierte Tests)", "marisk_reference": "MaRisk AT 7.3", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TST-003", "title": "TLPT-Vorbereitung mit klarer Scope- und Sicherheitssteuerung", "theme": "Digitale Resilienztests", "requirement_type": "Testverfahren", "control_objective": "Threat-Led-Tests liefern verwertbare Erkenntnisse ohne unkontrolliertes Betriebsrisiko.", "target_state": "Scope, Sicherheitsgrenzen und Kommunikationskaskaden für TLPT sind abgestimmt.", "implementation_steps": [ "Kritische Assets und Testgrenzen mit Fachbereich abstimmen.", "Rules of Engagement mit internen und externen Parteien fixieren.", "Notfallstopp und Entscheidungswege vor Teststart verifizieren." ], "evidence_examples": [ "TLPT-Scope-Dokument und RoE.", "Freigabeprotokoll des Steuerungsgremiums." ], "iso_control_anchors": [ "5.7", "8.20", "8.31" ], "dora_reference": "DORA Kapitel IV (TLPT-Anforderungen)", "marisk_reference": "MaRisk AT 4.3.5", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TST-004", "title": "Testbefunde in Architektur- und Prozessverbesserung überfuehren", "theme": "Digitale Resilienztests", "requirement_type": "Testverfahren", "control_objective": "Testresultate fuehren messbar zu robusteren Kontrollen und Betriebsablaeufen.", "target_state": "Findings sind priorisiert, budgetiert und bis Wirksamkeitsnachweis geschlossen.", "implementation_steps": [ "Findings nach Kritikalität, Aufwand und Risikoabbau priorisieren.", "Maßnahmen in Portfolio- und Budgetsteuerung übernehmen.", "Retests für kritische Findings verbindlich terminieren." ], "evidence_examples": [ "Finding-Register mit Status und Fristen.", "Retest-Berichte mit Closure-Entscheid." ], "iso_control_anchors": [ "10.1", "10.2", "5.35" ], "dora_reference": "DORA Kapitel IV (Folgemaßnahmen)", "marisk_reference": "MaRisk AT 4.4.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TPR-001", "title": "Drittparteieninventar für kritische Services konsolidieren", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Drittparteiensteuerung", "control_objective": "Alle wesentlichen Dienstleister und Abhängigkeiten sind transparent erfasst.", "target_state": "Zentrales Inventar mit Kritikalität, Servicebezug und Verantwortlichen ist aktuell.", "implementation_steps": [ "Dienstleisterdaten aus Einkauf, IT und Fachbereich zusammenfuehren.", "Kritikalitätsmodell für Servicebeitrag und Substituierbarkeit anwenden.", "Pflegeprozess mit Fristen und Kontrollpunkten etablieren." ], "evidence_examples": [ "Drittparteieninventar mit Aktualisierungsdatum.", "Qualitätsreport zur Datenvollständigkeit." ], "iso_control_anchors": [ "5.19", "5.20", "5.23" ], "dora_reference": "DORA Kapitel V (IKT-Drittparteienrisiko)", "marisk_reference": "MaRisk AT 9", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-002", "title": "Risikobasierte Due Diligence vor Beauftragung verbindlich machen", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Drittparteiensteuerung", "control_objective": "Nur Anbieter mit tragfähigem Sicherheits- und Betriebsmodell werden beauftragt.", "target_state": "Due-Diligence-Prüfung deckt Sicherheit, Betrieb, Exit und Konzentrationsrisiko ab.", "implementation_steps": [ "Prüfbausteine je Kritikalitätsstufe definieren.", "Mindestanforderungen für Sicherheitsnachweise festlegen.", "Freigabeentscheidung mit dokumentiertem Restrestrisiko treffen." ], "evidence_examples": [ "Due-Diligence-Checklisten mit Bewertungsresultat.", "Freigabevermerk inkl. Risikoauflagen." ], "iso_control_anchors": [ "5.21", "5.22", "5.36" ], "dora_reference": "DORA Kapitel V (Vorausgehende Bewertung)", "marisk_reference": "MaRisk AT 9 Tz. 2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TPR-003", "title": "Vertragsklauseln für Resilienz und Auditierbarkeit standardisieren", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Drittparteiensteuerung", "control_objective": "Verträge sichern notwendige Informations-, Prüf- und Interventionsrechte ab.", "target_state": "Standardklauseln zu Meldepflicht, Testing, Suboutsourcing und Exit sind verpflichtend.", "implementation_steps": [ "Musterklauseln mit Recht, Einkauf und IT abstimmen.", "Klausel-Compliance im Vertragsprozess technisch prüfbar machen.", "Abweichungen nur mit dokumentierter Genehmigung zulassen." ], "evidence_examples": [ "Vertragsbausteinkatalog mit Pflichtklauseln.", "Abweichungsregister mit Freigabestatus." ], "iso_control_anchors": [ "5.19", "5.20", "5.31" ], "dora_reference": "DORA Kapitel V (Vertragliche Anforderungen)", "marisk_reference": "MaRisk AT 9 Tz. 7", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TPR-004", "title": "Laufendes Dienstleistermonitoring und Exit-Readiness etablieren", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Drittparteiensteuerung", "control_objective": "Leistungsabfall und Risiken bei kritischen Providern werden früh erkannt und beherrscht.", "target_state": "Monitoring-KPI, Review-Zyklen und Exit-Plan sind je kritischem Provider aktiv.", "implementation_steps": [ "KPI-Set für Verfügbarkeit, Sicherheit und Eskalationen festlegen.", "Quartalsreviews mit Provider und internen Stakeholdern durchführen.", "Exit- und Substitutionsszenarien regelmäßig prüfen." ], "evidence_examples": [ "Provider-Scorecards mit Trendanalyse.", "Exit-Playbook mit Testhistorie." ], "iso_control_anchors": [ "5.23", "5.30", "8.14" ], "dora_reference": "DORA Kapitel V (Laufende Überwachung)", "marisk_reference": "MaRisk AT 9 Tz. 8", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-REG-001", "title": "Informationsregister-Datenmodell für Aufsichtsanfragen harmonisieren", "theme": "Informationsregister", "requirement_type": "Registersteuerung", "control_objective": "Aufsichtsrelevante Informationen koennen konsistent und schnell bereitgestellt werden.", "target_state": "Registerdaten folgen einem einheitlichen Datenmodell mit klaren Eigentuemern.", "implementation_steps": [ "Pflichtdatenfelder und Datenherkunft je Registerobjekt definieren.", "Datenverantwortliche in Fachbereichen verbindlich benennen.", "Abgleichregeln zwischen Quellsystemen und Register etablieren." ], "evidence_examples": [ "Datenmodell mit Felddefinitionen.", "Owner-Liste für Registerobjekte." ], "iso_control_anchors": [ "5.9", "5.36", "8.12" ], "dora_reference": "DORA Kapitel V (Informationsregister)", "marisk_reference": "MaRisk AT 9 Tz. 6", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-REG-002", "title": "Register-Aktualisierung an Beschaffungs- und Change-Prozesse koppeln", "theme": "Informationsregister", "requirement_type": "Registersteuerung", "control_objective": "Neuerungen bei Services und Providern werden ohne Zeitverzug im Register sichtbar.", "target_state": "Events aus Einkauf und Change Management triggern automatische Registerprüfungen.", "implementation_steps": [ "Prozessereignisse mit Register-Update-Pflichten verknüpfen.", "Pflichtkontrolle vor Vertragsfreigabe und Produktivsetzung einführen.", "SLA für Registeraktualisierung und Eskalation definieren." ], "evidence_examples": [ "Workflow-Regelwerk für Update-Trigger.", "SLA-Report zur Aktualisierungsfrist." ], "iso_control_anchors": [ "8.32", "8.33", "5.37" ], "dora_reference": "DORA Kapitel V (Datenaktualitaet)", "marisk_reference": "MaRisk AT 9", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-REG-003", "title": "Datenqualität des Registers messbar steuern", "theme": "Informationsregister", "requirement_type": "Registersteuerung", "control_objective": "Registereintraege sind vollständig, korrekt und prüfbar.", "target_state": "Qualitätskennzahlen und Korrekturprozess für Registerdaten sind etabliert.", "implementation_steps": [ "Qualitätskriterien für Vollständigkeit, Konsistenz und Plausibilität festlegen.", "Regelmaessige Datenqualitätsjobs mit Fehlerklassifikation einführen.", "Abweichungen mit Fristen an Datenowner zurückspielen." ], "evidence_examples": [ "Datenqualitätsdashboard für Registerobjekte.", "Fehler- und Korrekturprotokoll." ], "iso_control_anchors": [ "8.15", "8.16", "5.35" ], "dora_reference": "DORA Kapitel V (Registerintegrität)", "marisk_reference": "MaRisk AT 4.4.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-REG-004", "title": "Aufsichtsfähige Register-Exports standardisieren", "theme": "Informationsregister", "requirement_type": "Registersteuerung", "control_objective": "Anfragen der Aufsicht koennen fristgerecht in gefordertem Format beantwortet werden.", "target_state": "Exportlogik, Freigabeprozess und Archivierung sind formal definiert.", "implementation_steps": [ "Standardexporte für wiederkehrende Aufsichtsanfragen bereitstellen.", "Freigabe- und Vier-Augen-Prinzip vor Versand implementieren.", "Versand- und Inhaltsnachweise revisionssicher archivieren." ], "evidence_examples": [ "Exportvorlagen mit Feldmapping.", "Archivierte Auskunftsfaelle mit Freigabevermerk." ], "iso_control_anchors": [ "5.31", "5.33", "5.34" ], "dora_reference": "DORA Kapitel V (Aufsichtskommunikation)", "marisk_reference": "MaRisk AT 4.4.3", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-EVD-001", "title": "Nachweisarchitektur für Kontrollen und Entscheidungen aufbauen", "theme": "Nachweise & Auditfähigkeit", "requirement_type": "Nachweis- und Prüfverfahren", "control_objective": "Kontrollwirkung und Managemententscheidungen sind jederzeit belegbar.", "target_state": "Nachweise folgen einem einheitlichen Klassifikations- und Ablageschema.", "implementation_steps": [ "Nachweiskategorien für Kontrollen, Tests, Vorfälle und Freigaben definieren.", "Ablageorte mit Zugriffsschutz und Aufbewahrungsfristen standardisieren.", "Verlinkung zwischen Nachweis und zugrunde liegendem Prozess sicherstellen." ], "evidence_examples": [ "Nachweiskatalog mit Klassifikationsregeln.", "Ablagestruktur mit Berechtigungsmatrix." ], "iso_control_anchors": [ "5.33", "5.34", "5.35" ], "dora_reference": "DORA querschnittlich (Dokumentation und Nachweise)", "marisk_reference": "MaRisk AT 4.4.2", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-EVD-002", "title": "Prüfpfad für zentrale Resilienzentscheidungen etablieren", "theme": "Nachweise & Auditfähigkeit", "requirement_type": "Nachweis- und Prüfverfahren", "control_objective": "Prüfer koennen den Entscheidungsweg von Risiko bis Massnahme eindeutig nachvollziehen.", "target_state": "Entscheidungsprotokolle enthalten Kontext, Optionen, Beschluss und Umsetzungsergebnis.", "implementation_steps": [ "Standardtemplate für Entscheidungsprotokolle definieren.", "Verknuepfung zu Risiko, Kontrolltest und Budgetmassnahme herstellen.", "Regelmaessige Stichprobenprüfung auf Nachvollziehbarkeit durchführen." ], "evidence_examples": [ "Entscheidungsprotokolle mit Referenzobjekten.", "Stichprobenbericht der Quality Assurance." ], "iso_control_anchors": [ "5.37", "9.2", "9.3" ], "dora_reference": "DORA querschnittlich (Governance-Nachweis)", "marisk_reference": "MaRisk AT 4.4.3", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-EVD-003", "title": "Readiness-Checks für interne und externe Audits betreiben", "theme": "Nachweise & Auditfähigkeit", "requirement_type": "Nachweis- und Prüfverfahren", "control_objective": "Auditanfragen koennen fristgerecht mit validen Belegen beantwortet werden.", "target_state": "Vorbereitete Kontrollpakete und Ansprechpartner sind für Top-Themen gepflegt.", "implementation_steps": [ "Auditrelevante Themenfelder in standardisierte Evidence-Pakete überfuehren.", "Verantwortliche für jedes Paket und Vertretungen benennen.", "Halbjährliche Readiness-Checks mit Gap-Liste durchführen." ], "evidence_examples": [ "Evidence-Pakete pro Themenfeld.", "Readiness-Protokoll mit Maßnahmenfortschritt." ], "iso_control_anchors": [ "9.1", "9.2", "10.1" ], "dora_reference": "DORA querschnittlich (Prüffestigkeit)", "marisk_reference": "MaRisk AT 4.4.2", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-EVD-004", "title": "Review-Zyklus für Richtlinien und Nachweise institutionalieren", "theme": "Nachweise & Auditfähigkeit", "requirement_type": "Nachweis- und Prüfverfahren", "control_objective": "Dokumentation bleibt aktuell und spiegelt den realen Steuerungszustand.", "target_state": "Richtlinien und Nachweise werden nach festen Zyklen geprüft und freigegeben.", "implementation_steps": [ "Reviewkalender für alle kernrelevanten Dokumente aufsetzen.", "Änderungen mit Impact-Bewertung und Freigabeprozess koppeln.", "Überfaellige Reviews automatisiert eskalieren." ], "evidence_examples": [ "Reviewkalender mit Status je Dokument.", "Aenderungsnachweise mit Freigabekette." ], "iso_control_anchors": [ "5.1", "5.35", "5.36" ], "dora_reference": "DORA querschnittlich (Dokumentensteuerung)", "marisk_reference": "MaRisk AT 4.3.1", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-005", "title": "CTPP-Konzentrationsrisiken mit Szenarioanalysen steuern", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Drittparteiensteuerung", "control_objective": "Abhängigkeiten von kritischen IKT-Dienstleistern werden früh erkannt und aktiv reduziert.", "target_state": "Konzentrationskennzahlen und Exit-Szenarien für CTPP-relevante Services sind etabliert und managementwirksam berichtet.", "implementation_steps": [ "Konzentrationsmetriken je Provider, Servicefamilie und Kritikalität definieren.", "Szenarioanalysen für Provider-Ausfall und Leistungseinschraenkung halbjährlich durchführen.", "Maßnahmenplan für Diversifizierung, Architekturhaertung und Exit-Readiness priorisieren." ], "evidence_examples": [ "Konzentrationsreport mit Schwellenwerten und Trendanalyse.", "Szenario- und Maßnahmenprotokolle für CTPP-Ausfaelle." ], "iso_control_anchors": [ "5.19", "5.20", "5.30", "8.13" ], "dora_reference": "DORA Kapitel V (IKT-Drittparteienrisiko, CTPP-Oversight)", "marisk_reference": "MaRisk AT 9, BT 3.3", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TST-005", "title": "Testprogramm mit Recovery- und Kommunikationszielen koppeln", "theme": "Resilienztests", "requirement_type": "Test- und Übungsverfahren", "control_objective": "Resilienztests prüfen nicht nur Technik, sondern auch Wiederherstellung, Eskalation und externe Kommunikation.", "target_state": "Das Testprogramm enthält pro Szenario technische, organisatorische und kommunikative Erfolgskriterien mit Management-Abnahme.", "implementation_steps": [ "Szenario-Templates mit RTO/RPO-, Entscheidungs- und Kommunikationskriterien erweitern.", "Testdurchführung mit Business, IT, Compliance und Kommunikation gemeinsam planen.", "Findings mit Fristen und Wirksamkeitsnachtest in den Verbesserungszyklus überfuehren." ], "evidence_examples": [ "Testkatalog mit kombinierten Erfolgsmetriken.", "Abnahmeprotokolle und Nachtest-Nachweise zu kritischen Findings." ], "iso_control_anchors": [ "5.24", "5.29", "5.30", "8.34" ], "dora_reference": "DORA Kapitel IV (Digitale operationale Resilienztests)", "marisk_reference": "MaRisk AT 7.3, BT 3.2", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-EXT-001", "title": "Exit-Strategie und Ausstiegsplanung nach DORA Art. 28", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Drittparteiensteuerung", "control_objective": "Die Exit-Fähigkeit für kritische Dienstleister ist jederzeit nachweisbar und operativ umsetzbar.", "target_state": "Für jeden kritischen IKT-Dienstleister existiert ein dokumentierter und getesteter Exit-Plan, der Szenarien, Verantwortlichkeiten, Datenportabilität und Zeitpläne umfasst.", "implementation_steps": [ "Inventarisierung aller kritischen Dienstleister und Bewertung der Exit-Relevanz.", "Erstellung von Exit-Plänen je Dienstleister mit Szenarien, Datenportabilität und Migrationspfaden.", "Regelmäßige Tests der Exit-Pläne durch Dry-Runs und Simulationen.", "Dokumentation der Testergebnisse und Nachbesserung identifizierter Lücken.", "Berichterstattung an das Leitungsorgan über Exit-Readiness und offene Risiken." ], "evidence_examples": [ "Exit-Plan-Dokumentation je kritischem Dienstleister", "Dry-Run-Protokolle und Testergebnisse", "Nachweis der Datenportabilität und Integritätstests", "Board-Beschlüsse zu Exit-Entscheidungen" ], "iso_control_anchors": [ "5.19", "5.20", "5.30", "8.14" ], "dora_reference": "DORA Artikel 28 (IKT-Drittparteienrisikomanagement)", "marisk_reference": "MaRisk AT 9, EBA/GL/2019/02", "maturity": "defined", "review_status": "needs_review" }, { "id": "DORA-EXT-002", "title": "Datenportabilität und Vendor-Lock-in-Prävention", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Drittparteiensteuerung", "control_objective": "Vendor-Lock-in-Risiken werden frühzeitig erkannt und durch vertragliche und technische Maßnahmen minimiert.", "target_state": "Datenportabilitätsanforderungen sind vertraglich vereinbart, technisch umsetzbar und regelmäßig getestet.", "implementation_steps": [ "Analyse von Vendor-Lock-in-Risiken je kritischem Dienstleister.", "Vertragliche Sicherstellung von Datenexport, Standardschnittstellen und Übergabefristen.", "Technische Prüfung der Datenportabilität inklusive Formate, Volumen und Integrität.", "Regelmäßige Tests des Datenexports und der Datenübernahme durch Zielsysteme." ], "evidence_examples": [ "Vendor-Lock-in-Risikoanalyse je Dienstleister", "Vertragsklauseln zu Datenportabilität und Exit", "Datenexport-Testprotokolle", "Datenintegritätsnachweise" ], "iso_control_anchors": [ "5.19", "5.20", "5.21", "5.31" ], "dora_reference": "DORA Artikel 28 (Datenportabilität und Exit), DSGVO Art. 20", "marisk_reference": "MaRisk AT 9, EBA/GL/2019/02", "maturity": "defined", "review_status": "needs_review" }, { "id": "DORA-TPR-001", "title": "IKT-Dienstleisterinventar aufbauen und aktuell halten", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Operativer Prozess", "control_objective": "Das Institut kann alle relevanten IKT-Drittdienstleistungen, Dienstleister, Verträge und zugehörigen Verantwortlichkeiten vollständig und aktuell nachvollziehen.", "target_state": "Ein zentrales IKT-Dienstleisterinventar verbindet Dienstleister, Verträge, IKT-Dienstleistungen, interne Verantwortliche, betroffene Funktionen, Kritikalität, Risikobewertung und Registerrelevanz. Das Inventar wird regelmässig überprüft und mit Vertrags-, Auslagerungs- und Informationsregisterdaten abgeglichen.", "implementation_steps": [ "Datenquellen für Dienstleister, Verträge und IKT-Dienstleistungen identifizieren.", "IKT-Dienstleistungen von sonstigen Leistungen abgrenzen.", "Verantwortliche Rollen für Datenpflege und Review festlegen.", "Kritikalität, Funktionsbezug und Registerrelevanz ergänzen.", "Regelmässigen Abgleich mit Vertragsbestand und Informationsregister etablieren." ], "evidence_examples": [ "IKT-Dienstleisterinventar (vollständig)", "Vertragsliste mit IKT-Bezug", "Dienstleistungsklassifikation", "Datenqualitätsbericht", "Review-Protokoll", "Informationsregisterauszug" ], "iso_control_anchors": [ "5.19", "5.20", "5.23", "5.33" ], "dora_reference": "DORA Kapitel V, Art. 28 Abs. 2 (Informationsregister)", "marisk_reference": "MaRisk AT 9, BT 4", "cyber_risk_reference": "Transparenz über externe Angriffsflächen und kritische Dienstleisterabhängigkeiten", "maturity": "implemented", "review_status": "reviewed" }, { "id": "DORA-TPR-002", "title": "Abgrenzung von IKT-Dienstleistungen gegenüber sonstigen Leistungen", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Operativer Prozess", "control_objective": "Das Institut kann IKT-Dienstleistungen eindeutig von sonstigen Fremdleistungen abgrenzen und damit den Anwendungsbereich der DORA-Drittparteienregelungen bestimmen.", "target_state": "Eine verbindliche Abgrenzungsrichtlinie definiert Kriterien für IKT-Dienstleistungen, die unter DORA fallen. Die Abgrenzung wird bei Vertragsaufnahme und regelmässigen Reviews angewendet.", "implementation_steps": [ "Abgrenzungskriterien basierend auf DORA-Definitionen (Art. 3) entwickeln.", "Richtlinie zur Abgrenzung von IKT-Dienstleistungen verabschieden.", "Bestandsverträge auf IKT-Dienstleistungscharakter prüfen.", "Neubewertung bei wesentlichen Vertragsänderungen institutionalisieren." ], "evidence_examples": [ "Abgrenzungsrichtlinie für IKT-Dienstleistungen", "Bewertungsmatrix je Vertrag", "Protokoll der Bestandsprüfung" ], "iso_control_anchors": [ "5.19", "5.33" ], "dora_reference": "DORA Art. 3 Ziffer 18–21 (Definition IKT-Dienstleistung)", "marisk_reference": "MaRisk AT 9 (Fremdbezug)", "cyber_risk_reference": "Klassifikation der Angriffsfläche durch Drittanbieter", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-003", "title": "Kritische oder wichtige Funktionen zuordnen", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Governance-Verfahren", "control_objective": "IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, werden identifiziert und besonders gesteuert.", "target_state": "Jede IKT-Drittdienstleistung ist einer Funktion zugeordnet und hinsichtlich ihrer Kritikalität bewertet. Kritische Funktionen unterliegen verstärkten Anforderungen an Verträge, Überwachung, Exit und Register.", "implementation_steps": [ "Kriterien für kritische oder wichtige Funktionen institutsspezifisch definieren.", "IKT-Dienstleistungen den Funktionen zuordnen.", "Kritikalitätsbewertung dokumentieren und regelmässig aktualisieren.", "Verstärkte Anforderungen für kritische Funktionen umsetzen." ], "evidence_examples": [ "Funktionslandkarte mit IKT-Dienstleistungszuordnung", "Kritikalitätsbewertung je Dienstleistung", "Übersicht der kritischen IKT-Drittdienstleistungen" ], "iso_control_anchors": [ "5.19", "5.20", "5.23", "5.30" ], "dora_reference": "DORA Art. 28 Abs. 3 (Kritische oder wichtige Funktionen)", "marisk_reference": "MaRisk AT 9 Tz. 3 (Wesentlichkeit)", "cyber_risk_reference": "Fokussierte Sicherheitsmaßnahmen für kritische Dienstleister", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-004", "title": "Dienstleisterrisikobewertung vor Beauftragung und laufend", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Risikosteuerung", "control_objective": "Risiken durch IKT-Drittdienstleister werden vor Vertragsabschluss und während der gesamten Vertragslaufzeit bewertet.", "target_state": "Eine standardisierte Risikobewertung prüft Sicherheit, Betriebsstabilität, Finanzlage, Abhängigkeiten und Exit-Fähigkeit vor Beauftragung und jährlich.", "implementation_steps": [ "Risikobewertungsmatrix für IKT-Drittdienstleister entwickeln.", "Bewertung vor Vertragsabschluss (Due Diligence) durchführen.", "Laufende Risikobewertung mindestens jährlich wiederholen.", "Ergebnisse mit Maßnahmen und Fristen dokumentieren." ], "evidence_examples": [ "Risikobewertungsmatrix je Dienstleister", "Due-Diligence-Bericht", "Jährliche Risikobewertung mit Aktualisierung", "Maßnahmenübersicht aus Risikobewertungen" ], "iso_control_anchors": [ "5.21", "5.22", "5.36" ], "dora_reference": "DORA Art. 28 Abs. 1, Art. 29 Abs. 1 (Risikobewertung)", "marisk_reference": "MaRisk AT 9 Tz. 2, BT 4 Tz. 2", "cyber_risk_reference": "Bewertung der Cyber-Sicherheitslage des Dienstleisters", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TPR-005", "title": "Vertragsmindestinhalte nach DORA sicherstellen", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Vertragsanforderung", "control_objective": "Verträge mit IKT-Drittdienstleistern enthalten alle nach DORA erforderlichen Mindestklauseln.", "target_state": "Eine standardisierte Klauselprüfung stellt sicher, dass Verträge vollständige Leistungsbeschreibungen, Sicherheitsanforderungen, Meldepflichten, Kontrollrechte, SLA-Regelungen, Kündigungsfristen und Exit-Bestimmungen enthalten.", "implementation_steps": [ "DORA-Mindestklauselkatalog aus Art. 28 Abs. 2 ableiten.", "Vertragsprüfprozess mit Checkliste und Freigabestufen etablieren.", "Bestandsverträge auf Klausellücken prüfen und nachbessern.", "Abweichungen dokumentieren und managementseitig freigeben." ], "evidence_examples": [ "Klauselkatalog mit DORA-Mindestanforderungen", "Vertragsprüf-Checkliste", "Abweichungsregister mit Freigabevermerk", "Nachgebesserte Verträge" ], "iso_control_anchors": [ "5.19", "5.20", "5.31" ], "dora_reference": "DORA Art. 28 Abs. 2 (Vertragsanforderungen)", "marisk_reference": "MaRisk AT 9 Tz. 7, BT 4 Tz. 3", "cyber_risk_reference": "Vertragliche Absicherung von Sicherheitsanforderungen und Meldepflichten", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TPR-006", "title": "Kontroll- und Zugangsrechte vertraglich sichern", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Vertragsanforderung", "control_objective": "Das Institut hat vertraglich gesicherte Prüfungs-, Zugangs- und Interventionsrechte bei IKT-Drittdienstleistern.", "target_state": "Verträge mit kritischen IKT-Drittdienstleistern enthalten umfassende Audit-, Kontroll- und Zugangsrechte sowie das Recht auf Vor-Ort-Prüfungen und die Einsichtnahme in Unterauftragnehmerverhältnisse.", "implementation_steps": [ "Audit-, Kontroll- und Zugangsrechte als Pflichtklauseln definieren.", "Ausübungskonzept für Kontrollrechte (Häufigkeit, Umfang, Eskalation) erstellen.", "Kontrollrechte regelmässig ausüben und Ergebnisse dokumentieren.", "Verweigerung von Kontrollrechten als Risikoindikator eskalieren." ], "evidence_examples": [ "Vertragsklauseln zu Audit- und Kontrollrechten", "Jährlicher Kontrollplan", "Durchgeführte Audits und Prüfberichte", "Eskalationsvermerk bei verweigerten Rechten" ], "iso_control_anchors": [ "5.19", "5.20", "5.36", "9.2" ], "dora_reference": "DORA Art. 28 Abs. 2 lit. f–h (Kontroll- und Zugangsrechte)", "marisk_reference": "MaRisk AT 9 Tz. 7, BT 4 Tz. 4", "cyber_risk_reference": "Sicherstellung der Prüfbarkeit von Sicherheitsmaßnahmen beim Dienstleister", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-007", "title": "Unterauftragnehmer und Leistungsketten transparent machen", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Operativer Prozess", "control_objective": "Das Institut hat Transparenz über Unterauftragnehmer und Leistungsketten kritischer IKT-Drittdienstleister.", "target_state": "Vertragliche Regelungen verpflichten Dienstleister zur Offenlegung wesentlicher Unterauftragnehmer. Ein aktuelles Leistungskettenverzeichnis zeigt Abhängigkeiten und Konzentrationsrisiken auf.", "implementation_steps": [ "Vertragliche Verpflichtung zur Offenlegung von Unterauftragnehmern aufnehmen.", "Leistungsketten für kritische IKT-Dienstleistungen erfassen.", "Unterauftragnehmer auf Konzentrationsrisiken prüfen.", "Änderungen im Unterauftragnehmerverhältnis meldepflichtig machen." ], "evidence_examples": [ "Leistungskettenübersicht je kritischer Dienstleistung", "Vertragsklauseln zu Unterauftragnehmern", "Konzentrationsrisikoanalyse", "Änderungsmeldungen und Freigaben" ], "iso_control_anchors": [ "5.19", "5.20", "5.21" ], "dora_reference": "DORA Art. 28 Abs. 2 lit. e, Art. 29 Abs. 4 (Leistungsketten)", "marisk_reference": "MaRisk AT 9 Tz. 5, BT 4 Tz. 2", "cyber_risk_reference": "Erweiterte Angriffsfläche durch mehrstufige Dienstleisterketten", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-008", "title": "Exit-Strategien für kritische IKT-Drittdienstleistungen", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Plan", "control_objective": "Das Institut kann kritische IKT-Drittdienstleistungen geordnet beenden, übertragen oder ersetzen, ohne die digitale operationale Resilienz unangemessen zu gefährden.", "target_state": "Für kritische oder wichtige IKT-Drittdienstleistungen bestehen dokumentierte, realistische und überprüfte Exit-Strategien. Sie berücksichtigen Datenrückgabe, Übergangsfristen, Ersatzdienstleister, interne Verantwortlichkeiten, technische Abhängigkeiten, regulatorische Anzeige- oder Informationspflichten und Managementfreigaben.", "implementation_steps": [ "Kritische oder wichtige IKT-Drittdienstleistungen identifizieren.", "Exit-Szenarien und Auslöser definieren.", "Technische, vertragliche und operative Abhängigkeiten dokumentieren.", "Ersatz- oder Übergangsoptionen bewerten.", "Exit-Strategien regelmässig prüfen und, wenn angemessen, testen.", "Ergebnisse und offene Risiken managementfähig berichten." ], "evidence_examples": [ "Exit-Strategie je kritischer Dienstleistung", "Exit-Testprotokoll", "Abhängigkeitsanalyse", "Gremienfreigabe", "Maßnahmenverfolgung" ], "iso_control_anchors": [ "5.19", "5.29", "5.30", "5.36" ], "dora_reference": "DORA Art. 28 Abs. 2 lit. i, Art. 29 Abs. 5 (Exit)", "marisk_reference": "MaRisk AT 9 Tz. 9, BT 4 Tz. 6", "cyber_risk_reference": "Reduktion kritischer Abhängigkeiten und Wiederherstellungsfähigkeit bei Dienstleisterausfall", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-009", "title": "Exit-Test und Exit-Fähigkeit regelmässig überprüfen", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Kontrollaktivität", "control_objective": "Die praktische Umsetzbarkeit von Exit-Strategien wird regelmässig getestet und nachgewiesen.", "target_state": "Exit-Tests für kritische IKT-Drittdienstleistungen werden mindestens jährlich durchgeführt. Sie prüfen Datenrückgabe, Systemmigration, Kommunikationswege und die Einhaltung von Übergangsfristen.", "implementation_steps": [ "Test-Szenarien für Exit-Fälle definieren (Datenrückgabe, Migration, Löschung).", "Jährlichen Testplan für Exit-Übungen erstellen.", "Testergebnisse dokumentieren und Verbesserungen ableiten.", "Nicht bestandene Tests mit Maßnahmen und Fristen versehen." ], "evidence_examples": [ "Exit-Testplan für das laufende Jahr", "Durchgeführte Exit-Tests mit Ergebnissen", "Verbesserungsmaßnahmen aus Tests", "Management-Freigabe der Testergebnisse" ], "iso_control_anchors": [ "5.29", "5.30", "8.34" ], "dora_reference": "DORA Art. 29 Abs. 5 (Test der Exit-Fähigkeit)", "marisk_reference": "MaRisk AT 7.3, BT 3.3", "cyber_risk_reference": "Wiederherstellungsfähigkeit nach Dienstleister-Sicherheitsvorfall testen", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-TPR-010", "title": "Konzentrationsrisiken durch IKT-Drittdienstleister analysieren", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Risikosteuerung", "control_objective": "Risiken aus der Konzentration auf einzelne Dienstleister, Regionen oder Technologien werden identifiziert und gesteuert.", "target_state": "Eine regelmässige Konzentrationsrisikoanalyse prüft Abhängigkeiten auf Dienstleister-, Branchen-, Regional- und Technologieebene und leitet Maßnahmen zur Risikominderung ab.", "implementation_steps": [ "Konzentrationsdimensionen definieren (Dienstleister, Region, Technologie, Branche).", "Konzentrationsrisikoanalyse mindestens jährlich durchführen.", "Kritische Konzentrationen mit Maßnahmenplänen versehen.", "Ergebnisse in das gesamtinstitutische Risikomanagement einsteuern." ], "evidence_examples": [ "Konzentrationsrisikoanalyse (aktuell)", "Maßnahmenplan für identifizierte Konzentrationsrisiken", "Reporting an das Leitungsorgan", "Monitoring kritischer Konzentrationen" ], "iso_control_anchors": [ "5.19", "5.21", "5.22" ], "dora_reference": "DORA Art. 29 Abs. 3 (Konzentrationsrisiko)", "marisk_reference": "MaRisk AT 9 Tz. 4, BT 4 Tz. 2", "cyber_risk_reference": "Risikoerhöhung durch gemeinsame Angriffsfläche bei konzentrierten Dienstleistern", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-011", "title": "Laufende Überwachung von IKT-Drittdienstleistern", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Kontrollaktivität", "control_objective": "Die Leistungs- und Risikoentwicklung kritischer IKT-Drittdienstleister wird kontinuierlich überwacht.", "target_state": "Ein Überwachungsprozess mit definierten Kennzahlen, Berichtsintervallen und Eskalationsschwellen ist für alle kritischen IKT-Drittdienstleister etabliert.", "implementation_steps": [ "Überwachungskennzahlen je Dienstleister (Verfügbarkeit, Sicherheitsvorfälle, SLA-Einhaltung) definieren.", "Regelmässige Leistungs- und Risikoberichte von Dienstleistern einfordern.", "Abweichungen systematisch erfassen, eskalieren und nachverfolgen.", "Steuerungsgespräche mit kritischen Dienstleistern institutionalisieren." ], "evidence_examples": [ "Überwachungskonzept mit Kennzahlen", "Dienstleister-Scorecards mit Trend", "Abweichungsprotokoll mit Eskalation", "Steuerungsgesprächsprotokolle" ], "iso_control_anchors": [ "5.19", "5.23", "5.35", "8.16" ], "dora_reference": "DORA Art. 29 Abs. 1–2 (Laufende Überwachung)", "marisk_reference": "MaRisk AT 9 Tz. 8, BT 4 Tz. 5", "cyber_risk_reference": "Kontinuierliche Überwachung der Cyber-Sicherheitslage des Dienstleisters", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TPR-012", "title": "Informationsregisterfähigkeit für IKT-Drittdienstleistungen sicherstellen", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Nachweis / Evidenz", "control_objective": "Das Institut kann jederzeit ein vollständiges, richtiges und aktuelles Informationsregister über alle IKT-Drittdienstleistungen vorlegen.", "target_state": "Das Informationsregister enthält alle geforderten Angaben zu IKT-Drittdienstleistungen, Dienstleistern, Verträgen, Funktionen, Kritikalität und Unterauftragnehmern. Die Datenqualität wird regelmässig geprüft.", "implementation_steps": [ "Registerdatenmodell mit allen DORA-Pflichtfeldern definieren.", "Datenquellen mit automatisierten Schnittstellen anbinden.", "Datenqualitätsregeln und Korrekturprozesse etablieren.", "Register periodisch auf Vollständigkeit und Aktualität prüfen." ], "evidence_examples": [ "Informationsregisterauszug (vollständig)", "Datenqualitätsbericht", "Schnittstellendokumentation", "Review-Protokoll der Registerdaten" ], "iso_control_anchors": [ "5.19", "5.33", "5.34", "5.36" ], "dora_reference": "DORA Art. 28 Abs. 3 (Informationsregister)", "marisk_reference": "MaRisk AT 9 Tz. 6", "cyber_risk_reference": "Register als Grundlage für Cyber-Risikoanalyse externer Schnittstellen", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-013", "title": "Incident-Kommunikation mit IKT-Drittdienstleistern", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Vertragsanforderung", "control_objective": "IKT-bezogene Vorfälle bei Dienstleistern werden dem Institut zeitnah gemeldet und institutsintern korrekt behandelt.", "target_state": "Vertragliche Meldefristen, Eskalationswege und Kommunikationsschnittstellen sind mit allen kritischen Dienstleistern vereinbart. Eingehende Meldungen werden im institutseigenen Incident-Prozess aufgenommen und weiterverarbeitet.", "implementation_steps": [ "Meldepflichten und -fristen für Sicherheitsvorfälle vertraglich regeln.", "Kommunikationsschnittstellen und Ansprechpartner benennen.", "Eingehende Dienstleister-Meldungen in den Incident-Prozess integrieren.", "Regelmässige Kommunikationsübungen mit kritischen Dienstleistern durchführen." ], "evidence_examples": [ "Vertragsklauseln zu Meldefristen", "Kommunikationsmatrix je Dienstleister", "Eingegangene Meldungen und Bearbeitungsnachweise", "Übungsprotokolle zur Incident-Kommunikation" ], "iso_control_anchors": [ "5.19", "5.24", "5.25", "5.26" ], "dora_reference": "DORA Art. 28 Abs. 2 lit. c, Art. 29 Abs. 2 (Meldepflichten)", "marisk_reference": "MaRisk AT 9 Tz. 8, BT 3.2", "cyber_risk_reference": "Sicherstellung rechtzeitiger Information über Cyber-Vorfälle beim Dienstleister", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-TPR-014", "title": "Management Reporting zu IKT-Drittparteienrisiken", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Bericht / Reporting", "control_objective": "Das Leitungsorgan erhält regelmässig entscheidungsrelevante Informationen über IKT-Drittparteienrisiken.", "target_state": "Ein standardisiertes Reporting informiert das Leitungsorgan vierteljährlich über Dienstleisterbestand, Risikobewertungen, wesentliche Vorfälle, Konzentrationsrisiken, Kontrollstatus und Exit-Readiness.", "implementation_steps": [ "Reporting-Kennzahlen für IKT-Drittparteienrisiko definieren.", "Standardisiertes Reporting-Template entwickeln.", "Reporting-Rhythmus (quartalsweise) und Eskalationsschwellen festlegen.", "Reporting mit dem gesamtinstitutischen Risikobericht abstimmen." ], "evidence_examples": [ "Quarterly TPR-Report an das Leitungsorgan", "Kennzahlen-Dashboard (Dienstleister, Risiken, Maßnahmen)", "Eskalationsnachweise bei Schwellwertverletzungen", "Sitzungsprotokolle mit TPR-Tagesordnungspunkt" ], "iso_control_anchors": [ "5.35", "5.36", "5.37" ], "dora_reference": "DORA Art. 29 Abs. 1, Art. 5 (Berichtspflichten)", "marisk_reference": "MaRisk AT 4.3.1, BT 3.1", "cyber_risk_reference": "Entscheidungsrelevante Informationen zur Cyber-Risikolage durch Dienstleister", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-TPR-015", "title": "Maßnahmen- und Befundverfolgung im TPR-Umfeld", "theme": "IKT-Drittparteienrisiko", "requirement_type": "Nachweis / Evidenz", "control_objective": "Alle identifizierten Mängel, Risiken und Verbesserungsmaßnahmen im IKT-Drittparteienbereich werden systematisch verfolgt und bis zum Wirksamkeitsnachweis geschlossen.", "target_state": "Ein Maßnahmen-Tracking-System erfasst alle Befunde aus Audits, Risikobewertungen, Vertragsprüfungen und Kontrollen. Jede Massnahme hat einen Verantwortlichen, eine Frist und einen Wirksamkeitsnachweis.", "implementation_steps": [ "Maßnahmenkategorien für TPR-spezifische Befunde definieren.", "Tracking-System mit Fristen, Verantwortlichen und Status aufsetzen.", "Regelmässige Review-Termine zur Maßnahmenverfolgung institutionalisieren.", "Überfällige Maßnahmen eskalieren und managementseitig nachsteuern." ], "evidence_examples": [ "Maßnahmen- und Befundtracking (aktuell)", "Review-Protokolle mit Status je Massnahme", "Eskalationsnachweise bei überfälligen Maßnahmen", "Wirksamkeitsnachweise abgeschlossener Maßnahmen" ], "iso_control_anchors": [ "5.35", "5.36", "10.1", "10.2" ], "dora_reference": "DORA Art. 29, Art. 4 (Kontinuierliche Verbesserung)", "marisk_reference": "MaRisk AT 4.4.2, BT 4", "cyber_risk_reference": "Nachverfolgung von Sicherheitsbefunden bei Dienstleistern", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-001", "title": "Governance-Rahmen für IKT-Risikomanagement etablieren", "theme": "IKT-Risikomanagement", "requirement_type": "Governance-Verfahren", "control_objective": "Das Institut verfügt über einen dokumentierten Governance-Rahmen, der IKT-Risikomanagement als integralen Bestandteil des gesamtinstitutischen Risikomanagements verankert.", "target_state": "Ein vom Leitungsorgan freigegebener Governance-Rahmen definiert Ziele, Prinzipien, Verantwortlichkeiten, Entscheidungswege, Eskalationsschwellen und Berichtslinien für das IKT-Risikomanagement. Der Rahmen wird mindestens jährlich überprüft und bei wesentlichen Änderungen aktualisiert.", "implementation_steps": [ "IST-Governance für IKT-Risikomanagement aufnehmen und gegen DORA-Anforderungen mappen.", "Governance-Rahmen mit Leitungsorgan-Verantwortung, Ausschüssen, Rollen und Entscheidungswegen entwerfen.", "Eskalationsschwellen für IKT-Risiken in Zusammenarbeit mit Risikocontrolling festlegen.", "Rahmen durch Leitungsorgan freigeben und in der Organisation kommunizieren.", "Jährlichen Review-Prozess für den Governance-Rahmen institutionalisieren." ], "evidence_examples": [ "Freigegebener Governance-Rahmen (aktuell)", "Gremienbeschluss zur Verabschiedung", "Eskalationsmatrix für IKT-Risiken", "Review-Protokoll mit Änderungshistorie" ], "iso_control_anchors": [ "5.1", "5.2", "5.3", "5.36" ], "dora_reference": "DORA Art. 5 Abs. 1 (Governance), Art. 6 Abs. 1 (Rahmen für IKT-Risikomanagement)", "marisk_reference": "MaRisk AT 4.3.1, AT 4.4.1", "cyber_risk_reference": "Governance-Verankerung für Cyber-Risikosteuerung auf Management-Ebene", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-002", "title": "Rollen und Verantwortlichkeiten im IKT-Risikomanagement definieren", "theme": "IKT-Risikomanagement", "requirement_type": "Governance-Verfahren", "control_objective": "Rollen, Aufgaben, Kompetenzen und Verantwortlichkeiten für das IKT-Risikomanagement sind institutsweit eindeutig zugeordnet und dokumentiert.", "target_state": "Ein verbindliches Rollenmodell weist Verantwortlichkeiten für IKT-Risikoidentifikation, -bewertung, -behandlung, -überwachung und -berichterstattung zu. Dritte-Verteidigungslinie (Revision) prüft die Wirksamkeit des Gesamtsystems.", "implementation_steps": [ "RACI-Matrix für IKT-Risikomanagement mit Fachbereichen, IT, Risikocontrolling, Informationssicherheit und Revision erstellen.", "Stellvertretungsregelungen für jede Schlüsselrolle festlegen.", "Rollen in Stellenbeschreibungen und Zielvereinbarungen integrieren.", "Rollenverständnis durch Schulungen und Kommunikation sicherstellen." ], "evidence_examples": [ "Rollen- und Verantwortungsmatrix (RACI)", "Stellenbeschreibungen mit IKT-Risikobezug", "Schulungsnachweise für Rolleninhaber", "Review-Protokoll der Rollenverteilung" ], "iso_control_anchors": [ "5.2", "5.3", "5.37" ], "dora_reference": "DORA Art. 5 Abs. 2 (Rollen), Art. 6 Abs. 3 (Personal)", "marisk_reference": "MaRisk AT 4.4.1 (Aufbauorganisation), AT 7.1 (Personal)", "cyber_risk_reference": "Klare Verantwortungszuordnung für Cyber-Sicherheitsmaßnahmen", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-IRM-003", "title": "IKT-Risikostrategie und Risikoappetit festlegen", "theme": "IKT-Risikomanagement", "requirement_type": "Strategie / Plan", "control_objective": "Das Institut verfügt über eine dokumentierte IKT-Risikostrategie, die den Risikoappetit, die Risikotragfähigkeit und strategische Ziele für IKT-Risiken definiert.", "target_state": "Die IKT-Risikostrategie ist mit der Geschäftsstrategie und dem gesamtinstitutischen Risikoappetit abgestimmt. Sie definiert quantitative und qualitative Risikoschwellen, Prioritäten und Maßnahmen bei Schwellwertverletzungen.", "implementation_steps": [ "IKT-Risikoappetit aus gesamtnstitutischem Risikoappetit ableiten und operationalisieren.", "IKT-Risikostrategie mit Zielen, Schwellenwerten und Überwachungskennzahlen formulieren.", "Strategie durch Leitungsorgan freigeben und jährlich überprüfen.", "Abweichungen von der Strategie als Eskalationsereignis definieren." ], "evidence_examples": [ "Freigegebene IKT-Risikostrategie (aktuell)", "Risikoappetit-Erklärung mit Schwellenwerten", "Jährlicher Strategie-Review mit Beschluss", "Abweichungsbericht bei Strategieverletzung" ], "iso_control_anchors": [ "5.1", "5.4", "5.36" ], "dora_reference": "DORA Art. 6 Abs. 1 lit. a–b (Strategie), Art. 6 Abs. 4 (Dokumentation)", "marisk_reference": "MaRisk AT 4.2.1 (Risikostrategie), AT 4.3.2 (Risikotragfähigkeit)", "cyber_risk_reference": "Strategische Steuerung von Cyber-Risiken und Investitionsprioritäten", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-004", "title": "IKT-Risikoinventar aufbauen und aktuell halten", "theme": "IKT-Risikomanagement", "requirement_type": "Operativer Prozess", "control_objective": "Alle identifizierten IKT-Risiken werden in einem zentralen Risikoinventar erfasst, bewertet und aktuell gehalten.", "target_state": "Ein vollständiges IKT-Risikoinventar erfasst jede identifizierte Gefährdung mit Risikobeschreibung, Eintrittswahrscheinlichkeit, Schadenshöhe, Risikowert, Verantwortlichem, Behandlungsoption, Frist und Status. Das Inventar wird mindestens quartalsweise aktualisiert.", "implementation_steps": [ "Risikokategorien für IKT-Risiken definieren (strategisch, operativ, Compliance, Reputation).", "Risikoinventar-Vorlage mit Pflichtfeldern entwickeln.", "Ersterfassung durch Fachbereiche, IT und Informationssicherheit durchführen.", "Regelmässige Aktualisierung (quartalsweise) und Konsolidierung institutionalisieren.", "Inventar mit Kontrollsystem und Maßnahmentracking verknüpfen." ], "evidence_examples": [ "IKT-Risikoinventar (vollständig, aktuell)", "Risikoklassifikation und -kategorien", "Aktualisierungsprotokolle je Quartal", "Abgleich mit Kontroll- und Maßnahmensystem" ], "iso_control_anchors": [ "5.7", "5.8", "5.9", "8.8" ], "dora_reference": "DORA Art. 6 Abs. 1 lit. c (Risikoidentifikation), Art. 7 (Risikobewertung)", "marisk_reference": "MaRisk AT 4.3.3 (Risikoinventar), BT 1 (IKT-Risiken)", "cyber_risk_reference": "Systematische Erfassung und Bewertung von Cyber-Risiken", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-005", "title": "Schutzbedarfsfeststellung für IKT-Assets durchführen", "theme": "IKT-Risikomanagement", "requirement_type": "Risikosteuerung", "control_objective": "Der Schutzbedarf aller IKT-Assets wird hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit systematisch festgestellt und dokumentiert.", "target_state": "Eine vollständige Schutzbedarfsfeststellung liegt für alle IKT-Assets (Anwendungen, Systeme, Daten, Netzwerke, Infrastruktur) vor. Die Einstufung erfolgt einheitlich anhand definierter Kriterien und wird bei wesentlichen Änderungen aktualisiert.", "implementation_steps": [ "Schutzbedarfskategorien (normal, hoch, sehr hoch) für Vertraulichkeit, Integrität und Verfügbarkeit definieren.", "Bewertungsmatrix mit Kriterien je Kategorie entwickeln.", "IKT-Assets identifizieren und Schutzbedarf je Asset bestimmen.", "Ergebnisse dokumentieren und regelmässig (mindestens jährlich) aktualisieren." ], "evidence_examples": [ "Schutzbedarfsfeststellung für alle IKT-Assets", "Bewertungsmatrix und Kriterienkatalog", "Aktualisierungsprotokoll", "Abweichungsanalyse bei geändertem Schutzbedarf" ], "iso_control_anchors": [ "5.9", "5.10", "8.1", "8.2" ], "dora_reference": "DORA Art. 7 Abs. 2 (Schutzbedarf), Art. 8 (Schutzmaßnahmen)", "marisk_reference": "MaRisk BT 1.1 (Informationssicherheit), BT 3.1 (Notfallmanagement)", "cyber_risk_reference": "Schutzbedarf als Grundlage für priorisierte Cyber-Sicherheitsmaßnahmen", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-006", "title": "IKT-Risikoanalyse und -bewertung durchführen", "theme": "IKT-Risikomanagement", "requirement_type": "Risikosteuerung", "control_objective": "IKT-Risiken werden systematisch analysiert, bewertet und priorisiert, um risikobasierte Entscheidungen zu ermöglichen.", "target_state": "Eine standardisierte Risikoanalyse bewertet identifizierte IKT-Risiken nach Eintrittswahrscheinlichkeit und Schadenshöhe. Die Ergebnisse werden in einer Risikomatrix visualisiert und priorisiert. Wesentliche Risiken werden mit Behandlungsoptionen und Fristen versehen.", "implementation_steps": [ "Risikoanalyse-Methodik (quantitativ/qualitativ) institutsspezifisch festlegen.", "Risikomatrix mit Eintrittswahrscheinlichkeit, Schadenshöhe und Risikoklassen definieren.", "Risikoanalyse für alle erfassten IKT-Risiken durchführen.", "Ergebnisse priorisieren und in Risikobericht aufnehmen." ], "evidence_examples": [ "Risikoanalysebericht (aktuell)", "Risikomatrix mit Bewertung aller IKT-Risiken", "Priorisierungsliste mit Behandlungskategorien", "Risikobericht an Leitungsorgan" ], "iso_control_anchors": [ "5.7", "5.8", "8.8" ], "dora_reference": "DORA Art. 7 (Risikoanalyse und -bewertung)", "marisk_reference": "MaRisk AT 4.3.3 (Risikoanalyse), BT 1.2", "cyber_risk_reference": "Systematische Bewertung von Cyber-Risiken als Grundlage für Maßnahmen", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-IRM-007", "title": "IKT-Risikobehandlung steuern und dokumentieren", "theme": "IKT-Risikomanagement", "requirement_type": "Risikosteuerung", "control_objective": "Für jedes identifizierte und bewertete IKT-Risiko wird eine Behandlungsoption festgelegt und umgesetzt.", "target_state": "Ein Risikobehandlungsplan dokumentiert für jedes wesentliche IKT-Risiko die gewählte Option (Vermeiden, Reduzieren, Übertragen, Akzeptieren), zugehörige Maßnahmen, Verantwortliche, Fristen und den Status der Umsetzung. Risikoakzeptanz erfolgt auf der dafür vorgesehenen Management-Ebene.", "implementation_steps": [ "Behandlungsoptionen institutsweit verbindlich definieren.", "Risikobehandlungsplan mit Maßnahmen, Verantwortlichen und Fristen erstellen.", "Akzeptanzkriterien und Genehmigungsstufen für Risikoakzeptanz festlegen.", "Umsetzung der Maßnahmen verfolgen und Wirksamkeit nachweisen.", "Restrisiken dokumentieren und managementseitig freigeben." ], "evidence_examples": [ "Risikobehandlungsplan (aktuell)", "Maßnahmenübersicht mit Status und Fristen", "Risikoakzeptanzdokumentation mit Genehmigung", "Wirksamkeitsnachweise umgesetzter Maßnahmen" ], "iso_control_anchors": [ "5.7", "5.8", "5.29", "8.3" ], "dora_reference": "DORA Art. 8 (Schutzmaßnahmen), Art. 9 (Risikobehandlung)", "marisk_reference": "MaRisk AT 4.3.4 (Risikobehandlung), BT 2", "cyber_risk_reference": "Systematische Behandlung identifizierter Cyber-Risiken mit Maßnahmenplan", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-IRM-008", "title": "Kontrollsystem für IKT-Risikomanagement aufbauen", "theme": "IKT-Risikomanagement", "requirement_type": "Kontrollaktivität", "control_objective": "Ein dokumentiertes Kontrollsystem stellt die Wirksamkeit der IKT-Risikomanagement-Maßnahmen sicher.", "target_state": "Das Kontrollsystem umfasst risikobasierte Kontrollziele, Kontrollen (präventiv, detektiv, korrektiv), Kontrollfrequenzen, Verantwortliche, Nachweise und Review-Zyklen. Kontrollergebnisse werden dokumentiert und bei Abweichungen eskalieren.", "implementation_steps": [ "Kontrollziele aus IKT-Risikoinventar und Schutzbedarf ableiten.", "Kontrolltypen (präventiv/detektiv/korrektiv) und -frequenzen festlegen.", "Kontrollen in Verantwortung der Fachbereiche, IT und Informationssicherheit betreiben.", "Kontrollergebnisse dokumentieren und bei Abweichungen Maßnahmen einleiten." ], "evidence_examples": [ "Kontrollsystem-Dokumentation mit Kontrollmatrix", "Durchgeführte Kontrollen mit Ergebnissen", "Abweichungsberichte und Maßnahmen", "Kontroll-Review-Protokoll" ], "iso_control_anchors": [ "5.7", "5.8", "8.8", "8.15" ], "dora_reference": "DORA Art. 8 (Kontrollsystem), Art. 10 (Wirksamkeit)", "marisk_reference": "MaRisk AT 4.4.2 (Kontrollsystem), BT 2.1", "cyber_risk_reference": "Kontrollsystem für Cyber-Sicherheitsmaßnahmen mit Nachweislogik", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-009", "title": "Wirksamkeitsprüfung von IKT-Kontrollen institutionalisieren", "theme": "IKT-Risikomanagement", "requirement_type": "Kontrollaktivität", "control_objective": "Die Wirksamkeit der IKT-Kontrollen wird regelmässig geprüft, dokumentiert und bei Feststellungen nachgesteuert.", "target_state": "Ein standardisierter Prozess prüft die Wirksamkeit aller IKT-Kontrollen mindestens jährlich. Die Prüfung umfasst Design-Wirksamkeit und operative Wirksamkeit. Ergebnisse werden dokumentiert, mit Soll-Zustand abgeglichen und Maßnahmen bei Abweichungen eingeleitet.", "implementation_steps": [ "Prüfmethodik für Design-Wirksamkeit und operative Wirksamkeit festlegen.", "Prüfplan mit Priorisierung (risikobasiert) und Frequenzen erstellen.", "Wirksamkeitsprüfungen durchführen und Ergebnisse dokumentieren.", "Maßnahmen bei nicht wirksamen Kontrollen ableiten und nachverfolgen." ], "evidence_examples": [ "Prüfplan für Wirksamkeitsnachweise (jährlich)", "Durchgeführte Wirksamkeitsprüfungen mit Ergebnissen", "Maßnahmenplan bei nicht wirksamen Kontrollen", "Management-Freigabe der Prüfergebnisse" ], "iso_control_anchors": [ "5.35", "5.36", "8.8", "9.1" ], "dora_reference": "DORA Art. 10 (Wirksamkeit und Überwachung)", "marisk_reference": "MaRisk AT 4.4.2 Tz. 3 (Wirksamkeit), BT 2.2", "cyber_risk_reference": "Nachweis der Wirksamkeit von Cyber-Sicherheitsmaßnahmen", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-010", "title": "Kritische IKT-Dienstleistungen identifizieren und Schutzbedarf bestimmen", "theme": "IKT-Risikomanagement", "requirement_type": "Risikosteuerung", "control_objective": "Kritische IKT-Dienstleistungen und deren Schutzbedarf werden identifiziert und in das IKT-Risikomanagement einbezogen.", "target_state": "Eine institutsspezifische Definition und Identifikation kritischer IKT-Dienstleistungen ist etabliert. Der Schutzbedarf dieser Dienstleistungen hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit ist dokumentiert und wird bei Änderungen aktualisiert.", "implementation_steps": [ "Kriterien für kritische IKT-Dienstleistungen definieren.", "IKT-Dienstleistungen identifizieren und Kritikalität bewerten.", "Schutzbedarf je kritischer Dienstleistung feststellen.", "Ergebnisse mit IKT-Risikoinventar und Kontrollsystem verknüpfen." ], "evidence_examples": [ "Kriterienkatalog für kritische IKT-Dienstleistungen", "Bewertung der Kritikalität je Dienstleistung", "Schutzbedarfsfeststellung für kritische Dienstleistungen", "Verknüpfung mit Risikoinventar und Kontrollen" ], "iso_control_anchors": [ "5.9", "5.10", "5.19", "8.1" ], "dora_reference": "DORA Art. 7 Abs. 3 (Kritische Dienstleistungen), Art. 8 Abs. 2", "marisk_reference": "MaRisk AT 9 (Auslagerungen), BT 3 (Notfallmanagement)", "cyber_risk_reference": "Fokussierte Cyber-Sicherheitsmaßnahmen für kritische Geschäftsprozesse", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-011", "title": "IKT-Risikoüberwachung mit Frühwarnindikatoren betreiben", "theme": "IKT-Risikomanagement", "requirement_type": "Kontrollaktivität", "control_objective": "IKT-Risiken werden kontinuierlich überwacht und Frühwarnindikatoren zeigen Risikoveränderungen zeitnah an.", "target_state": "Ein Kennzahlensystem mit Frühwarnindikatoren (KRI) für IKT-Risiken ist definiert und in Betrieb. Die Kennzahlen werden regelmässig erhoben, überwacht und bei Schwellwertverletzungen wird eskaliert. Trends und Veränderungen werden analysiert und berichtet.", "implementation_steps": [ "Frühwarnindikatoren für IKT-Risiken identifizieren und definieren.", "Schwellenwerte (Grün/Gelb/Rot) für jeden Indikator festlegen.", "Automatisierte Datenerhebung und Berichterstattung aufbauen.", "Regelmässige Überprüfung der Indikatoren auf Aussagekraft und Aktualität." ], "evidence_examples": [ "Frühwarnindikatoren-Übersicht mit aktuellen Werten", "Schwellwert-Definition und Eskalationsregeln", "Monitoring-Bericht mit Trendanalyse", "Eskalationsnachweise bei Schwellwertverletzung" ], "iso_control_anchors": [ "5.7", "5.8", "5.35", "8.16" ], "dora_reference": "DORA Art. 10 (Überwachung), Art. 11 (Frühwarnung)", "marisk_reference": "MaRisk AT 4.3.5 (Frühwarnung), BT 1.3", "cyber_risk_reference": "Frühzeitige Erkennung von Cyber-Risikoveränderungen durch KRIs", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-012", "title": "Management-Reporting zu IKT-Risiken etablieren", "theme": "IKT-Risikomanagement", "requirement_type": "Bericht / Reporting", "control_objective": "Das Management erhält regelmässig entscheidungsrelevante Informationen über die IKT-Risikolage, Kontrollstatus, Vorfälle und Maßnahmenfortschritt.", "target_state": "Ein standardisiertes Reporting informiert das Management quartalsweise über die IKT-Risikolage: Risikoinventar-Entwicklung, Kontrollergebnisse, Frühwarnindikatoren, wesentliche Vorfälle, Maßnahmenstatus und Reifegradentwicklung.", "implementation_steps": [ "Reporting-Kennzahlen und Berichtsvorlage für IKT-Risiken definieren.", "Berichtsrhythmus (quartalsweise) und Ad-hoc-Berichtsanlässe festlegen.", "Reporting in das gesamtinstitutische Risikoberichtswesen integrieren.", "Reporting regelmässig auf Aussagekraft und Entscheidungsrelevanz prüfen." ], "evidence_examples": [ "Quartalsbericht IKT-Risikomanagement", "Kennzahlen-Dashboard (Risiken, Kontrollen, Maßnahmen)", "Ad-hoc-Bericht bei wesentlicher Veränderung", "Review-Protokoll zur Reporting-Qualität" ], "iso_control_anchors": [ "5.35", "5.36", "5.37" ], "dora_reference": "DORA Art. 5 Abs. 3 (Berichtspflichten), Art. 11 (Risikoberichterstattung)", "marisk_reference": "MaRisk AT 4.3.1 (Reporting), BT 1.4", "cyber_risk_reference": "Entscheidungsrelevante Berichterstattung zur Cyber-Risikolage", "maturity": "managed", "review_status": "reviewed" }, { "id": "DORA-IRM-013", "title": "IKT-Risikobericht an das Leitungsorgan sicherstellen", "theme": "IKT-Risikomanagement", "requirement_type": "Bericht / Reporting", "control_objective": "Das Leitungsorgan erhält regelmässig einen umfassenden Bericht über die IKT-Risikolage und die Wirksamkeit des IKT-Risikomanagements.", "target_state": "Ein jährlicher IKT-Risikobericht informiert das Leitungsorgan über die Risikolage, wesentliche Risikoveränderungen, Kontrollergebnisse, Wirksamkeitsprüfungen, Reifegradentwicklung, Ressourcen- und Budgetbedarf sowie strategische Empfehlungen.", "implementation_steps": [ "Berichtsanforderungen des Leitungsorgans für IKT-Risiken erheben.", "Jährlichen IKT-Risikobericht mit Standardvorlage erstellen.", "Berichtstermin mit Jahresplanung des Leitungsorgans abstimmen.", "Berichtsergebnisse in strategische Planung und Budgetierung einsteuern." ], "evidence_examples": [ "IKT-Risikobericht an Leitungsorgan (jährlich)", "Sitzungsprotokoll mit Behandlung des Berichts", "Beschlussvorlage mit Maßnahmen", "Nachverfolgung der Beschlüsse" ], "iso_control_anchors": [ "5.1", "5.4", "5.36", "5.37" ], "dora_reference": "DORA Art. 5 Abs. 1 (Leitungsorgan), Art. 11 Abs. 2", "marisk_reference": "MaRisk AT 4.3.1 (Leitungsorgan), AT 4.4.1", "cyber_risk_reference": "Strategische Cyber-Risikoberichterstattung an das Leitungsorgan", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-014", "title": "Eskalationsprozess für IKT-Risiken definieren und betreiben", "theme": "IKT-Risikomanagement", "requirement_type": "Governance-Verfahren", "control_objective": "Wesentliche IKT-Risiken, Kontrollabweichungen und Vorfälle werden zeitnah und auf der richtigen Management-Ebene eskaliert.", "target_state": "Ein dokumentierter Eskalationsprozess definiert Eskalationsauslöser, -stufen, -empfänger, -fristen und Kommunikationswege für IKT-Risiken. Eskalationen werden dokumentiert, nachverfolgt und auf Wirksamkeit geprüft.", "implementation_steps": [ "Eskalationsauslöser (Schwellenwerte, Fristen, Risikoklassen) definieren.", "Eskalationsstufen und Entscheidungsbefugnisse je Stufe festlegen.", "Kommunikationswege und -formate für Eskalationen standardisieren.", "Eskalationsprozess regelmässig testen und schulen." ], "evidence_examples": [ "Eskalationsmatrix mit Auslösern und Stufen", "Dokumentierte Eskalationsfälle mit Verlauf", "Eskalationstest-Protokoll", "Schulungsnachweise für Eskalationsprozess" ], "iso_control_anchors": [ "5.2", "5.3", "5.24", "5.35" ], "dora_reference": "DORA Art. 5 Abs. 2 (Eskalation), Art. 6 Abs. 2", "marisk_reference": "MaRisk AT 4.4.1 (Entscheidungswege), BT 3.2", "cyber_risk_reference": "Zeitnahe Eskalation kritischer Cyber-Risiken und -Vorfälle", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-015", "title": "Nachweis- und Evidenzmodell für IKT-Risikomanagement aufbauen", "theme": "IKT-Risikomanagement", "requirement_type": "Nachweis / Evidenz", "control_objective": "Alle IKT-Risikomanagement-Aktivitäten sind revisionssicher nachweisbar und mit dem Evidenzmodell der Plattform verknüpft.", "target_state": "Ein standardisiertes Evidenzmodell ordnet jeder IKT-Risikomanagement-Anforderung konkrete Nachweise zu. Nachweise sind mit Verantwortlichen, Review-Zyklen und Aufbewahrungsfristen versehen. Das Modell wird regelmässig auf Vollständigkeit und Aktualität geprüft.", "implementation_steps": [ "Evidenzkategorien für IKT-Risikomanagement definieren.", "Nachweiszuordnung zu jeder DORA-IRM-Anforderung herstellen.", "Review-Zyklen und Verantwortliche je Nachweis festlegen.", "Evidenzmodell mit Kontrollsystem und Maßnahmentracking verknüpfen." ], "evidence_examples": [ "Evidenzmodell IKT-Risikomanagement (vollständig)", "Nachweisverzeichnis mit Zuordnung zu Anforderungen", "Review-Protokoll der Evidenzen", "Verknüpfung mit Kontroll- und Maßnahmensystem" ], "iso_control_anchors": [ "5.33", "5.34", "5.35", "5.36" ], "dora_reference": "DORA Art. 6 Abs. 4 (Dokumentation), Art. 10 Abs. 3", "marisk_reference": "MaRisk AT 4.4.2 (Dokumentation), BT 2.3", "cyber_risk_reference": "Revisionssichere Nachweisführung für Cyber-Sicherheitsmaßnahmen", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-016", "title": "Integration von DORA, MaRisk und ISO 27001 im IKT-Risikomanagement", "theme": "IKT-Risikomanagement", "requirement_type": "Governance-Verfahren", "control_objective": "Die Anforderungen aus DORA, MaRisk und ISO/IEC 27001:2022 werden im IKT-Risikomanagement konsistent und aufwandsminimierend integriert.", "target_state": "Ein integriertes Anforderungsmapping zeigt die Korrespondenz zwischen DORA-IRM-Artikeln, MaRisk-AT/BT-Ziffern und ISO/IEC 27001:2022-Kontrollen. Gemeinsame Nachweise, Kontrollen und Berichtsformate werden genutzt, um Doppelarbeiten zu vermeiden.", "implementation_steps": [ "Anforderungsmapping zwischen DORA IRM, MaRisk und ISO 27001 durchführen.", "Gemeinsame Kontrollziele und Nachweise identifizieren.", "Integrierte Berichts- und Nachweisstruktur aufbauen.", "Abweichungen und Zusatzanforderungen je Regulation dokumentieren." ], "evidence_examples": [ "Anforderungsmapping DORA–MaRisk–ISO 27001", "Gemeinsame Kontrollzielmatrix", "Integrierte Nachweisstruktur", "Abweichungsanalyse je Regulation" ], "iso_control_anchors": [ "5.1", "5.36", "5.37", "6.1" ], "dora_reference": "DORA Art. 6 Abs. 1, Art. 15 (Konsistenz)", "marisk_reference": "MaRisk AT 1 (Anwendungsbereich), AT 4.1 (Gesamtverantwortung)", "cyber_risk_reference": "Integrierte Cyber-Risikosteuerung über mehrere Regulierungsrahmen", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-IRM-017", "title": "Reifegradmodell für IKT-Risikomanagement etablieren", "theme": "IKT-Risikomanagement", "requirement_type": "Nachweis / Evidenz", "control_objective": "Der Reifegrad des IKT-Risikomanagements wird regelmässig gemessen, berichtet und als Grundlage für Verbesserungsmaßnahmen genutzt.", "target_state": "Ein institutsspezifisches Reifegradmodell bewertet alle Dimensionen des IKT-Risikomanagements (Governance, Risikoidentifikation, -analyse, -behandlung, Kontrollen, Überwachung, Reporting, Kultur) auf einer definierten Skala. Die Bewertung wird jährlich durchgeführt und mit Maßnahmenplänen verbunden.", "implementation_steps": [ "Reifegrad-Dimensionen und Bewertungsstufen für IKT-Risikomanagement definieren.", "Bewertungskriterien je Dimension und Stufe festlegen.", "Jährliche Reifegradbewertung durchführen und dokumentieren.", "Ergebnisse mit Maßnahmen- und Verbesserungsplan verknüpfen." ], "evidence_examples": [ "Reifegradmodell IKT-Risikomanagement", "Jährliche Reifegradbewertung mit Ergebnissen", "Maßnahmenplan aus Reifegradbewertung", "Entwicklungsreport mit Vorjahresvergleich" ], "iso_control_anchors": [ "5.35", "5.36", "10.1", "10.2" ], "dora_reference": "DORA Art. 6 Abs. 5 (Kontinuierliche Verbesserung), Art. 15", "marisk_reference": "MaRisk AT 4.4.2 (Verbesserung), BT 2.4", "cyber_risk_reference": "Reifegradbasierte Steuerung der Cyber-Sicherheitsfähigkeiten", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-IRM-018", "title": "Schulungs- und Sensibilisierungsprogramm für IKT-Risiken aufbauen", "theme": "IKT-Risikomanagement", "requirement_type": "Governance-Verfahren", "control_objective": "Mitarbeitende und Führungskräfte werden regelmässig zu IKT-Risiken geschult und für ihre Verantwortung im IKT-Risikomanagement sensibilisiert.", "target_state": "Ein rollenbasiertes Schulungsprogramm vermittelt IKT-Risikowissen an alle relevanten Mitarbeitenden. Führungskräfte erhalten vertiefende Schulungen zu IKT-Risikosteuerung, Eskalation und Reporting. Schulungsteilnahme und -erfolg werden dokumentiert.", "implementation_steps": [ "Schulungsbedarf für IKT-Risikomanagement rollenbasiert erheben.", "Schulungsprogramm mit Basisschulung (alle) und Vertiefung (Rolleninhaber) entwickeln.", "Jährlichen Schulungsplan erstellen und durchführen.", "Schulungserfolg messen und Programm kontinuierlich verbessern." ], "evidence_examples": [ "Schulungskonzept IKT-Risikomanagement", "Rollenbasierte Schulungsmatrix", "Teilnehmernachweise und Testergebnisse", "Jährlicher Schulungsplan mit Durchführung" ], "iso_control_anchors": [ "5.2", "5.3", "6.3", "7.2" ], "dora_reference": "DORA Art. 5 Abs. 2 (Personal), Art. 6 Abs. 3 (Sensibilisierung)", "marisk_reference": "MaRisk AT 7.1 (Personal), AT 7.2 (Schulung)", "cyber_risk_reference": "Mitarbeitersensibilisierung als Grundpfeiler der Cyber-Sicherheit", "maturity": "defined", "review_status": "reviewed" }, { "id": "DORA-KWF-001", "title": "Methodik zur Bestimmung kritischer oder wichtiger Funktionen etablieren", "theme": "Kritische oder wichtige Funktionen", "requirement_type": "Governance-Verfahren", "control_objective": "Das Institut verfügt über eine dokumentierte und freigegebene Methodik zur Bestimmung kritischer oder wichtiger Funktionen (kwF) nach DORA.", "target_state": "Eine institutsspezifische kwF-Methodik definiert Kriterien, Prozesse, Verantwortlichkeiten und Entscheidungsbefugnisse. Die Methodik berücksichtigt Ausfallperspektive, Pflichtverletzungsperspektive, Zeitkritikalität und regulatorische Bedeutung. Sie wird vom Leitungsorgan freigegeben und mindestens jährlich überprüft.", "implementation_steps": [ "kwF-Kriterienkatalog mit Ausfall-, Pflichtverletzungs-, Zeit- und Regulatorik-Dimensionen entwickeln.", "Methodik mit Prozesslandkarte, Bewertungsmatrix und Entscheidungslogik dokumentieren.", "Methodik durch Leitungsorgan freigeben und kommunizieren.", "Jährlichen Review der Methodik institutionalisieren." ], "evidence_examples": [ "kwF-Methodik-Dokument (freigegeben)", "Kriterienkatalog mit Bewertungsmatrix", "Leitungsorgan-Beschluss zur Methodik", "Review-Protokoll der Methodik" ], "iso_control_anchors": [ "5.7", "5.8", "5.9", "5.36" ], "dora_reference": "DORA Art. 3 Ziffer 23, Art. 28 Abs. 3 (Kritische oder wichtige Funktionen)", "marisk_reference": "MaRisk AT 9 Tz. 3 (Wesentlichkeit von Auslagerungen)", "cyber_risk_reference": "Cyber-Risikoanalyse für kritische Geschäftsprozesse priorisieren", "regulatory_landscape_reference": "kwF-Methodik als zentrale Schnittstelle zwischen DORA, BCM und Risikomanagement", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-KWF-002", "title": "Prozesslandkarte für kwF-Bestimmung aufbauen", "theme": "Kritische oder wichtige Funktionen", "requirement_type": "Operativer Prozess", "control_objective": "Eine vollständige Prozesslandkarte identifiziert alle institutsspezifischen Prozesse als Grundlage für die kwF-Bewertung.", "target_state": "Eine aktuelle Prozesslandkarte erfasst alle Prozesse mit Zuordnung zu regulierten Tätigkeiten, IKT-Abhängigkeiten, Kritikalität und Verantwortlichkeiten. Die Landkarte wird regelmässig aktualisiert und mit dem IKT-Risikoinventar abgeglichen.", "implementation_steps": [ "Prozesse institutsweit inventarisieren und klassifizieren.", "Regulierte Tätigkeiten den Prozessen zuordnen.", "IKT-Abhängigkeiten je Prozess dokumentieren.", "Prozesslandkarte in kwF-Bewertung integrieren." ], "evidence_examples": [ "Prozesslandkarte (vollständig)", "Prozess-Steckbriefe mit IKT-Abhängigkeiten", "Zuordnung regulierte Tätigkeiten", "Aktualisierungsprotokoll" ], "iso_control_anchors": [ "5.7", "5.9", "5.10", "8.1" ], "dora_reference": "DORA Art. 6 Abs. 1 (IKT-Risikomanagement), Art. 28 Abs. 3", "marisk_reference": "MaRisk AT 4.3.3 (Risikoinventar), AT 9 (Auslagerungen)", "cyber_risk_reference": "Prozessabhängigkeiten als Grundlage für Cyber-Risikoanalyse", "regulatory_landscape_reference": "Prozesslandkarte als Grundlage für kwF, BIA und Risikoanalyse", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-KWF-003", "title": "Ausfallszenarien für kwF bewerten", "theme": "Kritische oder wichtige Funktionen", "requirement_type": "Risikosteuerung", "control_objective": "Die Auswirkung eines Ausfalls von Prozessen, IKT-Systemen oder Dienstleistern auf kwF wird systematisch bewertet.", "target_state": "Ein standardisierter Prozess bewertet Ausfallszenarien für alle potenziell kritischen Funktionen. Die Bewertung prüft zeitkritische Wiederherstellungsanforderungen, finanzielle Auswirkungen, Reputationsschäden und regulatorische Konsequenzen.", "implementation_steps": [ "Ausfallszenarien für identifizierte kwF definieren.", "Maximal tolerierbare Ausfallzeiten (MTPD) und Wiederherstellungsziele (RTO/RPO) festlegen.", "Auswirkungen auf finanzielle Leistungsfähigkeit und Solidität bewerten.", "Szenarioergebnisse dokumentieren und in kwF-Entscheidung einfliessen lassen." ], "evidence_examples": [ "Ausfallszenario-Analyse je kwF", "MTPD/RTO/RPO-Definitionen", "Finanzielle Auswirkungsanalyse", "kwF-Entscheidungsdokumentation" ], "iso_control_anchors": [ "5.7", "5.29", "5.30", "8.34" ], "dora_reference": "DORA Art. 7 (Risikoanalyse), Art. 11 (BCM)", "marisk_reference": "MaRisk AT 4.3.3, BT 3 (Notfallmanagement)", "cyber_risk_reference": "Cyber-Ausfallszenarien priorisieren und bewerten", "regulatory_landscape_reference": "Ausfallszenarien verbinden DORA, MaRisk und BCM-Anforderungen", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-KWF-004", "title": "Pflichtverletzungsszenarien für kwF bewerten", "theme": "Kritische oder wichtige Funktionen", "requirement_type": "Risikosteuerung", "control_objective": "Die Auswirkung einer Pflichtverletzung durch Ausfall oder Beeinträchtigung von Prozessen oder IKT-Systemen wird systematisch bewertet.", "target_state": "Ein standardisierter Prozess bewertet Pflichtverletzungsszenarien für alle potenziell kritischen Funktionen. Die Bewertung prüft Verstösse gegen aufsichtsrechtliche Pflichten, Zulassungsanforderungen, Melde- und Dokumentationspflichten sowie sonstige regulatorische Anforderungen.", "implementation_steps": [ "Pflichtverletzungsszenarien für identifizierte kwF definieren.", "Regulatorische Pflichten und Konsequenzen je Szenario dokumentieren.", "Auswirkungen auf Zulassung und Aufsichtspflichten bewerten.", "Szenarioergebnisse dokumentieren und in kwF-Entscheidung einfliessen lassen." ], "evidence_examples": [ "Pflichtverletzungsszenario-Analyse je kwF", "Regulatorische Pflichtenübersicht", "Aufsichtsrechtliche Konsequenzenanalyse", "kwF-Entscheidungsdokumentation" ], "iso_control_anchors": [ "5.7", "5.8", "5.36", "6.1" ], "dora_reference": "DORA Art. 7 (Risikoanalyse), Art. 3 Ziffer 23", "marisk_reference": "MaRisk AT 4.3.3, AT 9 Tz. 3", "cyber_risk_reference": "Cyber-Risiken mit direktem regulatorischem Pflichtverletzungsrisiko priorisieren", "regulatory_landscape_reference": "Pflichtverletzungsszenarien als Erweiterung der reinen BIA-Logik", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-KWF-005", "title": "kwF-Managementfreigabe und Dokumentation sicherstellen", "theme": "Kritische oder wichtige Funktionen", "requirement_type": "Governance-Verfahren", "control_objective": "Die Einstufung als kritische oder wichtige Funktion wird managementseitig freigegeben und dokumentiert.", "target_state": "Jede kwF-Einstufung wird auf der dafür vorgesehenen Management-Ebene freigegeben. Die Entscheidung wird mit Begründung, Kriterienanwendung und Verantwortlichkeiten dokumentiert. Änderungen der Einstufung durchlaufen denselben Freigabeprozess.", "implementation_steps": [ "Freigabestufen für kwF-Einstufungen definieren.", "Entscheidungsvorlage mit Kriterienanwendung entwickeln.", "kwF-Entscheidungen dokumentieren und managementseitig freigeben.", "Änderungsmanagement für kwF-Einstufungen etablieren." ], "evidence_examples": [ "kwF-Entscheidungsvorlage mit Kriterien", "Managementfreigabe je kwF", "Änderungsdokumentation bei Reklassifikation", "Jährlicher Review der kwF-Entscheidungen" ], "iso_control_anchors": [ "5.1", "5.2", "5.3", "5.36" ], "dora_reference": "DORA Art. 5 (Governance), Art. 28 Abs. 3", "marisk_reference": "MaRisk AT 4.3.1 (Gesamtverantwortung)", "cyber_risk_reference": "Management-Entscheidung über Kritikalität von Cyber-Risiken", "regulatory_landscape_reference": "kwF-Freigabe als Entscheidungspunkt im übergreifenden Risikorahmen", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-KWF-006", "title": "kwF-Review-Zyklus institutionalisieren", "theme": "Kritische oder wichtige Funktionen", "requirement_type": "Kontrollaktivität", "control_objective": "Die kwF-Einstufungen werden regelmässig überprüft und bei wesentlichen Änderungen aktualisiert.", "target_state": "Ein dokumentierter Review-Prozess prüft kwF-Einstufungen mindestens jährlich sowie anlassbezogen bei wesentlichen Änderungen der Geschäftstätigkeit, Organisation, IKT-Landschaft oder regulatorischen Anforderungen.", "implementation_steps": [ "Jährlichen Review-Termin für kwF-Einstufungen festlegen.", "Anlassbezogene Review-Trigger definieren.", "Review-Ergebnisse dokumentieren und bei Änderungen Managementfreigabe einholen.", "Review-Historie je kwF führen." ], "evidence_examples": [ "Jährlicher kwF-Review-Bericht", "Anlassbezogene Reviews mit Begründung", "Änderungshistorie je kwF", "Managementfreigabe nach Review" ], "iso_control_anchors": [ "5.35", "5.36", "9.1", "10.1" ], "dora_reference": "DORA Art. 6 Abs. 5 (Review), Art. 28 Abs. 3", "marisk_reference": "MaRisk AT 4.4.2 (Review)", "cyber_risk_reference": "Regelmässige Überprüfung der Cyber-Risikobewertung kritischer Funktionen", "regulatory_landscape_reference": "kwF-Review als Teil des kontinuierlichen Verbesserungsprozesses", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-RTA-001", "title": "Tätigkeiteninventar für regulierte Tätigkeiten aufbauen", "theme": "Regulierte Tätigkeiten", "requirement_type": "Operativer Prozess", "control_objective": "Das Institut verfügt über ein vollständiges Inventar aller regulierten Tätigkeiten als Grundlage für kwF, Vorfallklassifikation und Informationsregister.", "target_state": "Ein zentrales Tätigkeiteninventar erfasst alle regulierten Tätigkeiten des Instituts mit Zuordnung zu nationalen und europäischen Begrifflichkeiten, EBA-Identifikatoren und betroffenen IKT-Dienstleistungen.", "implementation_steps": [ "Regulierte Tätigkeiten aus Zulassung und Geschäftsmodell identifizieren.", "Tätigkeiten mit europäischen Begrifflichkeiten und EBA-Identifikatoren abgleichen.", "Zuordnung zu kwF, IKT-Dienstleistungen und Informationsregister herstellen.", "Inventar regelmässig aktualisieren und mit Zulassungsänderungen abgleichen." ], "evidence_examples": [ "Tätigkeiteninventar (aktuell)", "Mapping nationale zu europäische Begrifflichkeiten", "EBA-Identifier-Liste", "Aktualisierungsprotokoll" ], "iso_control_anchors": [ "5.7", "5.9", "5.33" ], "dora_reference": "DORA Art. 3 Ziffer 23, Art. 19 (Vorfallklassifikation), Art. 28 Abs. 3 (Informationsregister)", "marisk_reference": "MaRisk AT 4.3.3 (Risikoinventar)", "cyber_risk_reference": "Cyber-Risikoanalyse auf Basis regulierter Tätigkeiten priorisieren", "regulatory_landscape_reference": "Regulierte Tätigkeiten als Querschnittsinstrument für DORA, MaRisk und Aufsicht", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-RTA-002", "title": "Mapping zwischen nationalen und europäischen Tätigkeitsbegrifflichkeiten etablieren", "theme": "Regulierte Tätigkeiten", "requirement_type": "Operativer Prozess", "control_objective": "Nationale und europäische Begrifflichkeiten für regulierte Tätigkeiten werden konsistent gemappt und dokumentiert.", "target_state": "Ein dokumentiertes Mapping bildet nationale Tätigkeitsbezeichnungen auf europäische Begrifflichkeiten (EBA-Identifier, CRR/CRD, MiFID, AIFMD etc.) ab. Das Mapping wird bei regulatorischen Änderungen aktualisiert.", "implementation_steps": [ "Nationale Tätigkeitsbezeichnungen aus Zulassungsbescheiden erfassen.", "Europäische Begrifflichkeiten und EBA-Identifier recherchieren und zuordnen.", "Mapping-Dokumentation mit Quellen und Gültigkeitsstand erstellen.", "Aktualisierung bei regulatorischen oder geschäftlichen Änderungen sicherstellen." ], "evidence_examples": [ "Mapping-Dokumentation national/europäisch", "EBA-Identifier-Zuordnungstabelle", "Quellenverzeichnis für Begrifflichkeiten", "Aktualisierungsnachweise" ], "iso_control_anchors": [ "5.33", "5.34", "5.36" ], "dora_reference": "DORA Art. 28 Abs. 3 (Informationsregister), Art. 19 (Vorfallklassifikation)", "marisk_reference": "MaRisk AT 4.3.3", "cyber_risk_reference": "Präzise Klassifikation der Cyber-Risiken je regulierter Tätigkeit", "regulatory_landscape_reference": "Konsistentes Begriffsverständnis über DORA, CRR, MiFID und nationale Regelungen", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-RTA-003", "title": "EBA-Identifier-Logik für das Informationsregister umsetzen", "theme": "Regulierte Tätigkeiten", "requirement_type": "Nachweis / Evidenz", "control_objective": "Die EBA-Identifier und deren Zuordnung zu IKT-Dienstleistungen sind für das Informationsregister korrekt und aktuell.", "target_state": "Die EBA-Identifier sind für jede regulierte Tätigkeit erfasst und den zugehörigen IKT-Dienstleistungen zugeordnet. Die Datenqualität wird regelmässig geprüft und Abweichungen werden korrigiert.", "implementation_steps": [ "EBA-Identifier aus EBA-Register und aufsichtlichen Vorgaben ableiten.", "Identifier den regulierten Tätigkeiten zuordnen.", "Verknüpfung mit IKT-Dienstleistungen im Informationsregister herstellen.", "Datenqualität durch regelmässige Abgleiche sichern." ], "evidence_examples": [ "EBA-Identifier-Tabelle mit Tätigkeitszuordnung", "Verknüpfung im Informationsregister", "Datenqualitätsbericht", "Korrekturprotokoll bei Abweichungen" ], "iso_control_anchors": [ "5.33", "5.34", "5.36" ], "dora_reference": "DORA Art. 28 Abs. 3 (Informationsregister)", "marisk_reference": "MaRisk AT 9 Tz. 6", "cyber_risk_reference": "Datenqualität als Grundlage für Cyber-Risikoanalyse", "regulatory_landscape_reference": "EBA-Identifier als Datenqualitätsanker für das Informationsregister", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-RTA-004", "title": "Registerdatenqualität für regulierte Tätigkeiten sicherstellen", "theme": "Regulierte Tätigkeiten", "requirement_type": "Kontrollaktivität", "control_objective": "Die Datenqualität der regulierten Tätigkeiten im Informationsregister wird systematisch überprüft und verbessert.", "target_state": "Ein Prozess zur Sicherstellung der Registerdatenqualität definiert Vollständigkeits-, Korrektheits- und Aktualitätskriterien. Regelmässige Qualitätskontrollen identifizieren Fehler und leiten Korrekturmaßnahmen ein. Verantwortlichkeiten für Datenpflege und -prüfung sind festgelegt.", "implementation_steps": [ "Datenqualitätskriterien für regulierte Tätigkeiten definieren.", "Regelmässige Qualitätskontrollen (mindestens quartalsweise) durchführen.", "Fehlerprotokoll mit Korrekturmaßnahmen und Fristen führen.", "Verantwortlichkeiten für Datenpflege und Qualitätssicherung zuweisen." ], "evidence_examples": [ "Datenqualitätsbericht (aktuell)", "Fehlerprotokoll mit Korrekturmaßnahmen", "Kontrollplan für Registerdatenqualität", "Review-Protokoll der Datenqualität" ], "iso_control_anchors": [ "5.33", "5.34", "5.35", "5.36" ], "dora_reference": "DORA Art. 28 Abs. 3 (Informationsregister), Art. 29 (Datenqualität)", "marisk_reference": "MaRisk AT 9 Tz. 6", "cyber_risk_reference": "Verlässliche Datenbasis für Cyber-Risikoanalyse", "regulatory_landscape_reference": "Datenqualität als übergreifende Anforderung für Meldewesen und Register", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-CON-001", "title": "Vertragsklassifikation für IKT-Dienstleistungen etablieren", "theme": "IKT-Verträge", "requirement_type": "Governance-Verfahren", "control_objective": "IKT-Dienstleistungsverträge werden nach Kritikalität und Komplexität klassifiziert, um angemessene Anforderungen je Kategorie zu definieren.", "target_state": "Eine verbindliche Vertragsklassifikation unterscheidet Baseline IKT-Leistung, kontrollrelevante IKT-Leistung, kwF-relevante IKT-Leistung und strategisch kritische IKT-Leistung. Jede Kategorie hat definierte Mindestanforderungen an Vertragsinhalte, Kontrollrechte und Überwachung.", "implementation_steps": [ "Klassifikationskriterien für IKT-Verträge entwickeln.", "Kategorien (Baseline, kontrollrelevant, kwF-relevant, strategisch kritisch) definieren.", "Bestandsverträge klassifizieren und nachkategorisieren.", "Klassifikation bei Vertragsänderungen und jährlich überprüfen." ], "evidence_examples": [ "Vertragsklassifikations-Richtlinie", "Klassifizierte Vertragsliste", "Überprüfungsprotokoll der Klassifikation", "Abweichungsdokumentation" ], "iso_control_anchors": [ "5.19", "5.20", "5.33" ], "dora_reference": "DORA Art. 28 (Vertragsanforderungen), Art. 29 (Überwachung)", "marisk_reference": "MaRisk AT 9 (Auslagerungen), BT 4", "cyber_risk_reference": "Risikobasierte Klassifikation der Cyber-Anforderungen je Vertragskategorie", "regulatory_landscape_reference": "Vertragsklassifikation als Grundlage für DORA, MaRisk und aufsichtliche Prüfung", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-CON-002", "title": "Mindestvertragsinhalte nach DORA sicherstellen", "theme": "IKT-Verträge", "requirement_type": "Vertragsanforderung", "control_objective": "IKT-Dienstleistungsverträge enthalten alle nach DORA und institutsspezifisch erforderlichen Mindestinhalte.", "target_state": "Eine standardisierte Vertragsprüfung stellt sicher, dass alle IKT-Verträge Leistungsbeschreibung, Rechte und Pflichten, Informationssicherheitsanforderungen, SLA-Vereinbarungen, Datenstandorte, Datenschutzklauseln, Kündigungsfristen, Haftungsregelungen und Änderungsmanagement enthalten.", "implementation_steps": [ "Mindestvertragsinhalte je Klassifikationskategorie definieren.", "Vertragsprüfprozess mit Checkliste und Freigabestufen etablieren.", "Bestandsverträge auf Lücken prüfen und nachbessern.", "Abweichungen dokumentieren und managementseitig freigeben." ], "evidence_examples": [ "Vertragsanforderungsmatrix je Kategorie", "Prüf-Checkliste für IKT-Verträge", "Lückenanalyse Bestandsverträge", "Abweichungsregister mit Freigabe" ], "iso_control_anchors": [ "5.19", "5.20", "5.31", "5.33" ], "dora_reference": "DORA Art. 28 Abs. 2 (Vertragsanforderungen)", "marisk_reference": "MaRisk AT 9 Tz. 7, BT 4 Tz. 3", "cyber_risk_reference": "Vertragliche Absicherung von Cyber-Sicherheitsanforderungen", "regulatory_landscape_reference": "Vertragsinhalte als Nachweis für aufsichtsrechtliche Anforderungen", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-CON-003", "title": "Unterauftragnehmerregelungen vertraglich sichern", "theme": "IKT-Verträge", "requirement_type": "Vertragsanforderung", "control_objective": "Verträge mit IKT-Dienstleistern enthalten Regelungen zur Offenlegung, Genehmigung und Steuerung von Unterauftragnehmern.", "target_state": "Alle IKT-Verträge verpflichten Dienstleister zur Offenlegung wesentlicher Unterauftragnehmer und zur Einholung der Zustimmung bei Änderungen der Unterauftragnehmerkette. Ein aktuelles Unterauftragnehmerverzeichnis dokumentiert die vollständige Leistungskette.", "implementation_steps": [ "Vertragsklauseln zu Unterauftragnehmern (Offenlegung, Genehmigung, Änderung) definieren.", "Unterauftnehmerverzeichnis je kritischer IKT-Dienstleistung aufbauen.", "Regelmässige Aktualisierung und Prüfung der Unterauftragnehmerkette.", "Konzentrationsrisiken durch gemeinsame Unterauftragnehmer identifizieren." ], "evidence_examples": [ "Vertragsklauseln zu Unterauftragnehmern", "Unterauftragnehmerverzeichnis (aktuell)", "Genehmigungsdokumentation bei Änderungen", "Konzentrationsrisikoanalyse Unterauftragnehmer" ], "iso_control_anchors": [ "5.19", "5.20", "5.21", "5.22" ], "dora_reference": "DORA Art. 28 Abs. 2 lit. e (Unterauftragnehmer)", "marisk_reference": "MaRisk AT 9 Tz. 5, BT 4 Tz. 2", "cyber_risk_reference": "Erweiterte Angriffsfläche durch Unterauftragnehmerketten", "regulatory_landscape_reference": "Durchgängige Transparenz über die gesamte Dienstleisterkette", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-CON-004", "title": "Exit-Regelungen vertraglich verankern", "theme": "IKT-Verträge", "requirement_type": "Vertragsanforderung", "control_objective": "IKT-Verträge enthalten verbindliche Exit-Regelungen für eine geordnete Beendigung, Übertragung oder Ersetzung der Dienstleistung.", "target_state": "Alle IKT-Verträge mit kwF-Relevanz enthalten Exit-Klauseln mit Kündigungsfristen, Datenrückgabe- und Löschverpflichtungen, Übergangsunterstützung, Migrationshilfen und Herausgabepflichten. Die Exit-Regelungen werden regelmässig auf Angemessenheit und Umsetzbarkeit geprüft.", "implementation_steps": [ "Exit-Mindestklauseln je Vertragskategorie definieren.", "Datenrückgabe-, Lösch- und Migrationsverpflichtungen vertraglich regeln.", "Übergangsfristen und Unterstützungsleistungen vereinbaren.", "Exit-Regelungen regelmässig auf Aktualität und Umsetzbarkeit prüfen." ], "evidence_examples": [ "Exit-Klauseln je IKT-Vertrag", "Datenrückgabe- und Löschkonzept", "Prüfprotokoll Exit-Regelungen", "Abweichungsdokumentation" ], "iso_control_anchors": [ "5.19", "5.29", "5.30", "5.36" ], "dora_reference": "DORA Art. 28 Abs. 2 lit. i (Exit), Art. 29 Abs. 5", "marisk_reference": "MaRisk AT 9 Tz. 9, BT 4 Tz. 6", "cyber_risk_reference": "Sicherer Datentransfer und -löschung beim Dienstleisterwechsel", "regulatory_landscape_reference": "Exit-Fähigkeit als DORA-, MaRisk- und BCM-Anforderung", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-CON-005", "title": "Audit- und Kontrollrechte vertraglich sichern", "theme": "IKT-Verträge", "requirement_type": "Vertragsanforderung", "control_objective": "IKT-Verträge enthalten umfassende Audit- und Kontrollrechte für das Institut und dessen Prüfungsinstanzen.", "target_state": "Verträge mit kwF-relevanten IKT-Dienstleistern enthalten Rechte auf Vor-Ort-Prüfungen, Einsichtnahme in Unterlagen, Zugang zu Systemen und Informationen sowie das Recht auf Prüfungen durch externe Prüfer und Aufsichtsbehörden.", "implementation_steps": [ "Audit- und Kontrollrechte als Pflichtklauseln definieren.", "Ausübungskonzept für Kontrollrechte (Häufigkeit, Umfang, Eskalation) erstellen.", "Kontrollrechte regelmässig ausüben und Ergebnisse dokumentieren.", "Verweigerung von Kontrollrechten als Risikoindikator eskalieren." ], "evidence_examples": [ "Audit-/Kontrollrechte-Klauseln je Vertrag", "Kontrollplan für das laufende Jahr", "Durchgeführte Audits und Prüfberichte", "Eskalationsvermerk bei verweigerten Rechten" ], "iso_control_anchors": [ "5.19", "5.20", "5.36", "9.2" ], "dora_reference": "DORA Art. 28 Abs. 2 lit. f–h (Kontroll- und Zugangsrechte)", "marisk_reference": "MaRisk AT 9 Tz. 7, BT 4 Tz. 4", "cyber_risk_reference": "Prüfbarkeit von Cyber-Sicherheitsmaßnahmen beim Dienstleister", "regulatory_landscape_reference": "Kontrollrechte als Instrument der aufsichtlichen Prüfung", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-CON-006", "title": "Berichtspflichten in IKT-Verträgen regeln", "theme": "IKT-Verträge", "requirement_type": "Vertragsanforderung", "control_objective": "IKT-Verträge enthalten verbindliche Berichtspflichten über Leistungserbringung, Sicherheitslage und Risikoentwicklung.", "target_state": "Verträge mit IKT-Dienstleistern definieren regelmässige Berichtspflichten zu SLA-Einhaltung, Sicherheitsvorfällen, Änderungen der Leistungserbringung, Personalveränderungen in Schlüsselfunktionen und Ergebnissen von Sicherheitsprüfungen.", "implementation_steps": [ "Berichtsanforderungen je Vertragskategorie definieren.", "Berichtsformate, -frequenzen und -empfänger festlegen.", "Eingehende Berichte prüfen und bei Abweichungen eskalieren.", "Berichtsqualität regelmässig bewerten und nachsteuern." ], "evidence_examples": [ "Berichtsanforderungsmatrix je Vertrag", "Eingegangene Dienstleisterberichte", "Prüfprotokoll der Berichtsinhalte", "Eskalationsnachweise bei Berichtsmängeln" ], "iso_control_anchors": [ "5.19", "5.23", "5.35", "5.36" ], "dora_reference": "DORA Art. 29 Abs. 1–2 (Überwachung und Berichtswesen)", "marisk_reference": "MaRisk AT 9 Tz. 8, BT 4 Tz. 5", "cyber_risk_reference": "Regelmässige Berichterstattung über Cyber-Sicherheitslage des Dienstleisters", "regulatory_landscape_reference": "Berichtspflichten als Nachweis der laufenden Überwachung", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-POL-001", "title": "Richtlinieninventar für IKT-Sicherheits- und DORA-Richtlinien aufbauen", "theme": "IKT-Richtlinien", "requirement_type": "Governance-Verfahren", "control_objective": "Das Institut verfügt über ein vollständiges und aktuelles Inventar aller IKT-Sicherheitsrichtlinien und DORA-relevanten Richtlinien.", "target_state": "Ein zentrales Richtlinieninventar erfasst alle IKT-Richtlinien mit Zweck, Geltungsbereich, Version, Freigabedatum, verantwortlicher Rolle, Review-Zyklus und Verknüpfung zu DORA-, MaRisk- und ISO-Anforderungen.", "implementation_steps": [ "Richtlinienkategorien (Sicherheit, IKT-Risiko, BCM, Auslagerungen etc.) definieren.", "Bestehende Richtlinien inventarisieren und kategorisieren.", "Richtlinienlücken gegen DORA- und MaRisk-Anforderungen identifizieren.", "Inventar regelmässig aktualisieren und mit Richtlinien-Review synchronisieren." ], "evidence_examples": [ "Richtlinieninventar (vollständig, aktuell)", "Lückenanalyse Richtlinien vs. DORA/MaRisk", "Kategorisierungsmatrix", "Aktualisierungsprotokoll" ], "iso_control_anchors": [ "5.1", "5.2", "5.33", "5.36" ], "dora_reference": "DORA Art. 6 Abs. 4 (Dokumentation), Art. 8 (Schutzmaßnahmen)", "marisk_reference": "MaRisk AT 4.4.2 (Dokumentation)", "cyber_risk_reference": "Richtlinien als Grundlage für Cyber-Sicherheitskontrollen", "regulatory_landscape_reference": "Richtlinieninventar als Nachweis der Dokumentationspflicht", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-POL-002", "title": "Dokumentenlenkung für IKT-Richtlinien etablieren", "theme": "IKT-Richtlinien", "requirement_type": "Governance-Verfahren", "control_objective": "IKT-Richtlinien durchlaufen einen standardisierten Dokumentenlenkungsprozess von Erstellung über Freigabe bis zur Archivierung.", "target_state": "Ein dokumentierter Dokumentenlenkungsprozess definiert Phasen (Entwurf, Abstimmung, Freigabe, Veröffentlichung, Review, Archivierung), Rollen (Autor, Prüfer, Freigeber) und Fristen. Jede Richtlinie hat eine eindeutige Version, Änderungshistorie und Gültigkeitsdauer.", "implementation_steps": [ "Dokumentenlenkungsprozess mit Phasen und Rollen definieren.", "Richtlinienvorlage mit Pflichtfeldern entwickeln.", "Versionierung und Änderungshistorie sicherstellen.", "Archivierungsregeln für abgelöste Richtlinien festlegen." ], "evidence_examples": [ "Dokumentenlenkungsprozess (Dokument)", "Richtlinienvorlage mit Metadaten", "Änderungshistorie je Richtlinie", "Archivierungsnachweis" ], "iso_control_anchors": [ "5.1", "5.33", "5.34", "5.36" ], "dora_reference": "DORA Art. 6 Abs. 4 (Dokumentation)", "marisk_reference": "MaRisk AT 4.4.2", "cyber_risk_reference": "Nachvollziehbare Richtlinienversionen für Sicherheitsaudits", "regulatory_landscape_reference": "Dokumentenlenkung als Grundlage für prüfbare Nachweise", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-POL-003", "title": "Leitungsorganfreigabe für IKT-Richtlinien sicherstellen", "theme": "IKT-Richtlinien", "requirement_type": "Governance-Verfahren", "control_objective": "Wesentliche IKT-Richtlinien werden durch das Leitungsorgan oder die dafür bestimmte Management-Ebene freigegeben.", "target_state": "Eine Freigabematrix definiert, welche Richtlinien durch das Leitungsorgan, welche durch die Geschäftsleitung und welche durch Fachbereichsleitungen freigegeben werden. Der Freigabeprozess ist dokumentiert und nachvollziehbar.", "implementation_steps": [ "Freigabematrix für IKT-Richtlinien definieren.", "Freigabeprozess mit Vorlagen und Fristen standardisieren.", "Freigaben dokumentieren und in der Richtlinie vermerken.", "Freigabe bei Richtlinienänderungen erneut einholen." ], "evidence_examples": [ "Freigabematrix IKT-Richtlinien", "Freigabevermerk in jeder Richtlinie", "Sitzungsprotokolle bei Leitungsorgan-Freigabe", "Änderungsdokumentation mit erneuter Freigabe" ], "iso_control_anchors": [ "5.1", "5.2", "5.3", "5.36" ], "dora_reference": "DORA Art. 5 Abs. 1 (Leitungsorgan)", "marisk_reference": "MaRisk AT 4.3.1 (Gesamtverantwortung)", "cyber_risk_reference": "Management-Commitment für Cyber-Sicherheitsrichtlinien", "regulatory_landscape_reference": "Freigabe als Nachweis der Leitungsorgan-Verantwortung", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-POL-004", "title": "Review-Trigger für IKT-Richtlinien definieren", "theme": "IKT-Richtlinien", "requirement_type": "Kontrollaktivität", "control_objective": "IKT-Richtlinien werden anlassbezogen und mindestens jährlich auf Aktualität und Angemessenheit überprüft.", "target_state": "Ein dokumentierter Review-Prozess definiert verbindliche Trigger für die Überprüfung von IKT-Richtlinien: mindestens jährlich, nach wesentlichen IKT-Vorfällen, nach Resilienztests, nach Audits, nach behördlichen Hinweisen und bei wesentlichen Änderungen der Geschäftstätigkeit, Bedrohungslage oder rechtlichen Anforderungen.", "implementation_steps": [ "Review-Trigger-Katalog für IKT-Richtlinien definieren.", "Jährlichen Review-Plan für alle Richtlinien erstellen.", "Anlassbezogene Reviews bei Trigger-Ereignissen auslösen.", "Review-Ergebnisse dokumentieren und bei Bedarf Richtlinien anpassen." ], "evidence_examples": [ "Review-Trigger-Katalog", "Jährlicher Review-Plan", "Durchgeführte Reviews mit Ergebnissen", "Richtlinienänderungen aus Reviews" ], "iso_control_anchors": [ "5.35", "5.36", "9.1", "10.1" ], "dora_reference": "DORA Art. 6 Abs. 5 (Review), Art. 12 (Tests)", "marisk_reference": "MaRisk AT 4.4.2 (Review)", "cyber_risk_reference": "Aktualisierung von Richtlinien nach Cyber-Vorfällen und Bedrohungsänderungen", "regulatory_landscape_reference": "Review-Trigger als Instrument der kontinuierlichen Verbesserung", "maturity": "initial", "review_status": "reviewed" }, { "id": "DORA-POL-005", "title": "Kontroll- und Nachweislogik in IKT-Richtlinien integrieren", "theme": "IKT-Richtlinien", "requirement_type": "Kontrollaktivität", "control_objective": "IKT-Richtlinien enthalten eine dokumentierte Kontroll- und Nachweislogik, die die Einhaltung der Richtlinienanforderungen belegbar macht.", "target_state": "Jede IKT-Richtlinie enthält einen Abschnitt zur Kontroll- und Nachweislogik, der die zugehörigen Kontrollen, Nachweise, Verantwortlichkeiten und Prüffrequenzen beschreibt. Die Kontroll- und Nachweislogik ist mit dem IKT-Kontrollsystem der Plattform abgestimmt.", "implementation_steps": [ "Kontroll- und Nachweisanforderungen je Richtlinie definieren.", "Nachweisartefakte und Aufbewahrungsfristen festlegen.", "Verknüpfung mit dem plattformweiten Evidenzmodell herstellen.", "Kontroll- und Nachweislogik regelmässig auf Vollständigkeit prüfen." ], "evidence_examples": [ "Kontroll- und Nachweislogik je Richtlinie", "Verknüpfungstabelle Richtlinien–Kontrollen–Nachweise", "Prüfprotokoll der Kontroll- und Nachweislogik", "Abweichungsbericht" ], "iso_control_anchors": [ "5.35", "5.36", "8.8", "9.1" ], "dora_reference": "DORA Art. 8 (Schutzmaßnahmen), Art. 10 (Wirksamkeit)", "marisk_reference": "MaRisk AT 4.4.2 (Kontrollsystem)", "cyber_risk_reference": "Nachweis der Einhaltung von Cyber-Sicherheitsrichtlinien", "regulatory_landscape_reference": "Integrierte Nachweislogik über Richtlinien-, Kontroll- und Prüfsysteme", "maturity": "initial", "review_status": "reviewed" }, { "id": "REG-NIS2-001", "title": "NIS2-Anwendungsbereich für das Institut prüfen und dokumentieren", "theme": "Regulatory Landscape", "requirement_type": "Governance-Verfahren", "control_objective": "Das Institut prüft, ob und in welchem Umfang der NIS2-Anwendungsbereich für seine Tätigkeiten relevant ist.", "target_state": "Eine dokumentierte Prüfung bewertet den Einrichtungsstatus (besonders wichtig, wichtig, nicht betroffen) nach NIS2. Die Prüfung berücksichtigt die DORA-Ausnahmeregelung und dokumentiert die Begründung für die Einstufung.", "implementation_steps": [ "NIS2-Kriterien für besonders wichtige und wichtige Einrichtungen prüfen.", "DORA-Ausnahmeregelung und deren Voraussetzungen dokumentieren.", "Einrichtungsstatus institutsspezifisch bestimmen und begründen.", "Prüfung jährlich und bei wesentlichen Änderungen wiederholen." ], "evidence_examples": [ "NIS2-Anwendungsbereichsprüfung (dokumentiert)", "Einrichtungsstatus-Begründung", "DORA-Ausnahmeprüfung", "Jährliches Review der Einstufung" ], "iso_control_anchors": [ "5.1", "5.2", "5.36" ], "dora_reference": "DORA Art. 1 Abs. 3 (Ausnahme von NIS2)", "marisk_reference": "–", "cyber_risk_reference": "NIS2 als ergänzender Cybersecurity-Rahmen zu DORA", "regulatory_landscape_reference": "NIS2–DORA-Schnittstelle als Ausgangspunkt für die regulatorische Landschaft", "maturity": "initial", "review_status": "reviewed" }, { "id": "REG-CRA-001", "title": "CRA-Produktbezug für IKT-Produkte und -Dienstleistungen prüfen", "theme": "Regulatory Landscape", "requirement_type": "Risikosteuerung", "control_objective": "Das Institut prüft, welche IKT-Produkte mit digitalen Elementen in den Anwendungsbereich des Cyber Resilience Act fallen.", "target_state": "Eine dokumentierte Prüfung identifiziert IKT-Produkte mit digitalen Elementen, die unter den CRA fallen könnten. Hersteller-, Händler- und Betreiberpflichten werden eingeordnet und in die Beschaffungs- und Vertragsprozesse integriert.", "implementation_steps": [ "IKT-Produkte mit digitalen Elementen inventarisieren.", "CRA-Anwendungsbereich je Produkt prüfen.", "Hersteller-/Lieferantenpflichten in Beschaffungsanforderungen übersetzen.", "Schwachstellenmanagement und Security-Updates in Verträgen adressieren." ], "evidence_examples": [ "CRA-Produktinventar", "Anwendungsbereichsprüfung je Produkt", "Beschaffungsanforderungen mit CRA-Bezug", "Vertragsklauseln zu Updates und Schwachstellen" ], "iso_control_anchors": [ "5.19", "5.20", "5.21", "8.34" ], "dora_reference": "DORA Art. 28 Abs. 2 (Vertragsanforderungen), Art. 29 (Überwachung)", "marisk_reference": "MaRisk AT 9 (Auslagerungen)", "cyber_risk_reference": "CRA als Produktsicherheitsrahmen für Cyber-Resilienz", "regulatory_landscape_reference": "CRA ergänzt DORA um die Produkt- und Herstellerperspektive", "maturity": "initial", "review_status": "reviewed" }, { "id": "REG-AIA-001", "title": "KI-Inventar nach AI Act aufbauen", "theme": "Regulatory Landscape", "requirement_type": "Operativer Prozess", "control_objective": "Das Institut verfügt über ein vollständiges Inventar aller eingesetzten KI-Systeme als Grundlage für die AI-Act-Governance.", "target_state": "Ein KI-Inventar erfasst alle KI-Systeme mit Klassifikation (verboten, Hochrisiko, geringes Risiko, minimales Risiko), Zweck, Einsatzbereich, Datenquellen, Verantwortlichen und Risikobewertung.", "implementation_steps": [ "KI-Systeme institutsweit identifizieren und erfassen.", "Klassifikation nach AI-Act-Risikokategorien durchführen.", "Verantwortlichkeiten für KI-Governance zuweisen.", "Inventar regelmässig aktualisieren und mit Änderungsmanagement verbinden." ], "evidence_examples": [ "KI-Inventar (vollständig, aktuell)", "Klassifikationsmatrix nach AI-Act-Kategorien", "Verantwortungsmatrix KI-Governance", "Aktualisierungsprotokoll" ], "iso_control_anchors": [ "5.7", "5.8", "5.9", "5.33" ], "dora_reference": "DORA Art. 6 (IKT-Risikomanagement)", "marisk_reference": "MaRisk AT 4.3.3", "cyber_risk_reference": "KI-Systeme als Teil der Cyber-Risikoanalyse und Angriffsfläche", "regulatory_landscape_reference": "KI-Inventar als Grundlage für AI-Act-Compliance", "maturity": "initial", "review_status": "reviewed" }, { "id": "REG-AIA-002", "title": "KI-Kompetenz nach AI Act institutsweit sicherstellen", "theme": "Regulatory Landscape", "requirement_type": "Governance-Verfahren", "control_objective": "Mitarbeitende und Führungskräfte verfügen über ausreichende KI-Kompetenz entsprechend ihrer Rolle und Verantwortung.", "target_state": "Ein rollenbasiertes KI-Kompetenzprogramm vermittelt Grundlagenwissen zu KI-Funktionsweise, -Risiken, -Chancen und regulatorischen Anforderungen. Das Programm wird mindestens jährlich durchgeführt und aktualisiert.", "implementation_steps": [ "KI-Kompetenzbedarf rollenbasiert erheben.", "Schulungsprogramm mit Basis- und Vertiefungsmodulen entwickeln.", "Schulungen durchführen und Teilnahme dokumentieren.", "KI-Kompetenz regelmässig auf Aktualität prüfen und Programm anpassen." ], "evidence_examples": [ "KI-Kompetenzrahmen mit Rollenzuordnung", "Schulungsprogramm und -materialien", "Teilnehmernachweise", "Kompetenzbewertung und -entwicklung" ], "iso_control_anchors": [ "5.2", "5.3", "6.3", "7.2" ], "dora_reference": "DORA Art. 5 Abs. 2 (Personal), Art. 6 Abs. 3 (Schulung)", "marisk_reference": "MaRisk AT 7.1, AT 7.2", "cyber_risk_reference": "KI-Kompetenz als Teil der Cyber-Sicherheitssensibilisierung", "regulatory_landscape_reference": "KI-Kompetenz als Querschnittsanforderung über AI Act, DORA und MaRisk", "maturity": "initial", "review_status": "reviewed" }, { "id": "OSS-001", "title": "Open-Source-Richtlinie etablieren", "theme": "Open Source & Software Supply Chain", "requirement_type": "Governance-Verfahren", "control_objective": "Die Nutzung von Open Source Software ist durch eine freigegebene Richtlinie geregelt.", "target_state": "Eine vom Management freigegebene Richtlinie definiert den Geltungsbereich, zulässige Lizenzen, Genehmigungsprozess, Verantwortlichkeiten und Eskalationswege. Die Richtlinie wird jährlich überprüft und bei wesentlichen Änderungen aktualisiert.", "implementation_steps": [ "IST-Stand zur OSS-Nutzung und Lizenzierung erheben.", "Richtlinienentwurf mit Geltungsbereich, Lizenzmatrix, Genehmigungsprozess und Rollen erstellen.", "Richtlinie durch Management freigeben und an alle relevanten Stellen kommunizieren.", "Jährlichen Review-Prozess institutionalisieren." ], "evidence_examples": [ "Freigegebene Open-Source-Richtlinie (aktuell)", "Lizenz-Compliance-Matrix", "Kommunikationsnachweis an Mitarbeitende und Lieferanten", "Review-Protokoll mit Änderungshistorie" ], "iso_control_anchors": [ "5.1", "5.2", "5.3", "5.36", "8.1" ], "dora_reference": "Art. 5, Art. 8, Art. 9, Art. 24, Art. 28", "marisk_reference": "AT 4.3.1, AT 7.2", "cyber_risk_reference": "Governance-Verfahren für Open-Source-Sicherheit und Software-Integrität", "maturity": "defined", "review_status": "reviewed" }, { "id": "OSS-002", "title": "SBOM-Erzeugung automatisieren", "theme": "Open Source & Software Supply Chain", "requirement_type": "Operativer Prozess", "control_objective": "Für jede relevante Anwendung und jedes Release wird automatisiert eine SBOM erzeugt.", "target_state": "Die SBOM-Erzeugung ist in die CI/CD-Pipeline integriert. Jede SBOM dokumentiert direkte und transitive Abhängigkeiten mit Version, Lizenz und Herkunft. SBOMs werden versioniert, archiviert und mit dem Schwachstellenmanagement verknüpft.", "implementation_steps": [ "SBOM-Werkzeuge (SPDX/CycloneDX) in der Build-Pipeline evaluieren und integrieren.", "SBOM-Format und Pflichtfelder institutsspezifisch definieren.", "Automatisierte SBOM-Erzeugung für alle relevanten Anwendungen einrichten.", "SBOM-Versionierung und Archivierung je Release konfigurieren.", "SBOM-Daten mit Schwachstellendatenbanken koppeln." ], "evidence_examples": [ "SBOM-Generator-Konfiguration in CI/CD", "Ausgelieferte SBOM je Release (SPDX/CycloneDX)", "Archivierungsnachweis (Versionshistorie)", "Integrationstest Schwachstellenabgleich" ], "iso_control_anchors": [ "8.2", "8.7", "8.8", "8.19", "8.25" ], "dora_reference": "Art. 6, Art. 7, Art. 8, Art. 24, Art. 28", "marisk_reference": "AT 4.3.2, AT 7.2, BT 1.1", "cyber_risk_reference": "SBOM als Grundlage für Schwachstellenmanagement und Software Supply Chain Security", "maturity": "defined", "review_status": "reviewed" }, { "id": "OSS-003", "title": "OSS-Komponenteninventar pflegen", "theme": "Open Source & Software Supply Chain", "requirement_type": "Operativer Prozess", "control_objective": "Ein zentrales Inventar erfasst alle relevanten OSS-Komponenten mit Anwendung, Version, Kritikalität und Eigentümer.", "target_state": "Das OSS-Komponenteninventar ist mit dem Informationsregister und dem IKT-Assetmanagement verknüpft. Jede Komponente ist mit SBOM-ID, Anwendung, Kritikalität, Patch-Status und Risikobewertung erfasst. Das Inventar wird bei jeder Änderung aktualisiert.", "implementation_steps": [ "Komponenteninventar-Datenmodell mit Pflichtfeldern definieren.", "Erstinventur aller OSS-Komponenten aus SBOMs und manueller Erfassung durchführen.", "Inventar mit Informationsregister, IKT-Assets und Anwendungen verknüpfen.", "Regelmäßige Aktualisierung bei neuen Releases oder Änderungen etablieren." ], "evidence_examples": [ "OSS-Komponenteninventar (vollständig, aktuell)", "Datenmodell-Dokumentation", "Verknüpfungsnachweis mit Informationsregister", "Änderungsprotokoll je Komponente" ], "iso_control_anchors": [ "5.9", "5.10", "8.1", "8.19", "8.25" ], "dora_reference": "Art. 6, Art. 7, Art. 10, Art. 28", "marisk_reference": "AT 4.3.3, BT 1, BT 1.1", "cyber_risk_reference": "Systematische Erfassung und Bewertung von OSS-Komponenten als IKT-Assets", "maturity": "initial", "review_status": "reviewed" }, { "id": "OSS-004", "title": "OSS-Schwachstellenmanagement betreiben", "theme": "Open Source & Software Supply Chain", "requirement_type": "Risikosteuerung", "control_objective": "Schwachstellen in OSS-Komponenten werden systematisch erkannt, bewertet und behandelt.", "target_state": "Ein siebenstufiger Workflow (Erkennung → Triage → Impact Assessment → Entscheidung → Umsetzung → Verifikation → Reporting) steuert alle OSS-Schwachstellen. Critical- und High-Findings unterliegen einem Human Gate. Behandlungsergebnisse fließen in das Management-Reporting.", "implementation_steps": [ "SBOM-Daten automatisiert gegen NVD, OSV und GitHub Advisory abgleichen.", "CVSS-basierte Bewertung mit Geschäftsrelevanz und kwF-Bezug etablieren.", "Human Gates für Risikoakzeptanz, Patch-Ausnahmen und Lieferanteneskalation definieren.", "Reporting-Prozess für kritische Findings aufbauen." ], "evidence_examples": [ "Schwachstellenbericht (monatlich)", "CVSS-Bewertung mit Triage-Entscheidung", "Human-Gate-Dokumentation für Akzeptanzen", "Management-Reporting zu OSS-Schwachstellen" ], "iso_control_anchors": [ "5.7", "5.8", "8.8", "8.19", "8.25" ], "dora_reference": "Art. 8, Art. 10, Art. 11, Art. 24, Art. 28", "marisk_reference": "AT 4.3.3, AT 4.3.4, BT 1.2", "cyber_risk_reference": "Schwachstellenmanagement als Kernprozess der Cyber-Risikosteuerung", "maturity": "defined", "review_status": "reviewed" }, { "id": "OSS-005", "title": "Patch- und Ausnahmemanagement steuern", "theme": "Open Source & Software Supply Chain", "requirement_type": "Risikosteuerung", "control_objective": "Sicherheitskritische Updates werden zeitnah bewertet, Abweichungen werden begründet und überwacht.", "target_state": "Ein standardisiertes Patch-Management definiert SLA-Zeiträume je Kritikalität. Abweichungen (compensating control, risk acceptance, supplier escalation) werden im Decision Log dokumentiert und unterliegen einer zeitlichen Befristung. Kompensierende Kontrollen werden auf Wirksamkeit überwacht.", "implementation_steps": [ "Patch-SLA nach Kritikalität (Critical: 30d, High: 90d, Medium: 180d) festlegen.", "Entscheidungsmatrix mit fünf Optionen (Patch, Upgrade, Compensating Control, Risk Acceptance, Supplier Escalation) etablieren.", "Ausnahmeentscheidungen im Decision Log mit Begründung und Befristung dokumentieren.", "Kompensierende Kontrollen auf Wirksamkeit prüfen." ], "evidence_examples": [ "Patch-Status-Übersicht (aktuell)", "Decision-Log-Einträge für Ausnahmen", "Wirksamkeitsnachweise kompensierender Kontrollen", "SLA-Erfüllungsreport" ], "iso_control_anchors": [ "5.7", "8.8", "8.19", "8.25", "8.26" ], "dora_reference": "Art. 8, Art. 10, Art. 11, Art. 24, Art. 28", "marisk_reference": "AT 4.3.4, BT 2, BT 2.1", "cyber_risk_reference": "Zeitnahe Patch-Bereitstellung als kritische Cyber-Sicherheitsmaßnahme", "maturity": "defined", "review_status": "reviewed" }, { "id": "OSS-006", "title": "Lieferanten-SBOM-Anforderungen durchsetzen", "theme": "Open Source & Software Supply Chain", "requirement_type": "Governance-Verfahren", "control_objective": "IKT-Dienstleister sind vertraglich verpflichtet, SBOMs und OSS-Prozessinformationen bereitzustellen.", "target_state": "Eine Standard-Vertragsklausel verpflichtet IKT-Dienstleister zur Bereitstellung von SBOMs in SPDX- oder CycloneDX-Format. Schwachstellen-Meldung und Patch-SLA sind vertraglich fixiert. Auditrechte für OSS-Prozesse sind vereinbart. Die Einhaltung wird regelmäßig überprüft.", "implementation_steps": [ "Standard-Vertragsklausel für Lieferanten-SBOM entwickeln und mit Legal abstimmen.", "SBOM-Anforderungen in IKT-Verträge und Ausschreibungen integrieren.", "Lieferanten-SBOMs bei Vertragsbeginn und je Release anfordern.", "SBOM-Compliance der Lieferanten regelmäßig überprüfen und dokumentieren." ], "evidence_examples": [ "Standard-Vertragsklausel (freigegeben)", "Lieferanten-SBOM-Verzeichnis", "SBOM-Compliance-Bericht", "Auditnachweis für Lieferanten-OSS-Prozesse" ], "iso_control_anchors": [ "5.19", "5.20", "5.21", "5.22", "5.23" ], "dora_reference": "Art. 28, Art. 30, Art. 33", "marisk_reference": "AT 9, BT 2.3", "cyber_risk_reference": "Durchsetzung von SBOM-Transparenz über die gesamte Software-Lieferkette", "maturity": "initial", "review_status": "reviewed" }, { "id": "OFS-001", "title": "API-Inventar und API-Risikoklassifizierung führen", "theme": "Open Finance Security", "maturity": "defined", "requirement_type": "Verpflichtend", "review_status": "reviewed", "control_objective": "Alle internen, externen und Drittanbieter-APIs sind inventarisiert, klassifiziert und mit Owner dokumentiert.", "target_state": "Vollständiges API-Inventar mit Authentifizierungsmethode, Rate-Limits, Datenklasse und Kritikalität.", "dora_reference": "Art. 8, Art. 9, Art. 28", "marisk_reference": "AT 4.3.1, AT 7.2, AT 9", "implementation_steps": [ "API-Endpunkte über Discovery-Tools und manuelle Erfassung inventarisieren", "Klassifizierung nach Datenart (PII, Zahlungsdaten, öffentlich) und Kritikalität durchführen", "Owner (Product Owner + Security Engineer) je API dokumentieren", "Inventar in API-Gateway/Service Catalog integrieren und quartalsweise aktualisieren" ], "evidence_examples": [ "API-Inventar (CSV/JSON-Export mit Timestamp)", "Klassifikationsmatrix mit Kritikalitätsbewertung", "RACI je API-Endpunkt" ], "iso_control_anchors": [ 8, 9, 12 ] }, { "id": "OFS-002", "title": "FAPI-/OIDC-konforme OAuth-Profile für sensible Finanz-APIs nutzen", "theme": "Open Finance Security", "maturity": "defined", "requirement_type": "Verpflichtend", "review_status": "reviewed", "control_objective": "OAuth 2.0 wird mit Authorization Code + PKCE, restriktiven Scopes und Token-Rotation eingesetzt.", "target_state": "Alle Open-Finance-APIs nutzen FAPI-konforme OAuth-Profile mit dokumentierter Client-Registrierung.", "dora_reference": "Art. 8, Art. 9, Art. 28", "marisk_reference": "AT 4.3.1, AT 7.2", "implementation_steps": [ "Authorization Code Grant + PKCE (Proof Key for Code Exchange) einführen", "FAPI 2.0 Security Profile (FAPI 2.0 Baseline + Advanced) evaluieren", "Client-Registrierung mit dokumentierten Redirect-URIs und Scope-Requests etablieren" ], "evidence_examples": [ "OAuth-Client-Register (Audit-Log-fähig)", "FAPI-Konformitäts-Assessment (FAPI OP/CIBA-Test-Suite)", "Scope- und Token-Policy-Dokumentation" ], "iso_control_anchors": [ 8, 9, 12 ] }, { "id": "OFS-003", "title": "mTLS-Zertifikats- und Schlüsselmanagement betreiben", "theme": "Open Finance Security", "maturity": "defined", "requirement_type": "Verpflichtend", "review_status": "reviewed", "control_objective": "mTLS-Verbindungen werden mit sicheren TLS-Konfigurationen, Zertifikatsüberwachung und Sperrprozessen betrieben.", "target_state": "Zertifikatsinventar, Key-Rotation, TLS-Audit und Revocation-Test dokumentiert.", "dora_reference": "Art. 8, Art. 9", "marisk_reference": "AT 4.3.1, AT 7.2", "implementation_steps": [ "Zertifikatsinventar mit Ablaufdaten, CA, Domains und Verantwortlichen führen", "TLS-Konfiguration auf mindestens TLS 1.2 festlegen (TLS 1.3 anstreben)", "Automatische Zertifikatsrotation (z. B. via cert-manager/ACME) implementieren", "Revocation-Test für jedes Zertifikat nach Deployment durchführen" ], "evidence_examples": [ "mTLS-Zertifikatsinventar mit SHA-256-Fingerprint", "TLS-Konfigurations-Audit (SSL Labs, testssl.sh)", "Revocation-Test-Protokoll mit Datum + Ergebnis" ], "iso_control_anchors": [ 8, 10, 12 ] } ]