Language:
PRODUCTS
SECTORS
MORE
Quantum Security 🔍 Search Request Access →
gateDORA — Digital Operational Resilience Gate
// The problem

A third-party outage today hits the entire chain.

DORA requires seamless control over ICT third-party providers, from the register duty to concentration risk review. gateDORA checks all six clusters before every onboarding, not only at the next audit.

Board responsibility becomes a sealed fact
DORA explicitly anchors ultimate responsibility for ICT risk with the management body. The gate seals the approval decision with a timestamp and risk acceptance.
// Architecture

6 clusters, checked sequentially.

Every cluster is dispositive (material_block_mode: true), a hit blocks bindingly, not merely for documentation.

CLUSTER 1
ICT Risk Management
Checks whether a documented ICT risk management framework with asset and threat analysis exists.
ict_framework_documented · risk_scoring_current
CLUSTER 2
Incident Reporting
Checks the classification of a major ICT incident and timely reporting to the competent authority.
incident_classified_major · reported_within_deadline
CLUSTER 3
Threat-Led Penetration Testing (TLPT)
Checks, for critical functions, whether TLPT has been performed within the mandated three-year cycle.
tlpt_required · tlpt_completed_within_cycle
CLUSTER 4
Third-Party Register
Checks whether the provider is fully recorded in the register of information on ICT third-party providers.
register_entry_complete
CLUSTER 5
Subcontracting Consent
Checks whether the provider's subcontracting relationships have been disclosed and approved by the financial entity.
subcontracting_disclosed · consent_obtained
CLUSTER 6
Concentration Risk
Checks dependency on a single critical ICT provider against the internal concentration-risk threshold.
concentration_risk_score · threshold_exceeded
No case, no doubt
Every cluster returns its own sealed result. A single hit in an active cluster is enough to block the overall action.
// Test results

Two tested scenarios.

All values on this page are fictional test data and serve only to illustrate the gate logic.

Scenario C1C2C3C4C5C6 Verdict Latency
Cloud provider, TLPT current, register complete, concentration risk lowPASSPASSPASSPASSPASSPASSDORA_SEALED478ms
Critical ICT provider without register entryPASSPASSPASSFAILnot evaluatednot evaluatedBLOCK_DR4_REGISTER_ENTRY_MISSING401ms
Cryptographic chain continuation
Every test produces a deterministic receipt_id, an input_snapshot_hash, an HMAC-SHA256 signature, and a merkle_link to the previous receipt. Persistence occurs in the gateDORAReceipt entity with a 10-year retention period.
// Clarification

What gateDORA is not.

  • Not automatic recognition by a European supervisory authority. The gate delivers a cryptographic proof, not regulatory approval.
  • Not an independent ICT security system. The gate seals the onboarding check, it does not replace ongoing technical monitoring.

For financial entities that want to make ICT third-party onboarding provable.

GATE CATALOG · REGULATORY DETERMINATION DOMAIN

gateDORA

gateDORA determines encoded digital-operational-resilience, ICT, third-party, incident and control conditions. The gate contributes a bound regulatory determination state; it creates neither regulatory authority nor Execution Permission.

DOMAIN_DETERMINATION_ONLY = true · EXECUTION_AUTHORITY = false · EXECUTION_PERMISSION = false
gateDORA regulatory determination domain
AUTHORITY BOUNDARY

DORA STATE IS NOT SUPERVISORY AUTHORITY.

CAN

  • deterministically evaluate encoded regulatory conditions
  • bind determinations to source, scope, time and input state
  • surface missing, expired or conflicting regulatory dependencies
  • produce attributable evidence for the concrete determination

CANNOT

  • replace a regulator, supervisor, court or competent institution
  • create legal or regulatory authority through score, consensus, AI or administration
  • turn a gate PASS into an Execution Right on its own
  • mint an ExecutionCapabilityToken on its own
REGULATORY STATE

Regulatory determination is evidence. Not regulatory authority.

SOURCE

Authoritative source

The relevant rule must originate outside the system from a legitimate normative or institutional source.

SCOPE

Defined matter

The determination is limited to the encoded subject, entity, transaction or operation under review.

TIME

Point-in-time state

Effective dates, transition periods, expiry and version state remain explicit.

INPUT

Canonical input

A reproducible determination requires a defined canonical input state.

DEPENDENCY

Dependencies

Missing or contradictory dependencies remain visible rather than being converted into invented permission.

EVIDENCE

Bound evidence

The resulting state can be bound to source, input, scope and time for later verification.

RELATED DETERMINATION DOMAINS

Regulatory domains compose. They do not confer authority on one another.

Only scope-relevant determinations become dependencies in Execution Rights resolution. The links shown are not a universally mandatory sequence.

EXECUTION RIGHTS

Five dimensions. Regulatory state can inform them; no gate replaces them.

AAUTHORITY
RRULE
JJURISDICTION
TTIME
DDEPENDENCY
ALL FIVE REQUIRED DIMENSIONS VALID → VALID EXECUTION RIGHT · ANY REQUIRED DIMENSION ABSENT → NO VALID EXECUTION RIGHT → NO CAPABILITY → NO EXECUTION
INVARIANT

A regulatory PASS is a determination. Never a permission by itself.

AUTHORITY → DETERMINATION → EXECUTION RIGHTS → CAPABILITY OR NONE → EXECUTION OR NONE → EVIDENCE

Request Access →