Zum Inhalt springen
Decision-State-Infrastruktur
ende
Anwendungen

DORA IKT-Risiko

DORA / IKT-RISIKOBEHANDLUNG

Was muss geklärt sein, bevor eine IKT-Risikobehandlung abgeschlossen werden kann?

Eine technische Maßnahme kann vollständig implementiert sein, ohne dass die zugrunde liegende IKT-Risikobehandlung bereits abgeschlossen werden kann.

Denn für eine belastbare Entscheidung reicht es nicht zu wissen, dass eine zweite Region aufgebaut, ein Recovery-Prozess implementiert oder ein Failover-Test durchgeführt wurde. Die Organisation muss zusätzlich wissen, welche Wirkung die Maßnahmen tatsächlich nachweisen, welches IKT-Restrisiko danach verbleibt, welche Unsicherheiten in dieser Bewertung enthalten sind, wie sich das verbleibende Risiko zur festgelegten IKT-Risikotoleranz verhält, welche Alternativen bestehen, wer welchen Teil des Zustands verantwortet und welche Authority einen verbleibenden Risk State gegebenenfalls übernehmen darf.

Im illustrativen Fall betreibt eine große europäische Universalbank einen Core Payment Hub, der eine von ihr intern als kritisch oder wichtig klassifizierte Payment Execution Function unterstützt. Nach einem umfangreichen Multi-Region-Resilience-Programm ist die technische Umsetzung weitgehend abgeschlossen.

Die Secondary Processing Region ist verfügbar. Die Payment Engine kann failovern. Akzeptierte Payment Instructions bleiben in den geprüften Szenarien erhalten. Monitoring und Recovery Procedures funktionieren. Doch ein integrierter Peak-Load-Test zeigt, dass eine notwendige Payment-Screening-Dependency im Recovery-Pfad nicht den erforderlichen Durchsatz erreicht. Dadurch wächst ein Processing Backlog und die vollständige End-to-End-Recovery überschreitet die intern festgelegte Recovery Boundary.

Die entscheidende Frage lautet nicht, ob das Resilience-Projekt technisch fertig ist. Sie lautet, ob die Bank auf Basis des aktuellen Evidence-, Effectiveness-, Uncertainty-, Tolerance- und Authority-Zustands die Behandlung des identifizierten IKT-Risikos tatsächlich abschließen kann.

TREATMENT IMPLEMENTED ≠ RISK TREATED

I / DIE RISK DECISION

Entschieden wird ein geregelter Risk-Treatment-State – nicht der Projektabschluss

01

Nicht das Resilience-Projekt wird abgeschlossen. Ein konkreter Risk-Treatment-State wird entschieden.

Nehmen wir eine illustrative große europäische Universalbank. Für diesen Fall nennen wir die zentrale Plattform Core Payment Hub. Sie unterstützt eine Payment Execution Function und verbindet unter anderem Payment Intake, Payment Orchestration, Payment Screening, Account Posting, Clearing- und Settlement-Schnittstellen, Reconciliation, Monitoring und Recovery-Prozesse.

Die Bank hat diese Payment Execution Function in ihrem eigenen Governance-Modell als critical or important function klassifiziert. Diese Klassifizierung ist Teil des illustrativen Szenarios. Epistemis entscheidet nicht, welche konkrete Funktion eines Finanzunternehmens regulatorisch als kritisch oder wichtig einzustufen ist.

Primärquelle: Verordnung (EU) 2022/2554 — DORA

Kann die Behandlung des identifizierten Regional-Outage-IKT-Risikos für die Payment Execution Function abgeschlossen werden – und welcher verbleibende Risk State darf danach unter welchen Bedingungen weitergetragen werden?

Dimension

Business Function

Gegenstand

Payment Execution

Dimension

ICT System

Gegenstand

Core Payment Hub

Dimension

Risk Scenario

Gegenstand

Ausfall einer Processing Region

Dimension

Risk Tolerance

Gegenstand

intern festgelegte Resilience-Grenzen

Dimension

Treatment

Gegenstand

Multi-Region-Resilience-Programm

Dimension

Evidence

Gegenstand

Architektur-, Failover-, Integrity- und End-to-End-Testnachweise

Dimension

Effectiveness

Gegenstand

tatsächlich nachgewiesene Risikoreduktion

Dimension

Residual Risk

Gegenstand

nach Treatment verbleibendes IKT-Risiko

Dimension

Uncertainty

Gegenstand

noch nicht ausreichend bestimmte Teile dieses Risk State

Dimension

Alternatives

Gegenstand

weitere Assurance, Treatment, anderer Operating Mode oder Acceptance

Dimension

Responsibility

Gegenstand

Verantwortung für einzelne Zustände

Dimension

Authority

Gegenstand

Befugnis zur Assessment- bzw. Acceptance-Entscheidung

Dimension

Review

Gegenstand

Bedingungen für spätere Neubewertung

Die Bank entscheidet nicht über ein abstraktes „Risk closed“. Sie entscheidet über einen spezifischen Decision Space.

02

DORA trennt Treatment, Wirksamkeit und Restrisiko

Die Delegierte Verordnung (EU) 2024/1774 verlangt Verfahren zur Bewertung von IKT-Risiken, zur Identifikation, Implementierung und Dokumentation von Treatment Measures, zur Bestimmung der Maßnahmen, die erforderlich sind, um IKT-Risiko innerhalb der festgelegten Risikotoleranz zu bringen, zur Überwachung der Wirksamkeit implementierter Treatment Measures, zur Beurteilung der Risikotoleranz, zur Identifikation verbleibender IKT-Restrisiken, zu deren Acceptance Governance, Begründung und späteren Review.

Primärquelle: Delegierte Verordnung (EU) 2024/1774

RISK ASSESSED

↓

TREATMENT IMPLEMENTED

↓

EFFECTIVENESS ASSESSED

↓

TOLERANCE RELATION DETERMINED

↓

RESIDUAL ICT RISK IDENTIFIED

↓

ACCEPT / FURTHER TREAT / ESCALATE

↓

REVIEW

03

Was den Risk-Treatment Decision State tatsächlich bildet

Der Decision State ist nicht der Zustand des Resilience-Projekts. Er entsteht erst aus mehreren verbundenen Dimensionen.

Zustandsdimension

Risk Identity

Leitfrage

Welches konkrete IKT-Risiko wird betrachtet?

Zustandsdimension

Risk Tolerance

Leitfrage

Welche intern autorisierte Risikotoleranz gilt?

Zustandsdimension

Treatment

Leitfrage

Welche Maßnahmen wurden tatsächlich umgesetzt?

Zustandsdimension

Evidence

Leitfrage

Welche Aussagen werden durch welche Nachweise getragen?

Zustandsdimension

Effectiveness

Leitfrage

Welche Risk-Reduction-Wirkung ist tatsächlich nachgewiesen?

Zustandsdimension

Residual Risk

Leitfrage

Welches IKT-Risiko bleibt nach Treatment bestehen?

Zustandsdimension

Uncertainty

Leitfrage

Welche Teile sind noch nicht ausreichend charakterisiert?

Zustandsdimension

Assumptions

Leitfrage

Welche Annahmen müssen weiter gelten?

Zustandsdimension

Alternatives

Leitfrage

Welche ernsthaften Alternativen bestehen?

Zustandsdimension

Responsibility

Leitfrage

Wer verantwortet welchen Teil des Zustands?

Zustandsdimension

Authority

Leitfrage

Wer darf welchen State beurteilen oder akzeptieren?

Zustandsdimension

Objections / Conditions

Leitfrage

Welche Einwände oder Bedingungen bleiben offen?

Zustandsdimension

Review

Leitfrage

Wann muss der Zustand erneut bewertet werden?

Treatment Implementation ist nur ein Input in den Decision State. Es ist nicht der Decision State selbst.

Der Risk-Treatment Decision State verbindet das identifizierte IKT-Risiko mit Risikotoleranz, Treatment, Evidence, tatsächlicher Effectiveness, verbleibendem Risiko, Unsicherheit, Alternativen, Verantwortung, Authority und Review Conditions.
IDENTIFIED ICT RISK
RISK TOLERANCE
TREATMENT
EVIDENCE
EFFECTIVENESS
RESIDUAL RISK
UNCERTAINTY
ASSUMPTIONS
ALTERNATIVES
RESPONSIBILITY
AUTHORITY
REVIEW CONDITIONS

State bei T0

Decision State v1

Full Treatment Closure

Treatment Implementation ist ein Input in diesen Zustand. Es ist nicht der Decision State selbst.

II / AKTUELLER TREATMENT STATE

Ein technisch weit entwickeltes Treatment-Programm kann zugleich offene Evidence-, Risk- und Authority-States enthalten

04

Das ursprüngliche IKT-Risiko ist klar abgegrenzt

Ein länger dauernder Ausfall der primären Processing Region könnte die Payment Execution Function länger beeinträchtigen, als es die intern festgelegte ICT Risk Tolerance zulässt.

Der Risk Scope ist nicht auf einen einzelnen Server oder Service reduziert. DORA verlangt die Identifikation und Dokumentation der unterstützten Business Functions, ICT Systems, Assets und relevanten Abhängigkeiten.

Primärquelle: Verordnung (EU) 2022/2554 — DORA

State

Payment Execution Function

Zustand

RESOLVED

State

Core Payment Hub

Zustand

RESOLVED

State

Regional Failure Scenario

Zustand

RESOLVED

State

Relevante ICT Assets

Zustand

RESOLVED

State

Wesentliche Dependencies

Zustand

RESOLVED

State

Business Impact Scope

Zustand

RESOLVED

05

Treatment Effectiveness braucht eine autorisierte Risk-Tolerance-Grenze

Die Wirksamkeit einer Risikobehandlung lässt sich nicht isoliert beurteilen. Es muss klar sein, welchen Risk State die Behandlung überhaupt erreichen soll.

Im Szenario besitzt die Bank ein intern genehmigtes ICT Risk Tolerance Framework. DORA ordnet dem Management Body die Gesamtverantwortung für das ICT Risk Management und die Festlegung des angemessenen ICT Risk Tolerance Level im Rahmen der Digital Operational Resilience Strategy zu.

Primärquelle: Verordnung (EU) 2022/2554 — DORA

Tolerance State

ICT Risk Tolerance Framework

Zustand

RESOLVED

Tolerance State

Zuständige Governance

Zustand

RESOLVED

Tolerance State

Relevante Payment-Resilience-Grenzen

Zustand

RESOLVED

Tolerance State

Anwendung auf diesen Decision Space

Zustand

RESOLVED

06

Die Treatment Measures sind weitgehend implementiert

  • 01Secondary Processing Region — geografisch getrennte Processing Environment verfügbar.
  • 02Transaction-State Protection — akzeptierte Payment Instructions und relevanter Processing State werden repliziert.
  • 03Recovery Orchestration — Recovery Steps sind standardisiert und teilweise automatisiert.
  • 04Network Resilience — erforderliche Connectivity Paths zur Secondary Environment sind vorbereitet.
  • 05Monitoring — Recovery State, Processing Backlog und wesentliche Dependencies werden überwacht.
  • 06Recovery Procedures — Runbooks, Eskalation und Fallback-Prozesse sind definiert.
  • 07End-to-End Testing — die vollständige Payment Execution Function kann unter Failover-Bedingungen getestet werden.

Treatment Measure

Secondary Region

Zustand

IMPLEMENTED

Treatment Measure

Transaction-State Protection

Zustand

IMPLEMENTED

Treatment Measure

Recovery Orchestration

Zustand

IMPLEMENTED

Treatment Measure

Network Resilience

Zustand

IMPLEMENTED

Treatment Measure

Monitoring

Zustand

IMPLEMENTED

Treatment Measure

Recovery Procedures

Zustand

IMPLEMENTED

Treatment Measure

End-to-End Testing Capability

Zustand

IMPLEMENTED

TREATMENT IMPLEMENTED

≠

RISK TREATED

07

Ein vorhandener Test ist noch kein Nachweis für jede Entscheidungsbehauptung

Die Bank besitzt bereits umfangreiche Evidence. Die relevante Frage ist jedoch nicht, welche Test Reports existieren, sondern welche konkrete Aussage über diesen Risk-Treatment-State welcher Test tatsächlich trägt.

Entscheidungsbehauptung

Secondary Region ist verfügbar

Evidence

Deployment Evidence

Zustand

RESOLVED

Entscheidungsbehauptung

Payment Engine kann regional failovern

Evidence

Regional Failover Test

Zustand

RESOLVED

Entscheidungsbehauptung

Akzeptierte Payment Instructions bleiben erhalten

Evidence

Transaction Integrity Test

Zustand

RESOLVED

Entscheidungsbehauptung

Recovery Procedures sind ausführbar

Evidence

Operational Exercise

Zustand

RESOLVED

Entscheidungsbehauptung

Backlog ist beobachtbar

Evidence

Monitoring Evidence

Zustand

RESOLVED

Entscheidungsbehauptung

Standard-Load Recovery erfüllt die interne Boundary

Evidence

End-to-End Test

Zustand

RESOLVED

Entscheidungsbehauptung

Peak-Load-End-to-End-Recovery erfüllt die Boundary

Evidence

Peak-Load Test

Zustand

NOT DEMONSTRATED

Entscheidungsbehauptung

Screening Recovery besitzt ausreichende Capacity

Evidence

Peak-Load Evidence

Zustand

INCOMPLETE

Entscheidungsbehauptung

Länger laufende Backlog-Clearance ist beherrschbar

Evidence

Extended Recovery Evidence

Zustand

INCOMPLETE

Ein technisch korrekter Control kann implementiert sein, während seine vollständige Risk-Reduction-Wirkung noch nicht ausreichend nachgewiesen ist.

08

Implementation und Effectiveness sind unterschiedliche States

Im entscheidenden Peak-Load-Test übernimmt die Secondary Region, der zentrale Payment Engine recovered, akzeptierte Payment Instructions bleiben erhalten und Monitoring erkennt den Backlog. Doch eine notwendige Payment-Screening-Dependency erreicht im Recovery-Pfad nicht den erforderlichen Durchsatz.

PAYMENT ENGINE — RECOVERED

ABER

SCREENING THROUGHPUT — DEGRADED

↓

PAYMENT BACKLOG — GROWS

↓

END-TO-END RECOVERY — EXCEEDS INTERNAL BOUNDARY

Effectiveness Dimension

Payment Engine Recovery

Zustand

EFFECTIVE IN TESTED SCOPE

Effectiveness Dimension

Transaction Integrity

Zustand

EFFECTIVE IN TESTED SCOPE

Effectiveness Dimension

Monitoring

Zustand

EFFECTIVE

Effectiveness Dimension

Operational Recovery

Zustand

EFFECTIVE IN TESTED SCOPE

Effectiveness Dimension

Standard-Load End-to-End Recovery

Zustand

EFFECTIVE

Effectiveness Dimension

Peak-Load End-to-End Recovery

Zustand

NOT YET EFFECTIVE AGAINST REQUIRED BOUNDARY

Die RTS verlangen genau diese zusätzliche Betrachtung: Nach Implementierung der Treatment Measures muss deren Wirksamkeit überwacht und beurteilt werden, ob die festgelegte Risikotoleranz erreicht wurde.

Primärquelle: Delegierte Verordnung (EU) 2024/1774

09

Nach Treatment existiert ein anderer Risk State

Vor Treatment konnte eine regionale Störung die Payment Execution Function über die tolerierte Grenze hinaus unterbrechen. Nach Treatment kann die Core Payment Engine failovern, aber unter Peak Load kann eine Screening-Dependency einen Backlog erzeugen, der die vollständige End-to-End-Recovery über die zugrunde gelegte Recovery Boundary hinaus verlängert.

ORIGINAL ICT RISK

≠

RESIDUAL ICT RISK

Residual-Risk-Dimension

Residual Risk exists

Zustand

KNOWN

Residual-Risk-Dimension

Failure mechanism

Zustand

KNOWN

Residual-Risk-Dimension

Relevante Dependency

Zustand

KNOWN

Residual-Risk-Dimension

Richtung der Wirkung

Zustand

KNOWN

Residual-Risk-Dimension

Vollständige Magnitude

Zustand

NOT FULLY CHARACTERISED

Residual-Risk-Dimension

Dauerprofil

Zustand

OPEN

Residual-Risk-Dimension

Relation zur Risk Tolerance

Zustand

UNRESOLVED

Residual-Risk-Dimension

Acceptance

Zustand

NOT EXERCISED

10

Ein bekanntes Restrisiko kann trotzdem wesentliche Unsicherheit enthalten

Residual Risk und Uncertainty sind nicht dasselbe. Der Risk State beschreibt, was passieren könnte. Der Uncertainty State beschreibt, wie gut wir diesen Risk State kennen.

Uncertainty

Payment Engine Failover

Zustand

CHARACTERISED

Uncertainty

Transaction Integrity

Zustand

CHARACTERISED IN TESTED SCOPE

Uncertainty

Screening Bottleneck

Zustand

IDENTIFIED

Uncertainty

Peak-Load Backlog Growth

Zustand

PARTIALLY CHARACTERISED

Uncertainty

Extended Backlog Clearance

Zustand

OPEN

Uncertainty

Payment-Mix Sensitivity

Zustand

OPEN

Uncertainty

Dependency Degradation Interaction

Zustand

OPEN

Uncertainty

Residual-Risk Magnitude

Zustand

MATERIAL UNCERTAINTY OPEN

Ein identifiziertes Restrisiko ist nicht automatisch ein ausreichend bestimmter Restrisiko-Zustand.

11

Annahmen dürfen nicht still zu Fakten werden

  • 01Die Secondary Region bleibt ausreichend unabhängig.
  • 02Payment Screening bleibt im Recovery-Pfad verfügbar.
  • 03Screening Capacity degradiert nicht weiter.
  • 04Payment Mix bleibt innerhalb bestimmter Grenzen.
  • 05Recovery Personnel ist verfügbar.
  • 06Monitoring funktioniert zuverlässig.
  • 07Der Backlog wächst nicht unbegrenzt.
  • 08Downstream-Schnittstellen bleiben erreichbar.

OBSERVATION

≠

EVIDENCE

≠

ASSUMPTION

„Der Backlog wird sich nach kurzer Zeit stabilisieren“ bleibt eine offene Annahme, solange dies nicht entsprechend belegt ist.

12

Der Decision Space enthält mehr als schließen oder nicht schließen

Candidate

A / Full Treatment Closure

Zustand

CURRENT PROPOSAL

Candidate

B / Additional Assurance

Zustand

AVAILABLE

Candidate

C / Additional Treatment

Zustand

AVAILABLE

Candidate

D / Different Recovery Operating Mode

Zustand

AVAILABLE

Candidate

E / Time-Bound Conditional Residual-Risk Acceptance

Zustand

AVAILABLE

Candidate

F / Treatment bleibt offen

Zustand

AVAILABLE

Diese Candidates sind keine Empfehlungen von Epistemis. Eine nachvollziehbare Entscheidung bewahrt nicht nur das gewählte Ergebnis, sondern auch die ernsthaften Alternativen, die zum Entscheidungszeitpunkt bestanden.

13

Treatment Owner, Risk Assessor und Acceptance Authority sind nicht dieselbe Rolle

Rolle

Payment Business Function Owner

Illustrative Verantwortung

Business Criticality und Operating Requirements

Rolle

Payment Platform Owner

Illustrative Verantwortung

Treatment Implementation

Rolle

Operational Resilience

Illustrative Verantwortung

Recovery- und Effectiveness Evidence

Rolle

ICT Risk Function

Illustrative Verantwortung

ICT Risk Assessment und Residual-Risk-State

Rolle

Independent Control Function

Illustrative Verantwortung

Oversight und Challenge

Rolle

Residual-Risk Acceptance Authority

Illustrative Verantwortung

Acceptance des dafür vorgesehenen Risk State

Rolle

Internal Audit

Illustrative Verantwortung

unabhängige spätere Prüfung

DORA legt die Gesamtverantwortung für ICT Risk Governance beim Management Body und verlangt eine angemessene Governance- und Rollentrennung. Daraus folgt jedoch nicht, dass jede konkrete Residual-Risk-Entscheidung automatisch vom Management Body selbst getroffen werden muss; die konkrete Acceptance Authority hängt von der Governance des Unternehmens ab.

Primärquelle: Verordnung (EU) 2022/2554 — DORA

TREATMENT OWNER

≠

RISK ASSESSOR

≠

ACCEPTANCE AUTHORITY

14

Authority ist selbst ein State

Authority Dimension

Risk-Tolerance Authority

Zustand

BOUND

Authority Dimension

Treatment Implementation Responsibility

Zustand

BOUND

Authority Dimension

Assurance Responsibility

Zustand

BOUND

Authority Dimension

ICT Risk Assessment Responsibility

Zustand

BOUND

Authority Dimension

Independent Challenge

Zustand

AVAILABLE

Authority Dimension

Residual-Risk Acceptance Authority

Zustand

IDENTIFIED

Authority Dimension

Actual Residual-Risk Acceptance

Zustand

NOT YET EXERCISED

AUTHORITY EXISTS ≠ AUTHORITY HAS ACCEPTED THIS STATE. Authority kann einen unzureichend bestimmten Risk State nicht durch ihre bloße Existenz ausreichend bestimmt machen.

15

Unterschiedliche fachliche Positionen sind Teil des Decision State

  • 01Payment Platform — die vereinbarten Architekturmaßnahmen wurden umgesetzt.
  • 02Operational Resilience — Standard-Load Recovery ist nachgewiesen; Peak-Load-End-to-End-Recovery erfüllt die erforderliche Boundary noch nicht.
  • 03ICT Risk — der Residual Risk ist identifiziert, seine vollständige Magnitude aber noch nicht ausreichend charakterisiert.
  • 04Business Function Owner — ein dauerhaft offener Resilience-State erzeugt selbst operative und strategische Kosten.
  • 05Independent Risk / Control — ein Acceptance-Prozess darf den unvollständig nachgewiesenen Treatment State nicht als remediated darstellen.

16

Decision Space v1 ist jetzt vollständig sichtbar

Dimension

Risk Identity

Zustand

RESOLVED

Dimension

Risk Tolerance

Zustand

RESOLVED

Dimension

Treatment Implementation

Zustand

RESOLVED

Dimension

Standard-Load Evidence

Zustand

RESOLVED

Dimension

Peak-Load Evidence

Zustand

INCOMPLETE

Dimension

Treatment Effectiveness

Zustand

PARTIAL

Dimension

Residual ICT Risk

Zustand

IDENTIFIED

Dimension

Residual-Risk Magnitude

Zustand

MATERIAL UNCERTAINTY OPEN

Dimension

Tolerance Relation

Zustand

UNRESOLVED

Dimension

Alternatives

Zustand

VISIBLE

Dimension

Responsibility

Zustand

BOUND

Dimension

Acceptance Authority

Zustand

IDENTIFIED

Dimension

Acceptance

Zustand

NOT EXERCISED

Dimension

Blocking Objection

Zustand

OPEN

Dimension

Review Model

Zustand

DEFINED

Dimension

Finality

Zustand

NOT AVAILABLE

III / WARUM DER RISK STATE NICHT SCHLIESSEN KANN

Der Blocker ist die ungeklärte Beziehung zwischen Effectiveness, Restrisiko und Tolerance

17

Der Blocker ist nicht „Failover-Test fehlgeschlagen“

PEAK-LOAD END-TO-END TREATMENT EFFECTIVENESS — OPEN

PEAK-LOAD END-TO-END EVIDENCE — INCOMPLETE

↓

TREATMENT EFFECTIVENESS — PARTIAL

↓

RESIDUAL-RISK MAGNITUDE — NOT SUFFICIENTLY CHARACTERISED

↓

RISK-TOLERANCE RELATION — UNRESOLVED

↓

ACCEPTANCE DECISION — NOT YET AVAILABLE

↓

DECISION SPACE v1 — NOT FINALISABLE

Der Blocker ist kein einzelner fehlgeschlagener Test. Er entsteht aus der noch nicht aufgelösten Beziehung zwischen nachgewiesener Treatment Effectiveness, verbleibendem Risk, Unsicherheit und Risk Tolerance.

Wenn Treatment Effectiveness nicht ausreicht, um den aktuellen Decision Space zu schließen, kann SIMULATION entweder untersuchen, was dem bestehenden State fehlt, oder was sich unter einer anderen regelgebundenen Entscheidung verändert. BRIDGE kontrolliert die Rückführung in einen geregelten Decision Space.

DECISION SPACE v1

Full Treatment Closure

BLOCKER / B-01

Peak-Load End-to-End Treatment Effectiveness offen

SIMULATION

01 / Current Space auflösen

  • Zusätzliche Assurance
  • Residual Risk charakterisieren
  • Tolerance Relation bestimmen

02 / Decision Space remodeln

  • Additional Treatment
  • Different Recovery Mode
  • Conditional Acceptance

BRIDGE

Classification · Evidence Inheritance · Residual-Risk-State · Tolerance · Authority · Conditions · Blocker

DECISION SPACE v2

Time-Bound Conditional Residual-Risk Acceptance

SEAL CHECK

Sind alle erforderlichen States dieses Decision Space aufgelöst?

T1 REVIEW

Gilt die Acceptance-Begründung noch?

18

Der State darf noch nicht „above tolerance“ heißen

Wir wissen derzeit nicht ausreichend, ob der vollständig charakterisierte Residual Risk innerhalb der Tolerance liegen wird, an ihrer Grenze liegt oder sie überschreitet.

TOLERANCE RELATION — UNRESOLVED

Unvollständige Evidence darf nicht durch eine vermeintlich präzisere Risk-Klassifikation ersetzt werden.

19

Was SEAL an dieser Stelle nicht sagt

  • 01SEAL sagt nicht, dass das System unsicher ist.
  • 02SEAL sagt nicht, dass die Bank nicht DORA-compliant ist.
  • 03SEAL sagt nicht, dass das Resilience-Programm gescheitert ist.
  • 04SEAL sagt nicht, dass der Risk oberhalb der Tolerance liegt.
  • 05SEAL sagt nicht, dass Residual Risk nicht akzeptiert werden darf.

Die für Full Treatment Closure erforderlichen Zustände bilden noch keinen finalisierbaren gemeinsamen Decision State.

IV / WAS SICH ÄNDERN KÖNNTE

Die Organisation kann den aktuellen Risk Decision Space auflösen – oder eine andere Entscheidung untersuchen

20

Path A: Den bestehenden Decision Space auflösen

Welche offenen States müssten aufgelöst werden, damit Decision Space v1 unter seinen bestehenden Regeln erneut bewertet werden kann?

Evidence

Zusätzliche Assurance könnte Peak-Load Behaviour über längere Zeiträume, Backlog Growth und Clearance, unterschiedliche Payment Mixes, Screening Capacity im Recovery State und zusätzliche Dependency-Degradation-Szenarien untersuchen.

Uncertainty

Offene Unsicherheiten müssten so weit charakterisiert werden, wie es der Decision Space verlangt: wann der Backlog entsteht, wie schnell er wächst, wo er sich stabilisiert, wie lange Clearance benötigt und wie weitere Dependency-Störungen wirken.

Residual Risk und Tolerance

Auf Basis neuer Evidence kann die Organisation den verbleibenden ICT Risk neu bestimmen. Erst dann entsteht eine belastbare Relation zur anwendbaren ICT Risk Tolerance.

Authority

Erst wenn der relevante Risk State ausreichend definiert ist, kann die zuständige Authority über ihn handeln. Authority ersetzt fehlendes Wissen nicht.

21

Path A hat kein vorgegebenes Ergebnis

Ergebnis

A1 / State resolved

Bedeutung

Die Evidence zeigt, dass die bestehenden Treatment Measures die für den Decision Space erforderliche Risk Position erreichen.

Ergebnis

A2 / Treatment insufficient

Bedeutung

Die Evidence zeigt, dass die bestehenden Measures nicht ausreichend sind.

Ergebnis

A3 / Material uncertainty remains

Bedeutung

Auch nach weiterer Assurance bleibt ein wesentlicher State offen.

SIMULATION optimiert nicht auf „grün“. Es untersucht den Decision Space.

22

Path B: Den Decision Space verändern

Was verändert sich, wenn nicht Full Treatment Closure, sondern eine andere regelgebundene Entscheidung betrachtet wird?

Candidate

Additional Treatment

Veränderte Entscheidung

Weitere technische Behandlung der Screening-/Recovery-Dependency.

Candidate

Restricted Recovery Operating Mode

Veränderte Entscheidung

Ein veränderter Operating Scope für den regionalen Recovery State.

Candidate

Time-Bound Conditional Residual-Risk Acceptance

Veränderte Entscheidung

Ein ausreichend charakterisierter Residual-Risk-State wird gegebenenfalls für einen definierten Zeitraum und unter klaren Bedingungen übernommen, während weitere Treatment-Arbeit offen bleibt.

Keine dieser Möglichkeiten ist eine Empfehlung von Epistemis.

V / ACCEPTANCE IST KEINE REMEDIATION

Eine Residual-Risk-Acceptance ist eine andere geregelte Entscheidung – kein umgeschriebener Treatment Closure

23

Decision Space v1 darf nicht rückwirkend verschwinden

Wenn die Organisation später einen Conditional-Acceptance-Candidate untersucht, bleibt der ursprüngliche Zustand erhalten: Full Treatment Closure; Peak-Load Evidence incomplete; Treatment Effectiveness partial; Residual-Risk Magnitude insufficiently characterised; Tolerance Relation unresolved; SEAL blocked.

24

Ein Conditional-Acceptance-Candidate erzeugt einen neuen Decision Space

DECISION SPACE v2 — TIME-BOUND CONDITIONAL RESIDUAL-RISK ACCEPTANCE

Die neue Entscheidung wäre nicht, dass das Risk Treatment jetzt vollständig abgeschlossen ist. Sie wäre, dass ein ausreichend bestimmter verbleibender ICT-Risk-State durch die dafür vorgesehene Authority für eine begrenzte Zeit und unter definierten Bedingungen übernommen wird, während weitere Treatment-Arbeit sichtbar offen bleibt.

25

Acceptance verändert mehrere States gleichzeitig

Dimension

Treatment

v1 Full Treatment Closure

soll abgeschlossen sein

v2 Conditional Acceptance

bleibt teilweise offen

Dimension

Residual Risk

v1 Full Treatment Closure

noch nicht ausreichend bestimmt

v2 Conditional Acceptance

muss ausreichend charakterisiert sein

Dimension

Tolerance Relation

v1 Full Treatment Closure

unresolved

v2 Conditional Acceptance

explizit bestimmt

Dimension

Decision Object

v1 Full Treatment Closure

Treatment Closure

v2 Conditional Acceptance

Residual-Risk Acceptance

Dimension

Authority

v1 Full Treatment Closure

Closure Governance

v2 Conditional Acceptance

Acceptance Authority

Dimension

Duration

v1 Full Treatment Closure

nicht primär begrenzt

v2 Conditional Acceptance

zeitlich gebunden

Dimension

Monitoring

v1 Full Treatment Closure

normaler Operating State

v2 Conditional Acceptance

zusätzliche Acceptance Conditions möglich

Dimension

Further Treatment

v1 Full Treatment Closure

abgeschlossen

v2 Conditional Acceptance

weiterhin offen

Dimension

Review

v1 Full Treatment Closure

regulär

v2 Conditional Acceptance

explizite Review-/Expiry-Punkte

Dimension

Historical v1 Blocker

v1 Full Treatment Closure

blockiert

v2 Conditional Acceptance

bleibt erhalten

Eine Alternative verändert nicht nur das Ergebnis. Sie verändert den Decision Space.

26

Accepted bedeutet nicht remediated

ACCEPTED

≠

REMEDIATED

 

CONDITIONALLY TOLERATED

≠

TECHNICALLY RESOLVED

Eine Residual-Risk-Acceptance darf nicht dazu führen, dass der offene Treatment Effectiveness State rückwirkend als vollständig gelöst dargestellt wird. Die RTS verlangen für akzeptierte Residual ICT Risks Rollen und Verantwortlichkeiten, ein Inventar einschließlich Begründung sowie mindestens jährliche Review.

Primärquelle: Delegierte Verordnung (EU) 2024/1774

27

BRIDGE prüft, ob der neue Candidate wieder in einen geregelten Decision Space darf

  • 01Classification — betrifft der neue Decision Space Residual-Risk-Acceptance statt Treatment Closure?
  • 02Evidence Inheritance — welche Evidence aus v1 bleibt für v2 gültig?
  • 03Residual Risk — ist der verbleibende Risk State ausreichend charakterisiert?
  • 04Risk Tolerance — ist seine Relation zur anwendbaren Tolerance explizit?
  • 05Assumptions — welche Annahmen bleiben gültig und welche neuen entstehen?
  • 06Authority — wer besitzt Authority für genau diese Acceptance?
  • 07Conditions — sind Gültigkeitsdauer, Monitoring, Escalation und Review eindeutig?
  • 08Open Treatment — welche Treatment Work bleibt weiterhin offen?
  • 09Objections — welche professionellen Gegenpositionen bestehen weiter?
  • 10Blockers — gibt es einen offenen State, der auch die Acceptance selbst verhindert?

BRIDGE muss verhindern, dass „accepted residual risk“ durch eine semantische Abkürzung zu „remediated risk“ wird.

Es gibt keinen direkten Pfad: SIMULATION → SEAL.

Wie SIMULATION, BRIDGE und SEAL Exploration, Admissibility und Finalität trennen

28

Decision Space v2 besitzt seinen eigenen vollständigen State

Dimension

Residual Risk Identity

Zustand

RESOLVED

Dimension

Risk Magnitude

Zustand

CHARACTERISED

Dimension

Tolerance Relation

Zustand

KNOWN

Dimension

Treatment Effectiveness

Zustand

PARTIAL / PRESERVED

Dimension

Acceptance Rationale

Zustand

BOUND

Dimension

Acceptance Authority

Zustand

EXERCISED

Dimension

Validity Period

Zustand

BOUND

Dimension

Enhanced Monitoring

Zustand

BOUND

Dimension

Further Treatment

Zustand

OPEN / OWNED

Dimension

Review Trigger

Zustand

BOUND

Dimension

Blocking Objection

Zustand

NONE

Ein offener Treatment State kann in einem anderen Decision Space erhalten bleiben. Das macht ihn nicht automatisch zu einem Blocker dieses neuen Decision Space. Entscheidend ist, ob die für v2 definierten Voraussetzungen selbst korrekt aufgelöst wurden.

29

v2 ist nicht automatisch SEAL-fähig

RESIDUAL RISK — SUFFICIENTLY CHARACTERISED

TOLERANCE RELATION — KNOWN

ACCEPTANCE AUTHORITY — BOUND

ACCEPTANCE RATIONALE — BOUND

VALIDITY PERIOD — BOUND

MONITORING CONDITIONS — BOUND

FURTHER TREATMENT OWNER — BOUND

REVIEW DATE — BOUND

CHANGE TRIGGERS — BOUND

BLOCKING OBJECTIONS — NONE

Ein Conditional-Acceptance-Candidate ist kein Shortcut. Er erzeugt eigene Voraussetzungen.

VI / SPÄTERE PRÜFUNG

Bei T1 muss die Organisation erklären können, ob Risk State und ursprüngliche Acceptance-Begründung noch gelten

30

Ein akzeptierter Residual Risk ist kein permanenter Endzustand

Die RTS verlangen bei akzeptierten Residual ICT Risks mindestens einmal jährlich eine Review. Dabei muss unter anderem geprüft werden, ob sich der Residual ICT Risk verändert hat, welche weiteren Mitigation Measures verfügbar sind und ob die ursprünglichen Gründe für seine Acceptance weiterhin gültig und anwendbar sind.

Primärquelle: Delegierte Verordnung (EU) 2024/1774

Ein bei T0 akzeptierter Residual Risk ist bei T1 nicht automatisch weiterhin akzeptabel.

31

Changes können den ursprünglichen Decision State verändern

Änderung

Neuer Peak-Load Test

Mögliche Folge

Evidence State verändert sich

Änderung

Major ICT Incident

Mögliche Folge

Risk State verändert sich

Änderung

Höheres Payment Volume

Mögliche Folge

Annahmen können entfallen

Änderung

Neue Screening Architecture

Mögliche Folge

Treatment State verändert sich

Änderung

Neue technische Dependency

Mögliche Folge

Risk Scope verändert sich

Änderung

Neue Mitigation Option

Mögliche Folge

Acceptance Rationale kann neu bewertet werden

Änderung

Veränderte Risk Tolerance

Mögliche Folge

Tolerance Relation verändert sich

Änderung

Audit Finding

Mögliche Folge

Review kann erforderlich werden

Änderung

Acceptance Expiry

Mögliche Folge

Neuer Decision State erforderlich

Acceptance darf sich nicht still verlängern.

32

Zwölf Monate später zählt nicht nur, ob ein Failover-Test existierte

Stellen wir uns vor, zwölf Monate nach einer späteren Acceptance tritt ein schwerwiegender regionaler Infrastructure Failure auf. Damit ist noch nichts darüber gesagt, ob frühere Entscheidungen falsch waren oder den späteren Vorfall verursacht haben. Aber die Organisation kann mit einer anderen Klasse von Review-Fragen konfrontiert werden.

  • 01Risk — welcher Residual ICT Risk war tatsächlich bekannt?
  • 02Evidence — welche Treatment-Effectiveness-Evidence lag bei T0 vor?
  • 03Uncertainty — welche Unsicherheiten blieben offen?
  • 04Tolerance — wie war der Risk State zur damals anwendbaren Risk Tolerance eingeordnet?
  • 05Assumptions — welche Annahmen trugen die Acceptance?
  • 06Alternatives — welche anderen Treatment- oder Operating-Optionen wurden betrachtet?
  • 07Responsibility — wer verantwortete Treatment Implementation, Effectiveness Assessment und Residual-Risk Assessment?
  • 08Authority — wer durfte den verbleibenden Risk State akzeptieren?
  • 09Rationale — warum wurde diese Acceptance ausgeübt?
  • 10Conditions — welche Gültigkeits-, Monitoring- und Treatment-Bedingungen galten?
  • 11Review — wurde die Acceptance entsprechend ihrer Bedingungen neu bewertet?
  • 12Change — war der bei T1 bestehende Risk State noch derselbe wie bei T0?

Welcher geregelte Risk-Treatment Decision State bestand tatsächlich zu T0 – und galt dieser Zustand bei T1 noch?

33

Ein Risk Register allein beantwortet diese Frage nicht

Risk Register

Risk ID

Decision State

konkreter Risk Scope

Risk Register

Score

Decision State

Evidence hinter der Bewertung

Risk Register

Treatment

Decision State

nachgewiesene Effectiveness

Risk Register

Owner

Decision State

Responsibility je State

Risk Register

Residual Risk

Decision State

verbleibende Uncertainty

Risk Register

Accepted

Decision State

Authority + Rationale

Risk Register

Review Date

Decision State

Conditions + Trigger

Risk Register

Status

Decision State

gesamter geregelter Entscheidungszustand

Ein Risk Register hält den Risk Status fest. Ein Decision State bewahrt die Grundlage, auf der Verantwortung für diesen Risk State übernommen wurde.

34

Unterschiedliche spätere Leser benötigen unterschiedliche Sichten

Leser

Payment Business

Zentrale Frage

Welcher Operating Risk wurde bewusst getragen?

Leser

Technology

Zentrale Frage

Welche Measures waren tatsächlich implementiert?

Leser

Operational Resilience

Zentrale Frage

Welche Recovery Effectiveness war nachgewiesen?

Leser

ICT Risk

Zentrale Frage

Welcher Residual-Risk-State wurde beurteilt?

Leser

Second Line / Control

Zentrale Frage

Welche Challenge und Conditions bestanden?

Leser

Internal Audit

Zentrale Frage

Wie entwickelte sich v1 → Blocker → SIMULATION → BRIDGE → v2?

Leser

Management / Oversight

Zentrale Frage

Auf welcher Grundlage wurde Verantwortung übernommen?

Leser

Autorisierter externer Reviewer

Zentrale Frage

Welche zulässige Sicht belegt den historischen State?

Wie spätere institutionelle Leser einen Decision State prüfen

35

Reale Authority bleibt außerhalb von Epistemis

  • 01Epistemis bestimmt nicht, welche Payment Function regulatorisch kritisch oder wichtig ist.
  • 02Epistemis bestimmt nicht, welche Risk Tolerance richtig ist.
  • 03Epistemis bestimmt nicht, ob der Recovery Test fachlich ausreichend ist.
  • 04Epistemis bewertet Residual ICT Risk nicht anstelle der zuständigen Funktion.
  • 05Epistemis wählt keine Mitigation.
  • 06Epistemis entscheidet nicht, ob eine Acceptance zulässig ist.
  • 07Epistemis bestimmt nicht, wer in einem konkreten Finanzunternehmen Acceptance Authority besitzt.
  • 08Epistemis zertifiziert keine DORA-Compliance.

DORA legt Governance-Verantwortung für ICT Risk fest und verlangt einen umfassenden ICT-Risk-Management-Framework. Die konkrete operative und organisatorische Authority bleibt jedoch beim Finanzunternehmen und seinen zuständigen Funktionen.

Primärquelle: Verordnung (EU) 2022/2554 — DORA

Epistemis bewahrt, welche Authority für welchen State zuständig war und auf welcher geregelten Entscheidungsgrundlage sie gehandelt hat.

36

Warum dieser Case über klassisches DORA-Dokumentationsmanagement hinausgeht

Finanzunternehmen besitzen bereits Risk Registers, Governance Policies, Asset Inventories, CMDBs, Architecture Documentation, Test Management, Incident Management, Business Continuity Management, Operational-Resilience-Prozesse, Audit Logs und Approval Workflows. Epistemis ersetzt diese Systeme nicht.

Das Problem liegt eine Ebene darüber: Wie werden die für eine konkrete Risk Decision relevanten Anforderungen, Treatment Measures, Nachweise, Effectiveness States, Unsicherheiten, Restrisiken, Alternativen, Verantwortlichkeiten und Authorities zu einem Zustand verbunden, der bei T0 verstanden und bei T1 rekonstruiert werden kann?

37

Der vollständige Epistemis-Mechanismus in vier Sätzen

  • 01Ein Blocker beschreibt, warum der aktuelle Risk-Treatment Decision Space nicht schließen kann.
  • 02SIMULATION untersucht entweder, was zur Auflösung dieses bestehenden Spaces fehlt, oder welche andere regelgebundene Risk Decision möglich wäre.
  • 03BRIDGE prüft, welche Requirements, Evidence, Risk States, Unsicherheiten, Rollen, Authorities und Conditions aus Exploration wieder in einen geregelten Decision Space überführt werden dürfen.
  • 04SEAL hält nur den Zustand fest, dessen für diesen Decision Space erforderliche Voraussetzungen aufgelöst sind und in dem keine blockierenden States offen bleiben.

Das ist keine DORA-Compliance-Checkliste. Es ist Infrastruktur für den Zustand einer konkreten Risk Decision.

QUELLEN / METHODE

Quellen- und Methodenhinweis

Reale regulatorische Grundlage

Die regulatorische Grundlage dieses Dossiers bilden die Verordnung (EU) 2022/2554 (DORA) und die Delegierte Verordnung (EU) 2024/1774. DORA liefert Governance-, ICT-Risk-Management- und Risk-Tolerance-Kontext. Die Delegierte Verordnung liefert die Treatment-, Effectiveness-, Residual-Risk-, Acceptance- und Review-Logik dieses Dossiers.

Primärquelle: Verordnung (EU) 2022/2554 — DORAPrimärquelle: Delegierte Verordnung (EU) 2024/1774

Illustratives Szenario

Die Universalbank, Core Payment Hub, Payment Execution Function, konkrete Systemarchitektur, das Regional-Outage-Szenario, das Multi-Region-Resilience-Programm, der Payment-Screening-Bottleneck, konkrete Test States, interne Rollen, Alternativen und die angenommene Acceptance-Struktur sind illustrativ. Sie beschreiben keine reale Bank, keinen realen Kunden, keinen realen DORA-Finding- oder Supervisory-Prozess.

Epistemis-Modellierung

Decision Space, Decision State, Blocker, SIMULATION, BRIDGE, SEAL, v1/v2 und Evidence-Pack-Sichten sind Epistemis-Konzepte. Sie sind keine Begriffe aus DORA oder der Delegierten Verordnung (EU) 2024/1774.

Welche IKT-Risikoentscheidung müsste Ihre Organisation später erklären können?

Ein Enterprise Pilot beginnt mit einer klar abgegrenzten haftungsrelevanten Risk Decision und bestimmt Risk Scope, Risk Tolerance, Treatment Measures, Evidence, Effectiveness State, Residual Risk, Unsicherheit, Alternativen, verantwortliche Rollen, Authority-Grenzen, Review Conditions und spätere Lesersichten.

Diesen Decision Space im Enterprise Pilot besprechenWeitere Anwendungsfälle ansehen