NIS2 and DORA

Know what you can already evidence for NIS2 and DORA

No single tool makes you compliant. What Hyground does is continuously surface and document the parts of both regimes that live in your stack: incident handling, risk analysis, asset and supply-chain visibility, and access governance. Read-only, inside your own perimeter.

Book a deep dive

Coverage

What Hyground can evidence, measure by measure

NIS2 Article 21 lists ten security measures, and DORA's pillars converge on the same operational core. Below is which ones Hyground evidences from live system state, which it supports in part, and which belong to other tools.

NIS2 Article 21(2) measure	Hyground Coverage	What you get	Maps to DORA
(a) Risk analysis and security policies	Full	FMEA risk analysis: scored failure-mode matrix, fault tree, report; on-demand asset inventory	Pillar 1: ICT risk management
(b) Incident handling	Full	Automated root-cause analysis; a timestamped, auditable session record per incident	Pillar 2: incident management
(c) Business continuity, backup, disaster recovery	None	Not Hyground: your backup and recovery tooling	Pillar 1: ICT risk management
(d) Supply-chain security	Full	Cross-stack dependency and asset enumeration; which running services use a vulnerable package	Pillar 4: third-party risk
(e) Secure development and vulnerability handling	Partial	Live exposure and configuration checks on running services	Pillars 1 and 3
(f) Assessing whether measures are effective	Full	Scheduled investigations on a cron cadence; downloadable reports that the checks ran	Pillar 3: resilience testing
(g) Basic cyber hygiene and training	None	Not Hyground: your awareness programme	Pillar 1: ICT risk management
(h) Cryptography and encryption	None	Not Hyground: your key management and encryption	Pillar 1: ICT risk management
(i) Access control and asset management	Full	Read-only adapters, short-lived per-environment tokens, full interaction audit trail; on-demand asset inventory	Pillar 1: ICT risk management
(j) Multi-factor authentication and secure communications	None	Not Hyground: your identity provider and communications	Pillar 1: ICT risk management

Scroll to see the full table

How it works

The capabilities behind the matrix

Each row above traces back to something that ships today. These are the five capabilities behind it.

NIS2 21(2)(b) / DORA Pillar 2

Incident handling

Automated root-cause analysis triggers within minutes of an alert and investigates across observability, cloud, Kubernetes, code, and ticketing. The structured diagnosis feeds your reporting clock, 24 hours under NIS2 and 4 hours for a major DORA incident, and every session is a timestamped, auditable incident record. When the regulator asks whether management ensured the measures were in place and working, that record is your evidence. Hyground recommends; your engineers decide.

NIS2 21(2)(a) / DORA Pillar 1

Risk analysis and asset inventory

Hyground's FMEA Risk Analysis vertical, applying failure mode and effects analysis to your stack, produces a scored failure-mode matrix, a fault tree, and report. Cross-stack asset enumeration across Kubernetes, AWS, Azure, databases, and observability feeds the inventory underneath it, built on demand instead of by hand. Scheduled runs make it continuous, not annual.

NIS2 21(2)(d)

Software bill of materials

A CycloneDX software bill of materials (SBOM) published with every release and available to customers, so your supplier review can check our dependency chain.

NIS2 21(2)(e)

Live dependency and exposure answers

Answers from your actual running state: which services use a vulnerable package, what dependencies drifted since the last release, and which services still accept unauthenticated traffic.

NIS2 21(2)(i)

Access governance and audit trail

Credentials sit centrally at the gatekeeper, not scattered across laptops. Adapters are read-only by default and verified at startup, access carries per-environment attribution with short-lived tokens, and every agent-to-system interaction is logged. The control story a procurement team can inspect.

NIS2 21(2)(f) / DORA Pillar 3

Effectiveness and third-party checks

Scheduled investigations run your checks on a cron cadence and produce downloadable reports: evidence that your measures run, not only that they are written down. The same watch extends to third parties, whether service-level objectives are met, whether data flows match the contract, and configuration drift on components someone else operates.

Third-party risk

The smallest third-party footprint you can put in a register

Hyground runs inside your environment and reads rather than writes, so you stay the operator of your own data plane. That keeps the third-party-risk paperwork short, and on-premises it nearly disappears.

Your perimeter, your credentials

Adapters are read-only by default and verified at startup. Credentials sit at the gatekeeper inside your environment and never leave it, and every agent-to-system interaction is logged with per-environment attribution.

Where your model runs

In your own cloud, pair Hyground with a managed model in a European region, such as Amazon Bedrock or Azure OpenAI, so prompts and responses stay in your tenant. Where you must exclude US providers, use a European model provider; on-premises with a local model, nothing leaves your environment at all.

Ready for your DORA register

For your register of information: data-processing location is your own tenant, substitutability is standard Kubernetes and model-agnostic, and exit is your own infrastructure and data. The only sub-processor to record is the model you connect to, typically a managed model in a European region of AWS or Azure, and on-premises there is none.

Coordinated vulnerability disclosure

Report a security issue to security@hyground.ai. Our written disclosure policy gives a dedicated contact with defined acknowledgement and triage times.

The honest edges

What Hyground does not do

Being precise about the edges is part of being a supplier you can put in a DORA register without a footnote. Hyground is the operational layer; it does not replace the tools around it, and it is not a certificate.

Not a SIEM, SOAR, or GRC tool

Your SIEM (security information and event management) keeps collecting and your governance tooling keeps the register. Hyground sits underneath them and answers what is true in the stack right now; it does not orchestrate remediation or own your controls.

Not backup, MFA, or a scanner

We do not run backups or failover, provide multi-factor authentication or identity management, or replace your code and dependency scanners or cloud-posture tooling. Where those belong in your programme, keep them.

Read-first by design

Hyground investigates and reports; it does not change your systems on its own. Writes are limited to ticket comments, a sandboxed shell, and its own knowledge base. Bounded remediation is on the roadmap, not something we claim today.

Certification in progress

ISO 27001 certification is in progress, and per-release CycloneDX software bill of materials files are available now. Where your procurement needs an issued certificate today, we will tell you exactly where we stand rather than imply more.

Deployment

Self-hosted, in the tier your obligation needs

Hyground is self-hosted in every tier, so the one you choose is the compliance argument you get to make.

Your cloud

Hyground runs in your own AWS, Azure, or Google Cloud tenant and your credentials never leave it. Pair it with a managed model in a European region, such as Amazon Bedrock or Azure OpenAI, so prompts stay in your tenant and the DORA Article 30 picture stays clean.

EU-sovereign

EU cloud such as StackIt, Hetzner, IONOS, or OVHcloud, paired with a model from a European provider, no US provider in the path. The strongest posture for DORA, NIS2, and Schrems II, and one a customer supervised by BaFin (Germany's financial regulator) can point to.

On-premises, air-gap optional

Nothing leaves your premises, and with a local model there is no sub-processor to record at all. The tier for defence, critical infrastructure, and classified or air-gapped environments.

You stay the operator

Hyground is a bring-your-own-chart deployment that sends no data back to us. Its information-security scope deliberately excludes your production environment, your model accounts, and your data, so the data plane stays yours.

The rules, in brief

Two regimes, two reporting clocks

Both regimes reach software vendors through their customers: in-scope customers push the requirements down the supply chain (NIS2 Article 21(2)(d), DORA Article 30), so the clock can start with you even when you are not directly in scope.

NIS2

Directive (EU) 2022/2555, a horizontal cybersecurity baseline. Significant-incident reporting runs on a 24-hour, 72-hour, and one-month cadence, with personal liability for management. In Germany it took effect through the amended BSI Act on 6 December 2025.

DORA

Regulation (EU) 2022/2554, applicable since 17 January 2025, the prescriptive resilience rulebook for finance. Five pillars, with major-incident reporting on a 4-hour, 72-hour, and one-month cadence, timed from when you classify the incident.

See it in practice

Proof and related use cases

Deutsche Bahn proof of concept

A proof of concept inside Deutsche Bahn's own VPC: read-only access paths, human-governed actions, and up to 85% lower mean time to resolution.

Read the case

Incident investigation

Automated root-cause analysis across your observability, cloud, and ticketing stack: the engine behind the incident-handling row above.

CVE blast-radius mapping

Which running services use a vulnerable package, found across your estate the day a CVE drops: supply-chain visibility in practice.

Map Hyground to your NIS2 or DORA programme

Bring your obligations and your stack. We will show you, against your own environment, which measures Hyground can evidence and which it cannot.

Book a deep dive Read the whitepaper Learn about Hyground's security