Sprache:
PRODUKTE
SEKTOREN
MEHR
Quantum Security 🔍 Suche Zugang anfragen →
gateDORA — Digital Operational Resilience Gate
// Das Problem

Ein Drittanbieter-Ausfall trifft heute die ganze Kette.

DORA verlangt lückenlose Kontrolle über IKT-Drittanbieter, von der Registerpflicht bis zur Konzentrationsrisikoprüfung. gateDORA prüft alle sechs Cluster vor jedem Onboarding, nicht erst beim nächsten Audit.

Vorstandsverantwortung wird zur versiegelten Tatsache
DORA verankert die Endverantwortung für IKT-Risiko ausdrücklich beim Leitungsorgan. Das Gate versiegelt die Freigabeentscheidung mit Zeitstempel und Risikoakzeptanz.
// Architektur

6 Cluster, sequenziell geprüft.

Jeder Cluster ist dispositiv (material_block_mode: true), ein Treffer blockiert bindend, nicht nur zur Dokumentation.

CLUSTER 1
IKT-Risikomanagement
Prüft, ob ein dokumentiertes IKT-Risikomanagementrahmenwerk mit Asset- und Bedrohungsanalyse vorliegt.
ict_framework_documented · risk_scoring_current
CLUSTER 2
Vorfallmeldung
Prüft die Klassifizierung eines schwerwiegenden IKT-Vorfalls und die fristgerechte Meldung an die zuständige Behörde.
incident_classified_major · reported_within_deadline
CLUSTER 3
Bedrohungsorientierte Penetrationstests (TLPT)
Prüft bei kritischen Funktionen, ob ein TLPT innerhalb des vorgeschriebenen Drei-Jahres-Zyklus durchgeführt wurde.
tlpt_required · tlpt_completed_within_cycle
CLUSTER 4
Drittparteienregister
Prüft, ob der Anbieter im Informationsregister für IKT-Drittdienstleister vollständig erfasst ist.
register_entry_complete
CLUSTER 5
Auslagerungszustimmung
Prüft, ob Unterauftragsverhältnisse des Anbieters offengelegt und vom Finanzunternehmen genehmigt wurden.
subcontracting_disclosed · consent_obtained
CLUSTER 6
Konzentrationsrisiko
Prüft die Abhängigkeit von einem einzelnen kritischen IKT-Anbieter gegen den internen Konzentrationsrisiko-Schwellenwert.
concentration_risk_score · threshold_exceeded
Kein Fall, kein Zweifel
Jedes Cluster liefert ein eigenes, versiegeltes Ergebnis. Ein Treffer in einem aktiven Cluster reicht, um den Gesamtvorgang zu blockieren.
// Testergebnisse

Zwei getestete Szenarien.

Alle Werte auf dieser Seite sind fiktive Testdaten und dienen ausschließlich der Illustration der Gate-Logik.

Szenario C1C2C3C4C5C6 Verdict Latenz
Cloud-Anbieter, TLPT aktuell, Register vollständig, Konzentrationsrisiko niedrigPASSPASSPASSPASSPASSPASSDORA_SEALED478ms
Kritischer IKT-Anbieter ohne RegistereintragPASSPASSPASSFAILnot evaluatednot evaluatedBLOCK_DR4_REGISTER_ENTRY_MISSING401ms
Kryptografische Kettenfortschreibung
Jeder Test erzeugt eine deterministische receipt_id, einen input_snapshot_hash, eine HMAC-SHA256-Signatur und einen merkle_link zur vorherigen Receipt. Persistenz erfolgt in der gateDORAReceipt-Entity mit 10 Jahren Aufbewahrungsfrist.
// Klarstellung

Was gateDORA nicht ist.

  • Keine automatische Anerkennung durch eine europäische Aufsichtsbehörde. Das Gate liefert einen kryptografischen Beweis, keine behördliche Zulassung.
  • Kein eigenständiges IKT-Sicherheitssystem. Das Gate versiegelt die Onboarding-Prüfung, es ersetzt keine laufende technische Überwachung.

Für Finanzunternehmen, die IKT-Drittanbieter-Onboarding belegbar machen wollen.

GATE CATALOG · REGULATORY DETERMINATION DOMAIN

gateDORA

gateDORA bestimmt kodierte regulatorische Bedingungen für einen definierten Sachverhalt. Das Gate liefert einen gebundenen regulatorischen Determination State; es erzeugt weder regulatorische Authority noch Execution Permission.

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

DORA-ZUSTAND IST KEINE AUFSICHTSAUTORITÄT.

KANN

  • kodierte regulatorische Bedingungen deterministisch bestimmen
  • Determinations an Quelle, Scope, Zeit und Input-State binden
  • fehlende, abgelaufene oder kollidierende regulatorische Dependencies sichtbar machen
  • zurechenbare Evidence für die konkrete Determination erzeugen

KANN NICHT

  • Regulator, Aufsicht, Gericht oder zuständige Institution ersetzen
  • rechtliche oder regulatorische Authority durch Score, Konsens, KI oder Administration erzeugen
  • aus einem Gate-PASS eigenständig ein Execution Right erzeugen
  • eigenständig einen ExecutionCapabilityToken erzeugen
REGULATORY STATE

Regulatorische Determination ist Evidence. Keine regulatorische Authority.

SOURCE

Authoritative source

Die relevante Regel muss außerhalb des Systems aus einer legitimen normativen oder institutionellen Quelle stammen.

SCOPE

Definierter Sachverhalt

Die Determination ist auf den kodierten Sachverhalt, die Einheit, Transaktion oder Operation begrenzt.

TIME

Zeitpunktbezogener Zustand

Geltungsbeginn, Übergangsfristen, Außerkrafttreten und Versionsstand bleiben explizit.

INPUT

Kanonischer Input

Eine reproduzierbare Determination benötigt einen definierten kanonischen Input-State.

DEPENDENCY

Dependencies

Fehlende oder widersprüchliche Dependencies bleiben sichtbar, statt in erfundene Permission umgewandelt zu werden.

EVIDENCE

Gebundener Nachweis

Der resultierende State kann für spätere Verifikation an Quelle, Input, Scope und Zeit gebunden werden.

VERWANDTE DETERMINATION DOMAINS

Regulatorische Domains werden komponiert. Sie verleihen einander keine Authority.

Nur scope-relevante Determinations werden Dependencies der Execution-Rights-Auflösung. Die gezeigten Links sind keine universell zwingende Sequenz.

EXECUTION RIGHTS

Fünf Dimensionen. Regulatorischer State kann sie informieren; kein Gate ersetzt sie.

AAUTHORITY
RRULE
JJURISDICTION
TTIME
DDEPENDENCY
ALLE FÜNF ERFORDERLICHEN DIMENSIONEN GÜLTIG → GÜLTIGES EXECUTION RIGHT · EINE ERFORDERLICHE DIMENSION FEHLT → KEIN GÜLTIGES EXECUTION RIGHT → KEINE CAPABILITY → KEINE AUSFÜHRUNG
INVARIANT

Ein regulatorischer PASS ist eine Determination. Niemals allein eine Permission.

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

Zugang anfragen →