Sie bauen Ihren eigenen Agenten für die Incident-Behebung?

→

Sie bauen Ihren eigenen Agenten für die Incident-Behebung?

→

Worauf Sie dabei achten sollten.

Sie bauen Ihren eigenen Agenten für die Incident-Behebung?

→

Worauf Sie dabei achten sollten.

NIS2 und DORA

Wissen, was Sie für NIS2 und DORA schon belegen können

Kein einzelnes Werkzeug macht Sie compliant. Hyground zeigt und dokumentiert fortlaufend die Teile beider Regelwerke, die in Ihrem Stack liegen: Incident-Bearbeitung, Risikoanalyse, Transparenz über Assets und Lieferkette sowie Zugriffssteuerung. Nur lesend, im eigenen Perimeter.

Whitepaper lesen

Deep Dive buchen

NIS2 und DORA

Wissen, was Sie für NIS2 und DORA schon belegen können

Whitepaper lesen

Deep Dive buchen

NIS2 und DORA

Wissen, was Sie für NIS2 und DORA schon belegen können

Whitepaper lesen

Deep Dive buchen

Abdeckung

Was Hyground belegen kann, Maßnahme für Maßnahme

NIS2 Artikel 21 nennt zehn Sicherheitsmaßnahmen, und die Säulen von DORA laufen auf denselben operativen Kern hinaus. Unten steht, welche Hyground aus dem laufenden Systemzustand belegt, welche es teilweise unterstützt und welche zu anderen Werkzeugen gehören.

Maßnahme nach NIS2 Artikel 21(2)

Abdeckung durch Hyground

Was Sie bekommen

Entspricht in DORA

(a) Risikoanalyse und Sicherheitsrichtlinien

Vollständig

FMEA-Risikoanalyse: bewertete Fehlermatrix, Fehlerbaum, Bericht; Asset-Inventar bei Bedarf

Säule 1: IKT-Risikomanagement

(b) Incident-Bearbeitung

Vollständig

Automatische Root-Cause-Analyse; ein zeitgestempelter, prüfbarer Session-Nachweis je Incident

Säule 2: Incident-Management

Keine

Nicht Hyground: Ihre Backup- und Recovery-Werkzeuge

Säule 1: IKT-Risikomanagement

(d) Sicherheit der Lieferkette

Vollständig

Stackübergreifende Erfassung von Abhängigkeiten und Assets; welche laufenden Services ein verwundbares Paket nutzen

Säule 4: Drittparteienrisiko

(e) Sichere Entwicklung und Schwachstellenbehandlung

Teilweise

Prüfungen von Exposition und Konfiguration an laufenden Services

Säulen 1 und 3

(f) Bewertung der Wirksamkeit von Maßnahmen

Vollständig

Geplante Untersuchungen in fester Taktung; herunterladbare Berichte, dass die Prüfungen liefen

Säule 3: Resilienztests

(g) Grundlegende Cyberhygiene und Schulung

Keine

Nicht Hyground: Ihr Awareness-Programm

Säule 1: IKT-Risikomanagement

(h) Kryptografie und Verschlüsselung

Keine

Nicht Hyground: Ihr Schlüsselmanagement und Ihre Verschlüsselung

Säule 1: IKT-Risikomanagement

(i) Zugriffssteuerung und Asset-Management

Vollständig

Nur lesende Adapter, kurzlebige Tokens je Umgebung, vollständiger Audit-Trail der Interaktionen; Asset-Inventar bei Bedarf

Säule 1: IKT-Risikomanagement

(j) Mehrfaktor-Authentifizierung und sichere Kommunikation

Keine

Nicht Hyground: Ihr Identity Provider und Ihre Kommunikation

Säule 1: IKT-Risikomanagement

Scrollen für die vollständige Tabelle

So funktioniert's

Die Fähigkeiten hinter der Matrix

Jede Zeile oben lässt sich auf etwas zurückführen, das heute ausgeliefert wird. Das sind die fünf Fähigkeiten dahinter.

NIS2 21(2)(b) / DORA Säule 2

Incident-Bearbeitung

Die automatische Root-Cause-Analyse startet innerhalb von Minuten nach einem Alert und untersucht Observability, Cloud, Kubernetes, Code und Ticketing. Die strukturierte Diagnose speist Ihre Meldefrist – 24 Stunden nach NIS2 und 4 Stunden bei einem schweren DORA-Incident –, und jede Session ist ein zeitgestempelter, prüfbarer Incident-Nachweis. Fragt die Aufsicht, ob die Geschäftsleitung für wirksame Maßnahmen gesorgt hat, ist dieser Nachweis Ihr Beleg. Hyground empfiehlt, Ihre Engineers entscheiden.

NIS2 21(2)(a) / DORA Säule 1

Risikoanalyse und Asset-Inventar

Der Bereich FMEA-Risikoanalyse von Hyground wendet die Fehlermöglichkeits- und Einflussanalyse auf Ihren Stack an und erzeugt eine bewertete Fehlermatrix, einen Fehlerbaum und einen Bericht. Die stackübergreifende Erfassung der Assets über Kubernetes, AWS, Azure, Datenbanken und Observability liefert das Inventar darunter, bei Bedarf erstellt statt von Hand gepflegt. Geplante Läufe machen daraus etwas Fortlaufendes statt etwas Jährliches.

NIS2 21(2)(d)

Software-Stückliste

Eine CycloneDX-Software-Stückliste (SBOM), zu jedem Release veröffentlicht und für Kunden verfügbar, damit Ihre Lieferantenprüfung unsere Abhängigkeitskette nachvollziehen kann.

NIS2 21(2)(e)

Antworten zu Abhängigkeiten und Exposition in Echtzeit

Antworten aus Ihrem tatsächlichen Betriebszustand: welche Services ein verwundbares Paket nutzen, welche Abhängigkeiten seit dem letzten Release abgewichen sind und welche Services noch unauthentifizierten Verkehr annehmen.

NIS2 21(2)(i)

Zugriffssteuerung und Audit-Trail

Zugangsdaten liegen zentral am Gatekeeper, nicht verstreut auf Laptops. Adapter sind standardmäßig nur lesend und werden beim Start geprüft, Zugriffe werden je Umgebung zugeordnet und nutzen kurzlebige Tokens, und jede Interaktion zwischen Agent und System wird protokolliert. Die Kontrollarchitektur, die ein Einkaufsteam prüfen kann.

NIS2 21(2)(f) / DORA Säule 3

Wirksamkeits- und Drittparteienprüfungen

Geplante Untersuchungen führen Ihre Prüfungen in fester Taktung aus und erzeugen herunterladbare Berichte: der Beleg, dass Ihre Maßnahmen laufen, nicht nur dass sie aufgeschrieben sind. Dieselbe Beobachtung erstreckt sich auf Dritte – ob Service-Level-Objectives eingehalten werden, ob Datenflüsse dem Vertrag entsprechen und ob Komponenten abweichen, die jemand anderes betreibt.

Drittparteienrisiko

Der kleinste Drittparteien-Fußabdruck, den Sie in ein Register eintragen können

Hyground läuft in Ihrer Umgebung und liest, statt zu schreiben, Sie bleiben also Betreiber Ihrer eigenen Datenebene. Das hält den Papierkram zum Drittparteienrisiko kurz, und on-premises verschwindet er fast ganz.

Ihr Perimeter, Ihre Zugangsdaten

Adapter sind standardmäßig nur lesend und werden beim Start geprüft. Zugangsdaten liegen am Gatekeeper innerhalb Ihrer Umgebung und verlassen sie nie, und jede Interaktion zwischen Agent und System wird mit Zuordnung je Umgebung protokolliert.

Wo Ihr Modell läuft

In Ihrer eigenen Cloud kombinieren Sie Hyground mit einem verwalteten Modell in einer europäischen Region, etwa Amazon Bedrock oder Azure OpenAI, damit Prompts und Antworten in Ihrem Tenant bleiben. Wo Sie US-Anbieter ausschließen müssen, nutzen Sie einen europäischen Modellanbieter; on-premises mit einem lokalen Modell verlässt gar nichts Ihre Umgebung.

Bereit für Ihr DORA-Register

Für Ihr Informationsregister: Verarbeitungsort ist Ihr eigener Tenant, Austauschbarkeit über Standard-Kubernetes und modellunabhängig, Ausstieg in die eigene Infrastruktur und die eigenen Daten. Der einzige einzutragende Unterauftragsverarbeiter ist das Modell, das Sie anbinden, üblicherweise ein verwaltetes Modell in einer europäischen Region von AWS oder Azure; on-premises gibt es keinen.

Koordinierte Offenlegung von Schwachstellen

Melden Sie Sicherheitsprobleme an security@hyground.ai. Unsere schriftliche Offenlegungsrichtlinie nennt einen festen Ansprechpartner mit definierten Reaktions- und Triage-Zeiten.

Die ehrlichen Grenzen

Was Hyground nicht tut

Bei den Grenzen genau zu sein, gehört dazu, wenn man ein Lieferant sein will, den Sie ohne Fußnote in ein DORA-Register eintragen können. Hyground ist die Betriebsschicht; es ersetzt die Werkzeuge drumherum nicht, und es ist kein Zertifikat.

Kein SIEM, SOAR oder GRC-Werkzeug

Ihr SIEM (Security Information and Event Management) sammelt weiter, und Ihre Governance-Werkzeuge führen weiter das Register. Hyground sitzt darunter und beantwortet, was gerade tatsächlich im Stack gilt; es orchestriert keine Gegenmaßnahmen und übernimmt Ihre Kontrollen nicht.

Kein Backup, keine MFA, kein Scanner

Wir betreiben keine Backups oder Failover, stellen keine Mehrfaktor-Authentifizierung oder Identitätsverwaltung bereit und ersetzen weder Ihre Code- und Abhängigkeitsscanner noch Ihre Cloud-Posture-Werkzeuge. Wo diese in Ihr Programm gehören, behalten Sie sie.

Lesen zuerst, von Haus aus

Hyground untersucht und berichtet; es verändert Ihre Systeme nicht von sich aus. Schreibende Zugriffe beschränken sich auf Ticket-Kommentare, eine abgeschottete Shell und die eigene Knowledge Base. Begrenzte Gegenmaßnahmen stehen auf der Roadmap, wir behaupten sie heute nicht.

Zertifizierung läuft

Die ISO-27001-Zertifizierung läuft, und CycloneDX-Software-Stücklisten je Release sind bereits verfügbar. Wo Ihr Einkauf heute ein ausgestelltes Zertifikat braucht, sagen wir Ihnen genau, wo wir stehen, statt mehr anzudeuten.

Betrieb

Selbst gehostet, in der Stufe, die Ihre Pflicht verlangt

Hyground ist in jeder Stufe selbst gehostet, die von Ihnen gewählte Stufe ist also das Compliance-Argument, das Sie führen können.

Ihre Cloud

Hyground läuft in Ihrem eigenen AWS-, Azure- oder Google-Cloud-Tenant, und Ihre Zugangsdaten verlassen ihn nie. Kombiniert mit einem verwalteten Modell in einer europäischen Region, etwa Amazon Bedrock oder Azure OpenAI, bleiben die Prompts in Ihrem Tenant und das Bild nach DORA Artikel 30 bleibt sauber.

EU-souverän

EU-Cloud wie StackIt, Hetzner, IONOS oder OVHcloud, kombiniert mit einem Modell eines europäischen Anbieters, kein US-Anbieter im Weg. Die stärkste Aufstellung für DORA, NIS2 und Schrems II, und eine, auf die ein von der BaFin (deutsche Finanzaufsicht) beaufsichtigter Kunde verweisen kann.

On-premises, Air-Gap optional

Nichts verlässt Ihre Räumlichkeiten, und mit einem lokalen Modell gibt es überhaupt keinen Unterauftragsverarbeiter einzutragen. Die Stufe für Verteidigung, kritische Infrastruktur sowie eingestufte oder air-gapped Umgebungen.

Sie bleiben Betreiber

Hyground wird nach dem Prinzip Bring your own Chart ausgerollt und sendet keine Daten an uns zurück. Der Geltungsbereich der Informationssicherheit schließt Ihre Produktivumgebung, Ihre Modell-Accounts und Ihre Daten bewusst aus, damit die Datenebene Ihre bleibt.

Die Regeln, kurz gefasst

Zwei Regelwerke, zwei Meldefristen

Beide Regelwerke erreichen Softwareanbieter über deren Kunden: Kunden im Anwendungsbereich geben die Anforderungen die Lieferkette hinunter weiter (NIS2 Artikel 21(2)(d), DORA Artikel 30). Die Frist kann also bei Ihnen anlaufen, auch wenn Sie nicht unmittelbar betroffen sind.

NIS2

Richtlinie (EU) 2022/2555, eine horizontale Cybersicherheits-Grundlinie. Die Meldung erheblicher Incidents läuft im Takt von 24 Stunden, 72 Stunden und einem Monat, mit persönlicher Haftung der Geschäftsleitung. In Deutschland trat sie am 6. Dezember 2025 über das geänderte BSI-Gesetz in Kraft.

DORA

Verordnung (EU) 2022/2554, anwendbar seit dem 17. Januar 2025, das detaillierte Resilienz-Regelwerk für die Finanzbranche. Fünf Säulen, mit Meldung schwerer Incidents im Takt von 4 Stunden, 72 Stunden und einem Monat, gerechnet ab der Einstufung des Incidents.

In der Praxis

Belege und verwandte Use Cases

Proof of Concept bei der Deutschen Bahn

Ein Proof of Concept in der eigenen VPC der Deutschen Bahn: nur lesende Zugriffswege, menschlich gesteuerte Aktionen und eine bis zu 85 % geringere mittlere Behebungsdauer.

Fallbeispiel lesen

➞

Incident-Analyse

Automatische Root-Cause-Analyse über Ihren Observability-, Cloud- und Ticketing-Stack: die Maschine hinter der Zeile zur Incident-Bearbeitung weiter oben.

➞

Blast Radius einer CVE bestimmen

Welche laufenden Services ein verwundbares Paket nutzen, über den gesamten Bestand gefunden am Tag der CVE-Veröffentlichung: Lieferkettentransparenz in der Praxis.

➞

Hyground auf Ihr NIS2- oder DORA-Programm abbilden

Deep Dive buchen

Whitepaper lesen

Mehr zur Sicherheit von Hyground