CIO, CISO & AI OFFICER
DORA, NIS2 & CRA under control
Three regulatory frameworks, one calendar, and it shows no mercy: DORA has applied since 17 January 2025, the German NIS2 Implementation Act since 6 December 2025, and since 11 September 2026 the reporting obligations of the Cyber Resilience Act have been in full force. Anyone who now builds a separate documentation world for each regime triples the effort and halves the impact. The better way: a shared core control set based on ISO 27001, one incident process with multiple reporting outputs, one register instead of five Excel lists. We build this with you, pragmatically and audit-proof. To get started: a gap analysis at a fixed price that tells you what is really missing and what you can save yourself.
Legal status as of 24 September 2026
The situation in September 2026: all three clocks are ticking
NIS2 is no longer a draft in Germany. The German NIS2 Implementation Act entered into force on 6 December 2025, with no transition period for the measures under Section 30 BSIG (German BSI Act). The registration deadline with the BSI expired on 6 March 2026, and the grace period ended on 31 July 2026. The reality behind this is remarkable: according to the BSI, only around 38 per cent of the estimated 29,500 affected companies had registered by the original deadline. Anyone who is still not registered today is committing a separate administrative offence subject to a fine, regardless of how good their own security actually is.
The Cyber Resilience Act triggered its first operational stage on 11 September 2026: manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to ENISA and CERT-Bund within 24 hours, with a detailed notification after 72 hours and a final report after 14 days or one month respectively. The core obligations, including CE marking, follow on 11 December 2027. And DORA has been applicable since 17 January 2025; with its guidance of 18 December 2025, BaFin has shown how it views ICT risks and the use of AI in its supervisory audit practice.
Regulatory timeline for DORA, NIS2 and CRA. Legal status as of 24 September 2026.
The real problem: documenting the same controls three times
In terms of content, all three regimes essentially require the same thing: risk analysis, technical and organisational measures, incident detection, reporting processes, supply chain control, the ability to provide evidence. The mistake we see most often: each regime gets its own project, its own set of documents and its own owner. The result is three parallel worlds that have to be maintained three times with every change and contradict each other at the first audit.
The sustainable approach is a shared core control set. ISO 27001 is suitable as the backbone because the 93 controls in Annex A cover the majority of the requirements from Section 30 BSIG, DORA Articles 5 to 16 and the CRA product obligations. On top of this sits a mapping: which control fulfils which requirement from which regime? Each measure is implemented once, documented once and counted three times. This considerably reduces the maintenance effort and structurally prevents contradictions.
Reporting chains: the 3 a.m. question
All three regimes work with similar, but not identical, reporting logics. NIS2 requires an early initial notification within 24 hours and a notification within 72 hours to the BSI. The CRA requires an early warning within 24 hours to ENISA and the CSIRT. DORA works with its own deadlines and BaFin as the recipient, with initial notifications for financial entities within a matter of hours. The decisive question is banal and yet almost never answered: who determines at 3 a.m. which regime is affected, who drafts the notification, and who approves it? A single incident can trigger NIS2, CRA, DORA and Article 33 GDPR notifications in parallel. Without a prepared reporting matrix, a security incident turns into a deadline incident.
AI comes on top – and in both directions
For CISOs and AI Officers, the situation is becoming doubly more demanding. On the one hand, AI systems themselves are becoming the subject of audits: the BaFin guidance explicitly treats AI as an ICT risk, and the AI Act brings its own incident and documentation obligations. On the other hand, AI assistants are giving rise to new classes of attack: in 2025, the EchoLeak vulnerability (CVE-2025-32711, CVSS 9.3) caused a widely used office AI assistant to disclose internal data, triggered by a single crafted e-mail and without any click by the user. This class of attack affects every AI assistant with access to internal data. At the same time, vulnerabilities are exploited with the help of AI within minutes, while internal decision-making processes take hours. Frameworks such as the OWASP LLM Top 10 and MITRE ATLAS therefore belong in every security architecture that contains AI components today.
DOWNLOAD · PDF (GERMAN) · 104 KB
Reporting deadlines overview NIS2, CRA, DORA, GDPR
All reporting deadlines, recipients and reporting stages at a glance, for the reporting matrix in an emergency.
Our offer
We start with a gap analysis at a fixed price: applicability per regime, comparison of your existing controls against NIS2, DORA and CRA, a prioritised catalogue of measures with effort estimates. You receive a document you can use to budget internally and provide evidence externally. After that, on a modular basis: building the core control set, reporting matrix, supplier register, audit support. Each module individually, cancellable at any time.
Regulatory gap analysis at a fixed price
Applicability per regime, comparison of your controls against NIS2, DORA and CRA, a prioritised catalogue of measures with effort estimates.
MODULAR · TRANSPARENT PRICING · CANCEL AT ANY TIME
