NIS2, DORA and EU AI Act: three frameworks, one infrastructure layer.
Companies in regulated industries rarely operate under a single requirements framework. NIS2, DORA and the EU AI Act address, by different routes, the same technical foundation: the infrastructure layer on which digital systems ingest, process and protect data. This page explains the requirements of the three frameworks, their overlaps, and the technical signals that can feed into an audit in these contexts as a building block.
This page serves technical orientation and does not constitute legal advice. Assessing regulatory obligations in an individual case is the responsibility of qualified legal and compliance advisors.
The Network and Information Security Directive: requirements for critical infrastructure
The NIS2 Directive has been transposed in Germany: the NIS2 Implementation Act (NIS2UmsuCG) was promulgated in the Federal Law Gazette on 5/6 December 2025 and entered into force on 6 December 2025 without a transition period. The BSI registration deadline expired on 6 March 2026; around 29,500 entities are affected. The directive significantly expands the scope of the original NIS Directive and tightens cybersecurity and reporting requirements.
Who falls under NIS2
NIS2 distinguishes between essential and important entities. Essential entities include operators in the sectors of energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration and space. Important entities include postal and courier services, waste management, chemicals, food, manufacturing, digital providers and research institutions.
Classification is based on company size and sector. Companies with more than 50 employees or annual revenue exceeding EUR 10 million in one of the sectors listed fall within scope.
What NIS2 technically requires
NIS2 requires appropriate and proportionate technical, operational and organizational measures to manage risks to the security of network and information systems. The technical requirements cover risk analysis and information security policies, incident handling measures, business continuity measures, supply chain security, security measures in the acquisition, development and maintenance of network and information systems, and encryption and cryptographic procedures.
Cryptographic procedures, DNS configuration, access configuration and infrastructure integrity are technical parameters that can feed into a NIS2 audit as a building block — but they cover only a portion of the organization-wide risk management under Section 30 NIS2UmsuCG.
The Digital Operational Resilience Act: requirements for financial entities
DORA — Regulation (EU) 2022/2554 — has applied to financial entities in the EU since 17 January 2025. It defines uniform requirements for the digital operational resilience of the financial sector: ICT risk management, incident reporting, resilience testing, third-party risk and the Register of Information.
Who falls under DORA
DORA applies to a broad range of financial entities: credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, and ICT third-party service providers that supply financial entities.
The last point is relevant for many technology companies: a software vendor or infrastructure provider that supplies financial entities falls within the DORA scope as an ICT third-party service provider.
What DORA technically requires
DORA defines requirements in five areas: ICT risk management, management of ICT-related incidents, digital operational resilience testing, management of ICT third-party risk, and information sharing. The technical requirements for ICT systems and their infrastructure include measures for detecting anomalous activity, protection and prevention measures at the infrastructure layer, continuous monitoring and documentation, and requirements for third-party providers in the supply chain.
The public infrastructure posture of an ICT third-party service provider can serve as an input into the third-party risk assessment under DORA Art. 28 — it replaces neither ICT risk management, incident reporting, resilience testing nor the Register of Information.
Where NIS2, DORA and EU AI Act address the same infrastructure layer
The three frameworks originate from different regulatory contexts. At the technical infrastructure layer, however, they address overlapping parameters.
Cryptographic integrity
NIS2 requires the use of cryptographic procedures. DORA requires protective measures for ICT systems. Art. 50 EU AI Act requires machine-readable transparency and verifiable provenance for AI systems. All three requirements are anchored at the same infrastructure layer: DNS configuration, TLS certificate chain, DNSSEC and HTTP security headers.
Data source integrity
NIS2 sets requirements for supply chain security. DORA sets requirements for ICT third-party risk. Art. 50 EU AI Act sets requirements for the transparency and provenance of AI outputs and data sources. All three requirements touch the same technical question: are external data sources verifiably intact?
Documentation obligation
All three frameworks require structured, audit-ready documentation. A cryptographically signed, continuously retrievable record of technical infrastructure integrity forms the common documentation foundation for all three frameworks.
Continuous monitoring
NIS2 and DORA require continuous monitoring and incident reporting obligations. Art. 50 EU AI Act requires the ongoing assurance of machine-readable transparency. Quarterly re-scans and change notifications form the technical foundation for this continuity requirement.
What an audit checks in all three contexts
An auditor examining an infrastructure from a NIS2, DORA or EU AI Act perspective asks overlapping technical questions in all three contexts.
DNS and cryptographic base configuration
DNSSEC configuration, CAA records, TLS certificate chain and certificate transparency are audit-relevant in all three frameworks. Gaps at this layer are directly visible and documented in an audit.
HTTP security headers
HSTS, CSP, X-Frame-Options, X-Content-Type-Options and Referrer-Policy are standardized protective measures at the infrastructure layer. Their correct configuration is a check parameter in the CERTavia scan and can feed into NIS2 and DORA reviews as a technical building block.
Access configuration for automated systems
The consistency between declared crawler configuration and actual infrastructure response is relevant under DORA and NIS2 as part of third-party risk. Under the EU AI Act it is part of consent declaration integrity.
Machine-readable governance declaration
AI policy URL, an AI section in the privacy notice, deepfake disclaimer and a named point of contact for AI inquiries are transparency requirements under Art. 50 EU AI Act. Their machine-readable implementation simultaneously strengthens the documentation foundation for NIS2 and DORA.
Supply chain integrity
NIS2 and DORA explicitly set requirements for supply chain integrity. Software vendors and ICT third-party service providers that supply companies in regulated sectors face increasing pressure to demonstrate a verifiable infrastructure status.
Which sectors sit under all three frameworks
Financial sector
Banks, insurers and financial services providers are fully subject to DORA and fall within the NIS2 category of essential entities. AI systems in credit scoring, creditworthiness assessment and risk classification additionally fall under Annex III No. 5 of the EU AI Act. The infrastructure layer of these systems is subject to all three frameworks simultaneously.
Healthcare
Hospitals and healthcare facilities are essential entities under NIS2. AI systems in diagnostics and patient management fall under Annex III No. 2 of the EU AI Act. The technical infrastructure layer of these systems is subject to the combined requirements of both frameworks.
Critical infrastructure
Operators in the energy, water and transport sectors are essential entities under NIS2. AI systems in the control and monitoring of this infrastructure fall under Annex III No. 2 of the EU AI Act. The overlap of requirements is most pronounced in this sector.
ICT third-party service providers
Software vendors and infrastructure providers that supply financial entities fall under DORA as ICT third-party service providers. If they simultaneously supply operators of critical infrastructure, NIS2 additionally applies. A verifiable infrastructure status is an increasingly requested document in procurement processes and vendor qualification for these sectors.
One infrastructure layer, technically touching several frameworks
CERTavia produces machine-verifiable Layer-0 evidence of a domain's public infrastructure. This evidence is primarily an EU AI Act Art. 50 artifact; the same public infrastructure signals are also considered by NIS2 (supply chain, Section 30 NIS2UmsuCG) and DORA (third-party risk, Art. 28).
The result is a cryptographically signed, DNS-anchored evidence document. In the Enterprise tier, CERTavia bundles this Layer-0 evidence as consolidated infrastructure evidence with Art.-50 reference and mapping to NIS2- and DORA-relevant signals — not DORA reporting in the sense of incident reports or the Register of Information.
The Sovereign Vault link can be forwarded to external auditors, notified bodies and authorities. The machine-readable verification URL enables automated status queries by external audit systems.
Further reading
Risk classes, enforcement phases and technical infrastructure implications at a glance.
Annex III — high-risk AI in detail →High-risk categories and technical requirements for companies under Annex III.
EU AI Act quick test: evaluate your Annex III risk in two minutes →Questions and answers to assess your own risk classification.
CERTavia for compliance teams →Structured documentation for audits under EU AI Act, NIS2 and DORA.
CERTavia for boards and decision-makers →Audit-ready evidence for auditors, investors and the supervisory board.
CERTavia for CISOs →External evidence for risk registers, third-party risk and NIS2 Art. 21 risk management measures.
NIS2 and high-risk AI: who is affected? (Blog, DE) →Which companies fall under NIS2, what the directive requires, and why infrastructure evidence matters.
NIS2 obligations and implementation: recommendations (Blog, DE) →Concrete steps for NIS2 compliance with high-risk AI — from scope clarification to technical evidence.
One infrastructure layer, technically touching EU AI Act, DORA and NIS2.
CERTavia delivers machine-verifiable Layer-0 evidence — primarily an Art.-50 artifact. As an input into the third-party risk assessment under DORA Art. 28, the vendor scan is additionally available.
Check a domain DORA third-party evidence →Questions about NIS2, DORA and infrastructure evidence
Is this an official certification?
No. CERTavia does not issue a government-recognized certificate. The SOVP evidence is a technical instrument — cryptographically signed, DNS-anchored, directly verifiable by auditors. More in the glossary (DE) →
Can I scan a vendor without obtaining their consent?
SOVP checks exclusively publicly reachable infrastructure configurations — DNS, TLS, HTTP headers. No systems are actively attacked. Legal responsibility rests with the party commissioning the scan. We recommend vendor scans within contractually regulated due diligence processes, e.g. as part of the DORA third-party risk assessment under Art. 28. More about the vendor scan →
Where is my data stored? (GDPR)
SOVP scans check exclusively publicly accessible infrastructure parameters of the specified domain. Scan results and the Sovereign Vault are stored on European infrastructure. Customer data is processed exclusively for contract fulfillment. Details in the privacy policy →
Know your infrastructure status under all three frameworks
Quick Scan – free
The free Quick Scan delivers the Layer-0 result of your domain in 90 to 120 seconds. No form, no registration.
Scan your domain now — freeEnterprise & custom requirements
For complex regulatory frameworks or individual organizational structures, the contact form is available.
Get in touchCERTavia analyzes technical infrastructure signals. The result is a machine-readable finding, not a legal opinion and not a certification within the meaning of the EU AI Act conformity assessment under Article 43. For legally binding compliance assessments, contact an accredited conformity assessment body.
This page serves technical orientation and does not constitute legal advice. The presentation of NIS2, DORA and the EU AI Act reflects the state of knowledge at the time of publication. Regulatory requirements continue to evolve. Assessing specific obligations in an individual case and implementing a complete compliance program is the responsibility of qualified legal and compliance advisors. CERTavia provides technical infrastructure validation based on the Sovereign Validation Protocol (SOVP, Patent Pending No. 64/005,737).