NIS2 and High-Risk AI: Obligations, Implementation and Recommended Actions

This is Part 2 of our series on NIS2 and high-risk AI. Part 1 explains who is affected and why. Here, we cover concrete obligations, implementation strategies and prioritized steps for practice.

Obligations and requirements of the NIS2 directive for companies with high-risk AI

NIS2 shifts the focus away from abstract security promises toward concretely demonstrable measures. For high-risk AI operators, this means: policies are the starting point, robust evidence about your infrastructure, your incident management and your risk process is the goal.

Security requirements: technical and organizational measures

NIS2 requires a structured security level across the entire value chain. The following table shows the mandatory fields and their particular significance for high-risk AI:

For high-risk AI, a textual description of these measures is not enough. Auditors expect machine-readable, reproducible evidence of the infrastructure's state at the time of the audit. This is exactly where a technical infrastructure evidence approach like CERTavia delivers a clearly defined building block for your NIS2 dossier.

Incident management and reporting obligations

NIS2 tightens the requirements for handling security incidents. Particularly relevant are:

• A formalized incident response process with defined roles, escalation paths and decision criteria
• Deadlines and thresholds for reports to competent authorities, coordinated with sector-specific regulation
• The ability to technically prove what was configured in your infrastructure at the time of the incident

Especially for AI incidents, such as malfunctions caused by manipulated training data or compromised models, you must be able to demonstrably show whether the underlying infrastructure met the required controls. Clean infrastructure evidence prevents the otherwise unavoidable interpretation problem in the audit.

Risk assessment and governance for high-risk AI

NIS2 requires a systematic risk management process. For high-risk AI, this should include at least the following elements:

1. Risk inventory for AI-specific threats, such as model manipulation, data poisoning or misconfiguration of cloud and API interfaces
2. Assessment method with clearly defined evaluation criteria and a documented decision path
3. Linkage to technical controls, meaning a clear assignment of which infrastructure measures address which risk
4. Regular re-validation of the risks and their associated controls, especially after major changes to AI models or infrastructure

For compliance teams, it is essential that this process can be translated into an audit-ready dossier. This only succeeds if, alongside process documentation, structured, cryptographically verifiable infrastructure evidence is available. How this evidence can be used as a fixed component of AI Act and NIS2 documentation is described in the mapping under CERTavia in the AI Act audit dossier.

Without technical evidence, NIS2 compliance remains a claim on paper. With reproducible evidence, it becomes a robust argument toward supervisory authorities, auditors and your own board.

Implementation strategies and compliance measures in Germany

NIS2 compliance emerges within your existing security and governance structures, not in a parallel universe. The bottleneck is almost always missing, audit-ready evidence.

Step 1: Clarify NIS2 scope and responsibilities

The starting point is a clear assignment of which services and infrastructures fall under NIS2:

1. Identification of NIS2-relevant services, for example payment platform, patient portal, HR platform or SaaS core product
2. Mapping these services to concrete systems, domains, cloud accounts and network segments
3. Establishing a binding owner model between the business unit, IT, information security and compliance

In Germany, there is a special dimension to this: depending on the sector, you deal with different supervisory authorities that interpret NIS2 requirements alongside existing sector laws. This makes a clean scope document all the more important.

Step 2: Integrate NIS2 requirements into existing frameworks

Most regulated companies already work with established standards such as an ISMS or sector-specific security catalogs. Instead of building an additional NIS2 framework, you should:

• set up a mapping table that assigns NIS2 requirements to existing controls
• identify gaps where a policy exists but technical evidence is missing
• prioritize controls that affect both high-risk AI and business-critical services simultaneously

This is exactly where deterministic infrastructure evidence becomes effective, for example with the Sovereign Validation Protocol, which clearly shows whether your live infrastructure meets defined requirements at the time of the scan.

Step 3: German focus on demonstrability and documentation

In Germany you will be asked: Show me where this is documented. For NIS2, this concretely means:

• Audit-ready protocols for changes to critical systems and AI-relevant components
• Standardized reports that fit directly into NIS2, AI Act and sector-specific dossiers
• Supplier evidence for ICT third-party providers embedded in your NIS2-critical chain

Whoever defines an early template for audit reports, infrastructure evidence and risk decisions significantly reduces the effort per audit.

Step 4: Operational anchoring in day-to-day business

NIS2 must arrive in operations. Practically, this means:

1. Integration of NIS2 controls into change and release processes for AI systems
2. Regular, deterministic infrastructure validations for production domains and services
3. Anchoring reporting paths and documentation obligations in incident management

The more you automate these steps and back them with machine-readable evidence, the less time you lose in the audit on manual data searches. This is exactly where CERTavia precisely complements your existing governance process with cryptographically verifiable infrastructure evidence. For IT leaders and CTOs, there is a technical entry point via the validation process.

Technological and organizational challenges

Data security and infrastructure complexity

High-risk AI systems mostly operate on highly distributed architectures. Typical challenges:

• Unclear data flows between training, test and production environments, often without a clean separation of roles and permissions
• Fragmented logging that produces data during an incident but tells no consistent story of the infrastructure's state
• Dependency on ICT third-party providers, whose security level you are co-responsible for under NIS2

Mitigating this requires a technical inventory of all NIS2-relevant assets and a standardized validation of whether defined security requirements are really met at the time of the audit.

Transparency of AI algorithms and infrastructure dependency

Many organizations focus on model cards, fairness and explainability for high-risk AI. For NIS2, that is not enough. The audit asks:

• What infrastructure did these models run on – and in what state?
• What controls were active and demonstrable at the time of deployment?
• Can I, as an auditor, draw a consistent thread from the model decision to the audited underlying stack?

The practical approach: link every relevant AI deployment version to a concrete infrastructure snapshot – machine-readable and cryptographically verifiable.

Internal control mechanisms and demonstrability

Organizationally, NIS2 often fails due to fragmented responsibility – IT, data science, information security and compliance work on different lists and tools. Three measures help:

1. Harmonize the control catalog: consolidate NIS2, EU AI Act and sector requirements into a shared set of infrastructure controls
2. Standardize evidence format: define binary, machine-readable validation results per domain and service as a binding format
3. Clarify responsibility: fixed accountability for regularly obtaining, archiving and auditing the technical evidence – including supplier scans

Outlook: where cybersecurity and AI regulation are heading

From today's perspective, four clear trends are emerging:

• Stronger convergence of NIS2 and the EU AI Act – especially for high-risk systems with critical infrastructure relevance, requirements are being merged
• More focus on supply chains – from cloud platforms to specialized AI service providers, third parties are being drawn more strongly into evidence obligations
• Shift toward technical evidence – self-declarations and unstructured PDF policies lose weight compared to machine-readable, verifiable evidence
• Higher expectations for automation – risk analyses, infrastructure as code and continuous validation become the standard, not the exception

For German companies with high-risk AI, this means: whoever still organizes infrastructure, governance and evidence separately today produces friction losses, media breaks and attack surfaces in the audit. Whoever brings them together saves time and reduces liability pressure on the board.

Conclusion and recommended actions

NIS2 raises the expectations on your digital infrastructure, especially if you operate high-risk AI. Paper is no longer enough. What is required are audit-ready technical evidence that show what state your networks and systems were in at the time of the audit.

Prioritized steps for your practice

• Clarify scope and identify high-risk AI Which services fall under NIS2? Where is high-risk AI in use? Annex III screening with assignment to concrete domains, systems and cloud accounts.
• Define a shared control catalog Merge NIS2, EU AI Act and sector requirements into a consistent infrastructure control set. Mark which controls mandatorily require technical evidence (IAM, network, logging, deployment paths).
• Introduce a standardized evidence format Machine-readable, binary evaluable, with timestamp and cryptographic verifiability. Directly embeddable in NIS2 and AI Act dossiers.
• Build regular validation into processes Anchor infrastructure checks in change, release and incident processes. Every change to high-risk AI automatically triggers an infrastructure check.
• Technically secure the supply chain and vendor risk Record critical ICT third-party providers and check both contracts and the demonstrable infrastructure state. CERTavia Vendor Scan complements classic questionnaires with technical evidence.

NIS2 becomes manageable when your guiding principle is: first define the control, then specify the evidence. CERTavia addresses exactly this point and delivers machine-readable, cryptographically verifiable evidence as a building block of your NIS2 and AI Act documentation. For boards and decision-makers, a dedicated page explains how this evidence works in the audit conversation.

CERTavia 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, please consult an accredited conformity assessment body.