DORA is the domain. EVE governance signals are the reusable verification layer.
The Digital Operational Resilience Act (DORA) establishes requirements across ICT risk management, incident reporting, third-party risk, and operational resilience testing. EVE does not implement DORA compliance. EVE provides a set of deterministic governance signals — each following the same pattern: a declared rule, observed activity, deterministic evaluation, human review gate, and a sealed, cryptographically verifiable decision record.

The five signals built in the TPRM context apply to DORA-relevant governance questions without modification to the signal model. The domain changes. The verification pattern does not.
Illustrative source-mapping only. Article references below are indicative of the governance area each signal addresses. They are not a legal interpretation of DORA, not a compliance certification, and not legal advice. EVE does not assess materiality. Human review and professional judgement remain required for all DORA obligations.
The same verification pattern — applied to DORA governance
1
Declared rule
2
Observed activity
3
Deterministic evaluation
4
Human review
5
Sealed decision record
6
Public verification
1
Authority Boundary
Did the ICT action stay within the declared authority of the responsible function or delegated owner?
Live · v0 DORA mapping
What it evaluates
Whether an action taken by an actor exceeded the declared authority limit for that actor, action type, and context. Each limit is declared by the organisation; EVE compares the observed action to the declared threshold. Verdict is breach if exceeded, pass if within, unknown if the actor, action, or limit cannot be placed (fail-closed — never treated as pass).
DORA governance area
ICT risk management governance / delegated control ownership. DORA requires management bodies to define, approve and oversee ICT risk management arrangements and to maintain clear accountability for ICT-related decisions. The Authority Boundary signal surfaces whether an observed ICT action was within the declared authority of the responsible function.
Art 5 Management body responsibilities Art 6 ICT risk management framework
Output verdicts
breach pass unknown
unknown → actor, action, or limit unresolvable. Never a pass.
Domain proof — sealed on EVE Bridge
EVE-DORA-00004289 breach / authority_limit_exceeded → ICT change at impact level 5 above declared authority (limit 3) · Human decision: reject Verify publicly →
Synthetic DORA demo proof — shows the Authority Boundary mechanism in a DORA context. Not a real DORA finding or enforcement action.
2
Approval Chain
Was the declared approval chain satisfied before the ICT change, risk acceptance, or incident escalation?
Live · v0 DORA mapping
What it evaluates
Whether a declared sequence of approvals was satisfied — in order, by the declared approver identities, and before the associated action occurred. Missing approver identity, wrong order, or approval recorded after the action produces unknown or breach respectively. The chain is declared by the organisation; EVE verifies against it.
DORA governance area
Incident escalation, change approval, and risk acceptance workflows. DORA requires documented processes for classifying and escalating ICT-related incidents, and for managing ICT changes through approved workflows. The Approval Chain signal surfaces whether the declared escalation or change-approval sequence was followed before the associated action was recorded.
Art 11 Response and recovery Art 17 ICT-related incident classification Art 18 Reporting of major ICT-related incidents
Output verdicts
breach pass unknown
unknown → missing approval evidence or identity. Never a pass.
Domain proof — sealed on EVE Bridge
EVE-DORA-00004290 breach / approval_after_action → ciso_gate recorded after the ICT change was applied · Human decision: reject Verify publicly →
Synthetic DORA demo proof — shows the Approval Chain mechanism in a DORA context. Not a real DORA finding or enforcement action.
3
Overlapping Boundaries
Did all applicable ICT controls evaluate against this event or vendor — and did any fail?
Live · v0 DORA mapping
What it evaluates
A composition layer: each action or event carries the set of declared controls that apply to it. EVE verifies coverage (every applicable boundary was evaluated) and composes the verdicts. Propagation order: breach > unknown > pass. One failing control is enough for a breach, even if all others pass. Missing evaluation produces unknown, which propagates upward.
DORA governance area
Multiple ICT controls applying to the same event, vendor, or system. DORA requires financial entities to maintain a comprehensive ICT risk management framework with multiple intersecting control layers across risk identification, protection, detection, and response. The Overlapping Boundaries signal surfaces whether all controls declared applicable to an event were evaluated and whether any produced a finding.
Art 8 Identification Art 9 Protection and prevention Art 10 Detection Art 28 ICT third-party risk management
Output verdicts
breach pass unknown
unknown propagates upward from any unevaluated boundary.
Domain proof — sealed on EVE Bridge
EVE-DORA-00004291 breach / applicable_boundary_failed → subcontractor_check failed (concentration + exit_plan passed) · Human decision: reject Verify publicly →
Synthetic DORA demo proof — shows the Overlapping Boundaries mechanism in a DORA context. Not a real DORA finding or enforcement action.
4
Collective Outcome
Did individually acceptable ICT or vendor events produce an unacceptable combined operational risk outcome within a declared window?
Live · v0 DORA mapping
What it evaluates
The first cross-action layer: within one declared window, EVE groups events by a declared key, sums a declared field, and compares the aggregate to a declared collective limit. Each individual event may be below its own limit — the breach is collective. Groups are evaluated independently. Missing window, group key, or numeric value produces unknown for that group.
DORA governance area
ICT concentration risk and combined operational risk from multiple vendor or ICT events. DORA requires financial entities to assess ICT concentration risk at entity and group level, and to identify risks arising from multiple ICT third-party dependencies. The Collective Outcome signal surfaces whether individually acceptable events sum to a collectively unacceptable outcome within a declared window.
Art 26 Preliminary assessment of ICT concentration risk Art 28 General principles of ICT third-party risk management
Output verdicts (per group)
breach pass unknown
breach when aggregate > limit. Equal to limit = pass.
Domain proof — sealed on EVE Bridge
EVE-DORA-00004292 breach / collective_limit_exceeded → payments_processing dependencies 40+35+30=105 > limit 100 · Human decision: reject Verify publicly →
Synthetic DORA demo proof — shows the Collective Outcome mechanism in a DORA context. Not a real DORA finding or enforcement action.
5
Accumulation Risk
Did repeated minor ICT or vendor incidents accumulate beyond a declared threshold over a rolling window?
Live · v0 DORA mapping
What it evaluates
A rolling-window cumulative layer: EVE sums a declared field for a declared group-by key over a declared window anchored to a declared as_of reference point (never wall-clock time). A single event may be below any individual threshold while the rolling sum constitutes a breach. Out-of-window events are excluded. Events with unresolvable timestamps or group keys produce unknown (fail-closed).
DORA governance area
Repeated minor ICT incidents, control gaps, and vendor performance degradation accumulating over time. DORA requires financial entities to monitor and manage ICT-related risks on a continuous basis, including the cumulative effect of minor incidents and recurring ICT third-party control gaps. The Accumulation Risk signal surfaces whether individually sub-threshold incidents or exposures have accumulated beyond a declared rolling limit.
Art 6 ICT risk management framework Art 11 Response and recovery Art 30 Key contractual provisions / exit strategies
Output verdicts (per group)
breach pass unknown
unknown: unresolvable timestamp, group key, or non-numeric value.
Domain proof — sealed on EVE Bridge
EVE-DORA-00004287 breach / accumulation_limit_exceeded → cumulative ICT/vendor exposure 105 000 > limit 100 000 over 90-day window · no single-event breach · Human decision: reject Verify publicly →
Synthetic DORA demo proof — shows the Accumulation Risk mechanism in a DORA context. Not a real DORA finding or enforcement action.
Illustrative source-mapping — not a compliance statement
The DORA article references on this page are indicative only. They identify the governance area each EVE signal addresses in a DORA context. They are not a legal interpretation of DORA obligations, not a gap assessment, and not legal advice.

All sealed EVE-IDs linked on this page were produced against synthetic TPRM fixture data and are labelled accordingly. They demonstrate the verification mechanism — not DORA-specific findings. No customer, partner or production data is used or exposed anywhere on this page.

EVE does not certify DORA compliance. EVE does not assess materiality. EVE does not replace auditors, legal counsel, or competent authority review. Human review remains required for all DORA obligations.