What must be resolved before ICT risk treatment can be closed?

DORA separates treatment, effectiveness and residual risk

What actually forms the risk-treatment Decision State

Treatment effectiveness needs an authorised risk-tolerance boundary

The treatment measures are largely implemented

• 01Secondary Processing Region — geographically separate processing environment available.
• 02Transaction-State Protection — accepted payment instructions and relevant processing state are replicated.
• 03Recovery Orchestration — recovery steps are standardised and partially automated.
• 04Network Resilience — required connectivity paths to the secondary environment are prepared.
• 05Monitoring — recovery state, processing backlog and material dependencies are observable.
• 06Recovery Procedures — runbooks, escalation and fallback procedures exist.
• 07End-to-End Testing — the complete Payment Execution Function can be tested under failover conditions.

The existence of a test does not prove every decision-relevant claim

Implementation and effectiveness are different states

Treatment creates a different residual risk state

A known residual risk can still contain material uncertainty

Assumptions must not silently become facts

• 01The secondary region remains sufficiently independent.
• 02Payment Screening remains available on the recovery path.
• 03Screening capacity does not deteriorate further.
• 04Payment mix remains within defined bounds.
• 05Recovery personnel remain available.
• 06Monitoring functions reliably.
• 07Backlog growth remains bounded.
• 08Downstream clearing interfaces remain reachable.

The Decision Space contains more than close or do not close

Treatment owner, risk assessor and acceptance authority are not the same role

Authority is itself a state

Different professional positions are part of the Decision State

• 01Payment Platform — the agreed architecture measures have been implemented.
• 02Operational Resilience — standard-load recovery is demonstrated; peak-load end-to-end recovery does not yet meet the required boundary.
• 03ICT Risk — the residual risk is identified, but its full magnitude is not yet sufficiently characterised.
• 04Business Function Owner — leaving the resilience state indefinitely open creates operational and strategic cost of its own.
• 05Independent Risk / Control — acceptance must not cause an incompletely evidenced treatment state to be represented as remediated.

Decision Space v1 is now fully visible

Path A has no predetermined outcome

Path B: Remodel the Decision Space

A conditional-acceptance candidate creates a new Decision Space

Acceptance changes several states at once

Accepted does not mean remediated

BRIDGE examines whether the new candidate may return into a governed Decision Space

• 01Classification — is the new decision Residual-Risk Acceptance rather than Treatment Closure?
• 02Evidence Inheritance — which evidence from v1 remains valid for v2?
• 03Residual Risk — is the remaining risk state sufficiently characterised?
• 04Risk Tolerance — is its relationship to the applicable tolerance explicit?
• 05Assumptions — which assumptions remain valid and which new assumptions arise?
• 06Authority — who has authority over this exact acceptance decision?
• 07Conditions — are duration, monitoring, escalation and review unambiguous?
• 08Open Treatment — which treatment work remains unresolved?
• 09Objections — which professional objections remain?
• 10Blockers — does any open state still prevent the acceptance decision?

Decision Space v2 receives its own complete state

v2 is not automatically eligible for SEAL

Changes can alter the original Decision State

Twelve months later, the relevant question is not merely whether a failover test existed

• 01Risk — which residual ICT risk was actually known?
• 02Evidence — which treatment-effectiveness evidence existed at T0?
• 03Uncertainty — which uncertainties remained open?
• 04Tolerance — how was the risk state related to the applicable risk tolerance?
• 05Assumptions — which assumptions supported the acceptance?
• 06Alternatives — which other treatment or operating options were considered?
• 07Responsibility — who was responsible for treatment implementation, effectiveness assessment and residual-risk assessment?
• 08Authority — who was authorised to accept the remaining risk state?
• 09Rationale — why was that acceptance exercised?
• 10Conditions — which validity, monitoring and treatment conditions applied?
• 11Review — was the acceptance reassessed in accordance with its conditions?
• 12Change — was the risk state at T1 still the same state that existed at T0?

A risk register alone cannot answer that question

Different later readers need different views of the same state

Real authority remains outside Epistemis

• 01Epistemis does not determine which payment function is legally critical or important.
• 02Epistemis does not set the appropriate risk tolerance.
• 03Epistemis does not determine whether a recovery test is professionally sufficient.
• 04Epistemis does not assess residual ICT risk in place of the competent function.
• 05Epistemis does not select the mitigation.
• 06Epistemis does not determine whether acceptance is permitted.
• 07Epistemis does not determine who holds acceptance authority in a particular financial entity.
• 08Epistemis does not certify DORA compliance.

Why this case goes beyond conventional DORA documentation management

The full Epistemis mechanism in four statements

• 01A blocker explains why the current risk-treatment Decision Space cannot close.
• 02SIMULATION examines either what is missing to resolve that existing Space or what would change if a different rule-bound risk decision were considered.
• 03BRIDGE examines which requirements, evidence, risk states, uncertainties, roles, authorities and conditions from exploration may return into a governed Decision Space.
• 04SEAL binds only a state in which the prerequisites defined for that Decision Space have been resolved and no blocking states remain open.