---
title: "Observability in the age of CRA and NIS2"
url: "https://www.sparkfabrik.com/en/blog/observability-cra-nis2-compliance-guide/"
lang: "en"
type: "blog-post"
date: "2026-09-09"
lastmod: "2026-09-09"
author: "SparkFabrik Team"
description: "The entry into force of the Cyber Resilience Act imposes 24-hour notification windows for vulnerabilities. Reduce Mean Time To Detect by mapping telemetry's three pillars to regulatory requirements. Anomaly detection strategies and architectures to comply with CRA and NIS2 obligations without penalties."
tags: ["Security","DevOps"]
schema:
"@context": "https://schema.org"
"@type": "BlogPosting"
"headline": "Observability in the age of CRA and NIS2"
"description": "The entry into force of the Cyber Resilience Act imposes 24-hour notification windows for vulnerabilities. Reduce Mean Time To Detect by mapping telemetry's three pillars to regulatory requirements. Anomaly detection strategies and architectures to comply with CRA and NIS2 obligations without penalties."
"url": "https://www.sparkfabrik.com/en/blog/observability-cra-nis2-compliance-guide/"
"datePublished": "2026-09-09T00:00:00+00:00"
"dateModified": "2026-09-09T00:00:00+00:00"
"author":
"@type": "Person"
"name": "SparkFabrik Team"
"image": "https://www.sparkfabrik.com/images/blog/observability-ai-tempi-di-cra-e-nis2/featured-en.webp"
"publisher":
"@type": "Organization"
"name": "SparkFabrik"
"url": "https://www.sparkfabrik.com"
"logo": "https://www.sparkfabrik.com/images/logo.svg"
---
# Observability in the age of CRA and NIS2
**Author:** SparkFabrik Team
**Published:** 9 September 2026
**Tags:** Security, DevOps
---
{{% tldr %}}From September 11, 2026, a software producer will have 24 hours to report an actively exploited vulnerability: this is not a paperwork issue, it is a Mean Time To Detect requirement. The point almost everyone misses is that Annex I of the CRA mandates logging security-relevant activity as a product requirement, not as a DevOps best practice. This changes everything: telemetry must be designed as an exportable chain of evidence, not as a dashboard to look at when something breaks.{{% /tldr %}}
Starting September 11, 2026, the reporting obligations of the **Cyber Resilience Act**[^1] and the **Single Reporting Platform** managed by ENISA[^2] become operational. From that date, a software manufacturer has 24 hours to send an early warning[^3] regarding an actively exploited vulnerability or a severe incident. Meeting these deadlines requires **observability** built-in by design. The time windows then require 72 hours for detailed notification, and 14 days (vulnerabilities) or one month (severe incidents) for the final report.
The scale of potential fines clarifies what is at stake: Regulation (EU) 2024/2847 provides for up to 15 million euros or 2.5% of total worldwide annual turnover, while **NIS2**[^4] sets fines up to 10 million euros or 2% for essential entities. However, the problem is not legal. It is an engineering problem.
Twenty-four hours is not a paperwork problem. It is a **Mean Time To Detect** requirement. If telemetry is scattered across uncorrelated silos, the window is wasted on manual reconstruction of events: who called what, using which identity, on which endpoint, in which time window.
Here lies the point missed by most content on the subject. The CRA does not merely ask to notify: Annex I, Part 1, point (l) requires the product to **record and monitor security-relevant internal activity**, namely access to and modifications of data, services, and functions. Observability is therefore a product requirement even before it is an operational tool.
_This article maps telemetry's three pillars to regulatory obligations, demonstrates how to design the 24h/72h notification cascade starting from the observability pipeline, and concludes with the use of anomaly detection models to compress detection time._
## What CRA and NIS2 really ask for in terms of system visibility
The CRA regulates products with digital elements, whereas NIS2 regulates entities providing essential services. The former mandates the **recording of security-relevant activity** as an essential product security requirement; the latter mandates organizations to **notify significant incidents** within specific time windows. Both presuppose a **detection capability** that no documentary checklist can replace.
The distinction between Regulation (EU) 2024/2847 and Directive (EU) 2022/2555 is not academic: it changes who the obligated party is. If you develop and sell software, the CRA applies to you as a manufacturer. If you manage a service in one of the 18 sectors covered by NIS2, you are obligated as an entity. Many Italian companies are both at the same time, and this is the most challenging scenario to manage.
**Annex I of the CRA** lists logging and monitoring of security-relevant activity among the essential product security requirements, and **Annex VII** mandates that technical documentation provide explicit evidence of it. It is not an operational best practice: it is a condition for **CE marking**, and therefore for accessing the European market.
### Why a single incident triggers two regulations
Imagine a zero-day vulnerability in a software component sold to a healthcare provider. It is actively exploited in production on a Tuesday morning. From that moment, two distinct chains of obligations start: the manufacturer notifies under the CRA because the defect is in the product, while the hospital notifies under Article 23 of NIS2 because the essential service is compromised. The 24-hour and 72-hour windows run in parallel, not sequentially.
The operational consequence is concrete: you need **two separate chains of evidence**, yet powered by the **same telemetry pipeline**. Anyone separating them manually by exporting screenshots from different dashboards wastes hours they do not have.
The NIS2 scope is broader than many teams realize. In the January 2026 amendment and simplification proposals, the European Commission estimated that roughly 28,700 organizations are involved and supported in their compliance goals[^5].
If your customers operate in energy, healthcare, transport, public administration, or digital services, they most likely fall under its scope. The intersections between these two regulations and the DORA regulation[^6] are covered systematically in our [compendium on NIS2 and DORA](https://go.sparkfabrik.com/nis2-dora-compendium/en), which helps determine which rules apply to your scope. We also analyzed the architectural implications of these requirements on clusters and platforms [from the perspective of compliance in cloud native architectures](/en/blog/nis2-dora-impact-on-cybersecurity-in-cloud-native/).
### Logging as an essential product requirement, not a DevOps practice
What does it mean in practice to record security-relevant internal activity? It means **producing structured, correlatable events** for at least the following categories:
* authentication and authorization events, including failed attempts and privilege escalations;
* application or infrastructure configuration changes, along with the identity of who performed them;
* access to sensitive data or data subject to GDPR constraints[^7], referencing the affected resource;
* invocations of privileged functions and administrative APIs;
* integrity events: signature verification, applied updates, executed rollbacks.
The implicit requirement that almost everyone underestimates is **documentation**. If you cannot declare which events your product records, where it writes them, and how long it retains them, the technical file required by Annex VII simply does not exist.
In most projects we inherit, logging exists, but it was designed for debugging: natural language messages, unnormalized fields, and a retention period of a few days dictated by storage costs. Auditing requires a stable schema, structured format, and retention aligned with the product lifecycle. This changes everything.
## Monitoring or observability: which one actually stands up to a compliance audit?
**Monitoring answers questions you have already anticipated** when configuring thresholds. **Observability allows you to ask new questions** about a running system without releasing additional code. A zero-day is by definition a question you had not anticipated: which is why monitoring alone does not hold up during audits and incident response.
### Comparison table between traditional monitoring and observability
| Dimension | Traditional monitoring | Observability | Implication for CRA and NIS2 |
| ------------------------ | ---------------------------------- | -------------------------------- | ------------------------------------------------------- |
| Question type | Known and predefined (thresholds, checks) | Unknown, formulated post hoc | An unprecedented exploit has no preconfigured threshold |
| Granularity | Host, service, container | Single request, with context | Malicious requests must be isolated, not the host |
| Use in incident response | Alarm indicating something is broken | Interactive root cause analysis | 72-hour notification requires impact scope |
| Evidence value | Isolated logs, dashboards | Correlated and attributed traces | Technical file requires reconstructible evidence |
99.9% uptime is not a compliance metric. A service can be perfectly "up", return 200 to all requests, and simultaneously be compromised for weeks: availability measures continuity, not integrity.
### The three pillars as a chain of evidence
Logs, metrics, and traces: the **three pillars of observability** are the same ones every team knows from OpenTelemetry documentation, but under the CRA, their function changes. They are no longer used merely to understand why a service is slow; they must be interpreted as evidence, each with a specific role in incident reconstruction:
* **Metrics**: the signal that something is out of the ordinary. They answer "what" and trigger the regulatory timeline.
* **Distributed traces**: the path of the request across services. They answer "where" and define the impact scope.
* **Structured and correlated logs**: the evidence of what occurred. They answer "why" and feed the final report.
Without correlation, they remain three silos, and forensic reconstruction will not fit into the 24-hour window.
**Span attributes** are what transform telemetry into evidence: HTTP route, status code, client IP, caller identity, tenant. Without contextual attributes, a log is noise that no auditor will accept as an impact reconstruction.
**OpenTelemetry**[^8] is not just a technical choice; it is a **choice of data sovereignty**: vendor-agnostic instrumentation means being able to switch backends, from a commercial Application Performance Management (APM) tool like Dynatrace[^9] to an open source stack, without breaking evidence continuity. When the product lifecycle spans years and retention must match it, this portability is a requirement, not an architectural preference.
At runtime, **eBPF**[^10] comes into play, enabling kernel- and container-level monitoring without modifying applications. This is where the CRA's distinction between a present vulnerability and an actively exploited vulnerability materializes: static analysis and the **[SBOM](/en/blog/sbom-cyber-resilience-act-dependency-mapping/)**[^11] indicate that the flaw exists, but only runtime reveals that someone is using it. We already covered the build side of this chain, including scanning, artifact signing, and pipeline policies, in our series article dedicated to [automating monitoring in cloud native pipelines](/it/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/).
Turning these three signals into auditable indicators requires **Site Reliability Engineering** discipline, [which in our operational guide we translate into SLIs, SLOs, and measurable reliability](/en/landing/guida-sre/) rather than dashboards checked by eye.
## How to design the 24h/72h cascade with an observability pipeline
The 24 hours must be treated as a time budget, not an administrative deadline. They should be broken down into four phases: automated detection, event triage and qualification, minimum evidence gathering, and sending the early warning. If detection consumes 18 hours, the remaining three phases are left with a margin no team can meet.
Here are the four phases of the cascade along with their respective deliverables:
1. **Detection** (target: minutes, not hours). Deliverable: qualified alert with a telemetry snapshot of the time window.
2. **Triage and qualification** (a few hours). Deliverable: documented decision on "severe incident" or "actively exploited vulnerability", complete with rationale.
3. **Early warning within 24 hours**. Deliverable: nature of the event, suspected origin, impacted services.
4. **Detailed notification within 72 hours**. Deliverable: impact scope, indicators of compromise, mitigation measures already applied. Followed by the final report within 14 days for exploited vulnerabilities or one month for severe incidents, complete with documented root cause analysis and corrective action.
Neither Regulation (EU) 2024/2847 nor the ENISA FAQs on the Single Reporting Platform[^2] specify the **attachment format**: the pipeline output must be designed to be exportable. A dashboard dump is not a notification attachment: structured extracts are required, with coherent timestamps and references to trace identifiers.
### From detection to early warning: what to automate in the first 24 hours
**Alerting** must be built on security indicators, not just infrastructure thresholds. Defining SLIs and SLOs that reflect expected service behavior, such as the ratio of successful to failed authentications per client or the expected distribution of calls to privileged endpoints, allows a signal to trigger before the anomaly turns into user-visible downtime.
The second element is **routing**. Security alerts must end up in an incident response channel separate from the standard operational channel, featuring an explicit regulatory timer in the message. In our experience, the most common failure is not missed detection: it is failing to recognize that the alert carries a statutory deadline. A security ticket sitting parked in a backlog for 30 hours is a process problem, not a tooling problem.
The third element is the **automatic context snapshot at trigger time**: traces correlated to the suspicious request ID, metrics for the time window, and logs of security-relevant events. Freezing them instantly avoids having to reconstruct them after retention has already rotated them.
### Retaining evidence in an auditable manner
**Retention** must be aligned with the expected product lifecycle, not the cost convenience of the logging backend. If you declare five years of support, seven days of logs will not stand up to the first audit.
Then there is the question of **integrity**: who can modify or delete logs? Evidence that can be altered by anyone with cluster access is not evidence. What is needed is write-once storage, separated access controls, and logging operation auditing.
Finally, the correlation between the internal incident ID and the reference of the notification sent via ENISA's **Single Reporting Platform**[^2], which then dispatches to the relevant territorial CSIRTs[^12], in Italy the **CSIRT operating within the National Cybersecurity Agency (ACN)**[^13]. We gathered the qualification and response practices that make this process sustainable [in our guide to application security throughout the software lifecycle](/en/blog/guides/software-security-best-practices/).
## AI applied to observability: anomaly detection and proactive compliance
Anomaly detection models applied to logs, metrics, and traces compress detection time by replacing static thresholds with dynamic baselines learned from actual system behavior. In an **AIOps** context, this means **correlating seemingly unrelated events across different services and surfacing signals that no preconfigured rule would have caught**.
The operational paradox of compliance-driven monitoring is that the more logging requirements you create, the more events you generate, and the more noise you accumulate. **Alert fatigue** is not merely a service desk annoyance: it is a direct regulatory risk. A genuine signal buried beneath thousands of false positives consumes the 24-hour window while nobody notices.
What these models practically do on production telemetry:
* build dynamic baselines per service, endpoint, and time slot, instead of fixed thresholds that only fit average traffic;
* correlate events across different services that no human operator would connect, such as an authorization error spike on one service and a latency shift on another;
* detect **configuration drift** relative to the desired state before the deviation becomes an exploitable vulnerability.
The limitation must be stated honestly: a model flagging an anomaly does not produce a compliant notification. Qualifying an event as a severe incident remains a human, reasoned, and documented decision. **AI compresses the MTTD (Mean Time To Detect); it does not transfer the manufacturer's responsibility.**
A separate topic, outside the scope here, concerns **the observability of AI systems themselves**: how to trace probabilistic workloads and agents in production [is something we addressed when discussing AgentOps](/en/blog/agentops-governing-monitoring-ai-agents/).
### From alarm to automated action
**A detected anomaly** should not be limited to lighting up a dashboard panel. **In an event-driven architecture, it triggers a workflow**: isolating the suspicious workload, rolling back the drifted configuration, and automatically opening an incident file with the evidence snapshot already attached.
Event-driven automation is not an experimental concept: mature platforms like Event-Driven Ansible[^14], Datadog[^15], and Dynatrace[^9] connect a detected signal to an automated response workflow, from workload isolation to configuration rollback, without human intervention. These systems enable managing a massive volume of automated data. However, the value depends not just on volume, but on input signal reliability: automation triggered by noisy alerts amplifies errors instead of reducing them.
### Recurring errors that undermine investment
Four pitfalls we repeatedly observe in the field:
* **telemetry collected in abundance but uncorrelated**, rendering it unusable as a chain of evidence;
* retention dictated by backend budget rather than declared product lifecycle;
* alerts lacking named ownership and explicit regulatory deadlines;
* instrumentation added post hoc rather than designed alongside the application, meaning a lack of **observability by design**, the operational twin of the **security by design** mandated by the CRA.
A rule of thumb to check this in ten minutes: if for a given service you cannot tell which event generates which signal and who receives it within how many minutes, the compliance you filed is theoretical.
## From regulatory obligation to operational capability
**Observability plays two roles under the CRA**, not one: it is an **essential product requirement** under Annex I, Part 1, point (l), and it is the **enabler of the 24-hour and 72-hour notification cascade**, both on the manufacturer side and on the essential entity side under Article 23 of NIS2. Anyone treating it strictly as a troubleshooting tool is building only half of compliance.
The shift to be made is not technological, but cultural: **treating telemetry as evidence right from design**, not as a tool to consult when something breaks. Those who adopt this perspective arrive at the CRA and NIS2 deadlines with proof ready for export, rather than chasing it while the 24-hour clock ticks down.
At SparkFabrik, we are a Kubernetes Certified Service Provider, members of CNCF[^16] and OpenSSF[^17], and we **design open source observability stacks** based on Prometheus[^18], Grafana[^19], Jaeger[^20], and OpenTelemetry on Kubernetes[^21] in multi-cloud environments. The choice of open source here goes beyond ideology: it is the only approach that **guarantees telemetry data portability** throughout a product lifecycle that may outlast any vendor contract.
From mapping dependencies with an SBOM to automating runtime compliance, aligning with the CRA requires technical capabilities built together, not in sequence. The complete overview of obligations and deadlines is gathered on our [page dedicated to the Cyber Resilience Act and compliance paths](/en/resources/hot-topics/cra-cyber-resilience-act/), while for a security and compliance assessment you can [consult our supply chain security team](/en/services/cloud-native-services/supply-chain-security/).
## Notes and sources
[^1]: **Cyber Resilience Act (Regulation (EU) 2024/2847)**. Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), establishes mandatory horizontal cybersecurity requirements for hardware and software products with digital elements across the EU. (source: )
[^2]: **ENISA**. ENISA is the official EU agency dedicated to achieving a high common level of cybersecurity across Europe. It operates the CRA Single Reporting Platform for reporting vulnerabilities and incidents. (source: )
[^3]: **CRA Application**. Reporting obligations under the CRA become operational starting September 11, 2026. (source: )
[^4]: **NIS2 (Directive (EU) 2022/2555)**. The NIS2 Directive (Directive (EU) 2022/2555) is the EU legal framework establishing a high common level of cybersecurity across the Union, expanding the scope of the original NIS Directive. (source: )
[^5]: **28,700 organizations involved and supported**. Targeted amendments to the NIS2 Directive aim to increase legal clarity and will facilitate compliance for 28,700 companies, including 6,200 micro and small enterprises. (source: )
[^6]: **DORA**. The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, is the EU framework enforcing ICT risk management and cybersecurity for financial entities. (source: )
[^7]: **GDPR**. The General Data Protection Regulation (GDPR) is the EU law on data protection and privacy. It establishes strict rules for processing personal data, including telemetry collection. (source: )
[^8]: **OpenTelemetry**. OpenTelemetry is an open source and vendor-neutral observability framework from the CNCF, providing APIs, libraries, and agents to collect distributed traces, metrics, and logs. (source: )
[^9]: **Dynatrace**. Dynatrace is an AI-powered observability and security platform providing application performance monitoring, infrastructure monitoring, and digital experience management. (source: )
[^10]: **eBPF**. eBPF is a technology that executes sandboxed programs in the Linux kernel without modifying source code, enabling advanced networking, observability, and security monitoring. (source: )
[^11]: **SBOM**. An SBOM is a nested inventory of software product components and dependencies, used to manage supply chain risks and vulnerabilities. (source: )
[^12]: **CSIRT**. Established by the EU NIS Directive, the CSIRTs network connects Computer Security Incident Response Teams for operational cooperation and incident response across Member States. (source: )
[^13]: **CSIRT Italia (ACN)**. CSIRT Italia is the Italian national Computer Security Incident Response Team operating within the National Cybersecurity Agency (ACN) to manage cyber incidents and issue early warnings. (source: )
[^14]: **Event-Driven Ansible**. Event-Driven Ansible (Red Hat) connects events from monitoring systems to automated response playbooks for event-driven remediation. (source: )
[^15]: **Datadog**. Datadog is an observability and monitoring platform; its Workflow Automation feature triggers automated response workflows based on alerts and metrics. (source: )
[^16]: **CNCF**. The Cloud Native Computing Foundation (CNCF) is a non-profit organization under the Linux Foundation that hosts critical open source projects like Kubernetes and promotes cloud native technologies. (source: )
[^17]: **OpenSSF**. The Open Source Security Foundation (OpenSSF) is a Linux Foundation initiative developing standards, tools, and best practices to improve open source ecosystem security. (source: )
[^18]: **Prometheus**. Prometheus is an open source monitoring and alerting toolkit that collects and stores metrics as time series. Created at SoundCloud, it is a CNCF graduated project. (source: )
[^19]: **Grafana**. Grafana is an open source analytics and monitoring platform offering interactive dashboards, visualizations, and alerting for observability data across multiple sources. (source: )
[^20]: **Jaeger**. Jaeger is an open source distributed tracing platform hosted by the CNCF, used to monitor and analyze transactions, locate bottlenecks, and identify service dependencies. (source: )
[^21]: **Kubernetes**. Kubernetes is an open source container orchestration platform for automating deployment, scaling, and management of containerized applications. (source: )
---
## Frequently Asked Questions
### What does observability mean and how does it differ from monitoring?
Observability is the ability to understand the internal state of a system based on its external outputs, asking new questions without releasing additional code. Monitoring verifies known, predefined conditions using thresholds and checks. The difference matters during unforeseen incidents, where no pre-configured threshold exists.
### What are the three pillars of observability?
Metrics, distributed traces, and logs. Metrics signal that something is off, traces show the path of the request through services, and logs explain what happened. The value emerges from correlation: analyzed separately, they remain three silos unusable in forensic analysis.
### Does the Cyber Resilience Act explicitly require observability?
Regulation (EU) 2024/2847 does not use the term, but Annex I, Part 1, point (l) requires the product to record and monitor internal security-relevant activity, including access to and modifications of data, services, and functions. Annex VII mandates documenting this in the technical documentation.
### What are the incident notification timelines under NIS2 and CRA?
The CRA requires an early warning within 24 hours, a detailed notification within 72 hours, and a final report within 14 days for actively exploited vulnerabilities or one month for severe incidents. Article 23 of Directive (EU) 2022/2555 imposes similar 24-hour and 72-hour windows on essential and important entities.
### Is Grafana enough to be NIS2 compliant?
No. Grafana is the visualization and alerting layer of a broader stack that includes data collection, correlation, and auditable retention. Compliance depends on telemetry completeness, correlation across the three pillars, and evidence integrity, not on the single tool adopted.
---
## Related Articles
- [Orchestrating multiple SBOMs](https://www.sparkfabrik.com/en/blog/orchestrating-multiple-sboms-cra/) - Managing dozens of documents per release creates misalignment with Cyber Resilience Act …
- [Open source and the Cyber Resilience Act: managing responsibilities](https://www.sparkfabrik.com/en/blog/open-source-cyber-resilience-act-responsibilities/) - The Cyber Resilience Act introduces direct legal responsibilities for those integrating open source …
- [CRA: automating monitoring in cloud-native pipelines](https://www.sparkfabrik.com/en/blog/cra-compliance-automation-cloud-native-pipelines/) - The Cyber Resilience Act transforms compliance into a continuous process integrated into pipelines. …
---
*This is a Markdown version of the blog post to facilitate reading by AI and crawlers.*
*Visit [https://www.sparkfabrik.com/en/blog/observability-cra-nis2-compliance-guide/](https://www.sparkfabrik.com/en/blog/observability-cra-nis2-compliance-guide/) for the full version with images and formatting.*