How Grafana helps with NIS2 point 3.2 monitoring and alarm thresholds
If you are an essential or important entity preparing for NIS2 supervision, the question to answer first is which parts of point 3.2 of the Annex to Implementing Regulation 2024/2690 a self-hosted Grafana stack can support and which need another system. Point 3.2 asks for monitoring and logging of activity on network and information systems, with monitoring automated to the extent feasible, alarm thresholds that trigger alarms, and monitoring of the monitoring itself. Grafana helps with the dashboards and automated evaluation of metric and log queries, the alert rules and notification routing that fire when thresholds are crossed, and the alert history that shows what fired and when. It also helps with an independent availability check, provided the Grafana instance and its data sources run on infrastructure separate from the systems they watch. Grafana does not replace a SIEM, EDR or XDR tool, and it does not by itself give you tamper-protected log retention, backup of logs for a predefined period, or access control over log content. Those usually sit with a log platform such as Loki or Graylog, or with a security tool.
Confirm early which of your in-scope systems produce the signals you need, and whether the thresholds you set are defined by your own risk assessment rather than by a default. Grafana Alerting needs a high availability design if alerts must reach people reliably, and the Grafana high availability documentation notes that alerting needs additional configuration to avoid duplicate notifications. Ask your team to confirm how time synchronization is handled across monitored systems and the Grafana nodes, because point 3.2.6 expects synchronized time sources where feasible. Keep the configuration in version control with provisioning so the alert rules and contact points can be shown as they existed on a given date.
NIS2 creates no certificate of compliance. National competent authorities supervise through inspections, audits, scans, information requests and fines, so there is nothing to certify at the Grafana layer. DeployOpen plans, implements and documents monitoring systems, alert configuration and the evidence they produce, and prepares that evidence for review. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors or your national authority make any determination on compliance. The ENISA technical implementation guidance lists examples of evidence, including configured alarm thresholds and records of past alarms, which is the starting point for deciding what your Grafana instance must be able to show.
Mapping point 3.2 requirements to Grafana capabilities and configuration
This table maps each point 3.2 requirement in Implementing Regulation 2024/2690 to the Grafana capability that supports it and the configuration it needs. Rows marked as needing another control show where Grafana alone will not give an assessor the evidence they expect. Read it as a starting design, then confirm each row against your own network, retention and identity setup.
| Requirement | Grafana capability and configuration | Needs a log platform or other control? |
|---|---|---|
| 3.2 monitoring and logging of activity to detect potential incidents | Data source queries against metrics, logs and traces, with dashboards for security-relevant signals such as failed logins, privilege changes and service errors. Confirm which sources you connect and that each one is in scope. | Yes for security event logs, which usually need a SIEM or log platform as the system of record |
| 3.2 automated monitoring to the extent feasible | Grafana Alerting rules evaluated on a schedule against connected data sources, with rules stored under provisioning so changes are versioned in Git or Terraform. | No |
| 3.2.4 regular log review for unusual trends | Trend panels and anomaly-oriented queries on time series, plus a recorded review cadence kept outside Grafana. Grafana shows trends but does not replace a documented review by a qualified person. | Partly, the review record and ticketing sit in your case management tool |
| 3.2.4 alarm thresholds that trigger an alarm, automatically where appropriate | Threshold and reduce expressions in alert rules, with notification policies routing by label to contact points. Confirm threshold values are approved and that routing covers out-of-hours. | No |
| 3.2.4 timely, qualified response to alarms | Contact points to on-call and ticketing channels, with silences limited to documented maintenance windows. Grafana records alert state history, but the response itself is evidenced in your incident process. | Yes for incident handling and response records |
| 3.2.5 log retention, backup and protection from unauthorized change | Grafana stores configuration in MySQL or PostgreSQL, which you back up and restrict. Retention of the underlying log data depends on the data source, so set it in Loki, OpenSearch or your SIEM. Restrict edit rights through authentication and access control. | Yes for log retention, immutability and backup of the log store |
| 3.2.6 synchronized time sources | Grafana timestamps and alert evaluation depend on host clocks. Confirm NTP or equivalent sync on Grafana servers and every data source, and show the sync status in a dashboard. | Yes for host time sync on all monitored systems |
| 3.2.6 redundant monitoring and logging systems | Two or more active-active Grafana servers behind a load balancer sharing a MySQL 8.0 or later or PostgreSQL 12 or later database. Alerting needs extra configuration to avoid duplicate notifications, and Grafana Live has HA limitations, so test failover of alert delivery. | Yes for redundancy of the data source and log platform |
| 3.2.6 independent availability monitoring of the monitoring system | A second system, such as a separate Prometheus or Zabbix instance or an external uptime check, watches Grafana and its data sources and alerts through a different route. Grafana cannot reliably alert on its own outage. | Yes, this must run outside the Grafana stack |
Which Grafana setup fits a NIS2-scoped monitoring stack
A single Grafana server is the simplest pattern and can suit an entity whose monitoring workload is modest and whose tolerance for a monitoring outage is high. The configuration database matters most here. SQLite is not suitable for production, so the instance should use MySQL 8.0 or later or PostgreSQL 12 or later. The Grafana installation docs list packages for Debian and Ubuntu, RHEL and Fedora, SUSE, macOS and Windows, plus Docker images and Helm charts for Kubernetes, so the packaging choice should follow your existing patch and change process. The installation docs size small deployments under 25 concurrent users at 2 cores and 2 to 4 GB of RAM, but your own dashboard and alert load will decide the real sizing.
- Supported database: Run MySQL 8.0 or later or PostgreSQL 12 or later, with backups that cover the Grafana configuration store.
- Packaging path: Choose packages, Docker images or Helm charts that match how your team already patches systems.
- Single point of failure: Record that one node failing stops dashboards and alert evaluation until it is restored.
- Recovery target: Document how long the team can run without Grafana and who restores it.
- Provisioning: Keep data sources, dashboards and alert rules in files so a rebuild does not depend on memory.
Confirm with your auditor and your competent authority whether a single node meets your availability expectations for monitoring, and check your own environment's load before accepting the sizing guidance.
A high availability setup runs two or more active-active Grafana servers behind a load balancer, sharing a MySQL or PostgreSQL database. Database-backed auth tokens let users reach any node. This pattern addresses the redundancy expectation for monitoring systems, but it adds design work that a single node does not need. The Grafana docs note that alerting needs additional configuration to avoid duplicate notifications, and that Grafana Live has limitations in high availability. Duplicate notifications are an operational problem for on-call teams, and an unreviewed alerting configuration can also hide a failed evaluation.
- Shared database: Make the database itself highly available and tested, since both nodes depend on it.
- Load balancer health checks: Configure checks that remove a failed node without hiding the failure from the team.
- Duplicate-notification handling: Test that each alert reaches each contact point once, following the alerting configuration in the Grafana docs.
- Grafana Live limits: Confirm which live features your dashboards rely on before relying on them in high availability.
- Node failure drills: Stop one node during a test window and record what alerts, dashboards and logins did.
Confirm that your load balancer, database and notification path were tested together, and keep the test results as evidence of redundancy.
Point 3.2.6 expects the availability of monitoring and logging systems to be monitored independently of the systems they monitor. A Grafana pair can be redundant and still fail silently if the same network, identity or cluster fails with it. An external check runs outside the Grafana deployment and alerts a team when Grafana stops responding or stops sending notifications. The check itself can be a separate monitoring tool, a hosted service in a different administrative domain, or a small system in another site. The right choice depends on where your Grafana runs and what it would take to lose both.
- Separate failure domain: Place the watcher on infrastructure that does not share the Grafana cluster, network segment or identity provider.
- Heartbeat alert: Use a check that fires when Grafana stops answering or when an expected heartbeat notification does not arrive.
- Independent contact path: Route the watcher's alerts through a channel that does not depend on the Grafana notification chain.
- Clock source: Use synchronized time sources on both sides so timestamps in evidence can be compared.
- Ownership: Name the team that receives watcher alerts and the team that maintains the watcher itself.
Confirm with your security and operations leads where the watcher will run, since an external service may create its own data handling and supplier questions.
Evidence a Grafana setup gives assessors and how to keep it
ENISA's June 2025 guidance lists examples of evidence that show monitoring and alarm thresholds are working in practice. A self-hosted Grafana stack can produce or support several of them, and the cards below cover what to keep, how to version it and where the remaining evidence comes from.
Alarm thresholds as provisioned files
The thresholds an assessor will ask about are the alert rules themselves. Grafana alerting resources can be defined in YAML or JSON files and loaded at startup, so the rule set becomes a reviewable artifact instead of settings clicked together in the interface. Check that the files hold the thresholds, evaluation intervals and the conditions that trigger an alarm, and that the running instance matches them. Grafana also documents Terraform and Git Sync as further as-code options. Confirm which of these your version supports before you rely on one.
Version control for monitoring configuration
Keep provisioning files, dashboard JSON and notification policies in a Git repository with reviewed merge requests. The commit history then shows who changed a threshold, when, and why, which answers the question of whether the alarm logic was controlled. Store secrets such as webhook URLs outside the repository, and make the deployment pipeline the only path that writes to production. Record the approval for each threshold change so that a reviewer can match a change to a ticket.
Records of past alarms
ENISA's examples include records of past alarms, and these need to be kept beyond the current alert state. Grafana shows alert state and history for the period it retains, so decide how long alert history must be kept and export or archive it on a schedule. Confirm with your auditor or competent authority what period they expect, because the NIS2 text sets no fixed retention period. Test that an alarm from a sample date can be retrieved and traced to the rule that fired it.
Notification history and responses
An alarm only shows timely response if the notification reached a person or system and someone acted on it. Keep notification history from the contact points and the incident tool that receives them, and match each alarm to its acknowledgement and resolution. Check that notification policies route alarms to a monitored channel outside the affected system. Sample a few alarms each quarter and confirm the chain runs from threshold, to notification, to a documented response.
Dashboards showing monitored signals
Dashboards show which signals are monitored and whether they stayed within thresholds during a period. Version dashboard JSON with the rest of the configuration so that a dashboard shown to an assessor matches the one that existed at that date. Include the data sources, the time ranges and the threshold lines on each panel. Keep a list of the signals covered and link it to the system inventory, so gaps are visible.
Access records and SIEM sources
Access records show who could view, edit or silence alerts. Use a supported identity provider for sign-in, map roles to teams, and export the audit trail that your Grafana edition provides for administrative changes. Note that SIEM and EDR records, which ENISA also lists, come from those tools rather than from Grafana. Confirm with the owners of those systems what they retain, and reference their records in your evidence index.
Configuring Grafana for NIS2 point 3.2 monitoring step by step
This sequence turns a self-hosted Grafana stack into automated monitoring with defined alarm thresholds, staffed response and an independent check on the monitoring system itself, which is the evidence point 3.2 expects.
Confirm in-scope systems and monitoring signals
Start with the list of network and information systems in scope for your NIS2 obligations, then record which signals each one produces: metrics, system and security logs, authentication events and service health checks. Assign an owner to each system and each signal. Point 3.2.3 expects events that could be incidents to be detectable, so the output is a signed register that maps every in-scope system to the signals Grafana will receive. Confirm the scope with your legal and compliance leads before building anything, because the register becomes the baseline auditors will sample.
Deploy a production database and high availability
Install Grafana on the platform your team operates, using a production database instead of the default SQLite, because the installation docs say SQLite does not scale for production. Choose MySQL 8.0 or later or PostgreSQL 12 or later. Where monitoring must survive a node failure, run two or more active-active Grafana servers behind a load balancer sharing that database, and add the extra alerting configuration the high availability docs describe so notifications are not duplicated. Closing check: stop one node in a test environment and confirm dashboards and alert evaluation continue.
Connect data sources and verify ingestion
Add the metrics, log and event data sources identified in step one, and enable only the ones the register requires. Record the data source configuration in version control so the connections can be rebuilt. For each source, run a query that returns recent data for a known system and confirm the timestamps are current. The output is a short verification log per source showing query, time range and result. Gaps found here usually come from missing agents or forwarding rules, so fix them before writing any alert rule.
Define alert rules and thresholds as code
Write alert rules for the signals that could indicate an incident, such as failed authentication spikes, unexpected configuration changes, resource exhaustion and loss of log flow. Set thresholds from documented baselines, and record the reason for each value. Provision the rules from files loaded at startup, using the Grafana provisioning model, so changes go through review and leave a history. Point 3.2.4 expects alarm thresholds that trigger an alarm, automatically where appropriate, so mark which rules fire automated actions. Confirm by triggering each rule with a test event and capturing the alarm record.
Route notifications to a staffed response channel
Configure notification policies and contact points so every alarm reaches a channel that a qualified person watches during the hours the organization has committed to. Include an escalation path for alarms that go unacknowledged. Point 3.2.4 requires a timely, qualified response, so document who responds to each alarm class and what the first action is. Test the route end to end, including after-hours delivery and the escalation step. The output is a routing table and a test record showing acknowledgement by the named responder.
Monitor Grafana and its data path independently
Point 3.2.6 expects the availability of monitoring and logging systems to be watched independently of the systems they monitor. Set up a separate check, on infrastructure outside the Grafana cluster and its data sources, that tests whether Grafana answers, whether alert evaluation runs and whether data sources return fresh data. Route its failures to the same staffed channel. Also apply the Grafana security hardening settings, including requiring authentication for the metrics endpoint. Confirm by stopping the Grafana service in a test environment and checking that the external check raises an alarm.
Enforce time synchronization and access controls
Confirm that every monitored system and every Grafana node uses a synchronized time source, because log events can only be correlated if their timestamps agree. Restrict who can edit alert rules, data sources and notification policies, and separate those rights from the rights to acknowledge alarms. Protect stored logs and backups from unauthorized access or change, since point 3.2.5 requires this without setting a retention period. Confirm with a time-skew check across nodes and a permissions review that lists each role and its rights.
Document the review cadence and keep alarm records
Set a written schedule for reviewing logs for unusual trends, reviewing alarm thresholds and testing the independent monitoring check. Keep records of each alarm, its response and any threshold change, because ENISA's June 2025 guidance lists configured alarm thresholds and records of past alarms as examples of evidence. Assign the review to named roles and store the schedule with the register from step one. The closing output is a review calendar with completed entries, which shows the monitoring runs as an operating process and not only as a configuration.
What a Grafana stack does not cover for NIS2
Grafana can show that monitoring runs and that thresholds fire, but several point 3.2 duties sit outside the dashboards. The cards below are the areas your organization has to define, staff or assign to another control, and they are where an assessor will look for evidence beyond Grafana itself.
Log retention periods
Point 3.2.5 requires logs to be kept for a predefined period but sets no fixed length. Your organization has to choose the period per log source, document the reason and align it with other obligations such as GDPR storage limits. Grafana's own retention depends on the data source behind each panel, so confirm retention in Loki, Prometheus, or your SIEM rather than assuming a Grafana setting covers it.
Log backup and tamper protection
Logs must be backed up and protected from unauthorized access or change. Grafana dashboards are a view, not a store of record, so the protection usually comes from the log platform, object storage with write-once settings, restricted delete rights and separate administrators. Check who can alter or delete the underlying records, and test restoration from backup.
Qualified human response
Point 3.2.4 expects a timely, qualified response after an alarm fires. A threshold only starts the process. You need an on-call rota, documented triage steps, escalation paths and a record of who acted and when. Grafana can route notifications, but the competence of the responder and the handling of each alert are organizational controls that the dashboards cannot prove.
EDR and SIEM coverage
ENISA's June 2025 guidance lists SIEM systems and EDR or XDR tools among examples of evidence. Grafana visualizes metrics and logs but is not a detection engine for endpoint behavior or correlated security events. Decide which sources feed a SIEM or EDR platform, and confirm that security-relevant log samples with the point 3.2.3 elements reach it.
Independent availability monitor
Point 3.2.6 requires the availability of monitoring and logging systems to be monitored independently of the systems they monitor. If Grafana watches itself, a Grafana outage silences the alarm. Plan an external check, such as a separate Prometheus or Zabbix instance, a cloud health probe or a SaaS heartbeat, that alerts through a path independent of the primary stack. Test it by stopping the primary Grafana instance.
Sector and national rules
NIS2 is a directive, so national transposition laws, sector rules and the regulatory authority's expectations decide how the Implementing Regulation applies to you. Member States may keep or adopt stricter rules under Article 5. Confirm the requirements of your national competent authority and any sector regulator before you fix thresholds or retention. This page does not replace that review.
Proposed amendments under COM(2026) 13
The Commission proposed targeted amendments to NIS2 on 20 January 2026 (COM(2026) 13), including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, so treat it as a proposal and do not design controls around its outcome. Track the legislative progress and reassess scope and obligations once the text is final.
Questions buyers ask about NIS2 monitoring with Grafana
Does NIS2 certify a Grafana monitoring stack?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Your monitoring stack, alert rules and records are evidence you show during that oversight, and the Implementing Regulation 2024/2690 point 3.2 expectations apply to how you run them. For a sense of what assessors look for, the ENISA technical implementation guidance lists examples of evidence such as configured alarm thresholds and records of past alarms. Ask your national authority and your sector regulator which evidence they expect.
How much effort does NIS2 monitoring with Grafana take, and who is needed?
Effort depends on how many systems you monitor, how many alert rules you need, and how much evidence you must keep. Typical roles are a platform or infrastructure engineer who builds and runs the stack, a security engineer who defines which events and thresholds matter, a compliance lead who defines the evidence set, and an on-call owner who handles alarms. Point 3.2 also expects logs to be reviewed regularly and alarms to lead to a timely, qualified response, so the people who answer alarms must be named in your procedures. Ask any partner to break its estimate down by role and by deliverable.
Can our internal team set this up without a partner?
Often yes, if you already run Grafana or similar tooling and have engineers who can write alert rules, manage data sources and operate high availability. The harder parts are usually not the dashboards. They are deciding which signals count as potential incidents, setting thresholds you can defend, keeping monitoring available independently of the systems it watches, and producing records an auditor can sample. A useful test is whether your team can document each alert, its owner, its threshold rationale and its response path, and then prove it works during a drill. An external partner can deliver a fixed-scope build with agreed deliverables, which can be useful if internal capacity is limited.
What drives the cost of a Grafana NIS2 monitoring build?
The main cost drivers are the scope of signals (which systems, logs and metrics feed Grafana), high availability for Grafana and its database, the number of alert rules and notification routes, the integrations you need with logging, identity and ticketing tools, and how much evidence design is required. One-time work includes architecture, build, provisioning and documentation. Recurring costs include platform operations, upgrades, rule maintenance and any Grafana Cloud or Enterprise subscription you choose. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for the quote to list each deliverable, the assumptions behind it and which costs recur.
How long does a Grafana NIS2 monitoring project take?
Duration follows the same drivers as cost: the number of signal sources, whether high availability is required, how many alert rules must be designed and tested, and how many integrations must be validated. Grafana's own guidance notes that high availability needs two or more active-active servers behind a load balancer sharing a MySQL or PostgreSQL database, and that alerting needs extra configuration to avoid duplicate notifications. Plan time for testing alert routing and for a documented drill, not only for installation. Ask for a timeline tied to the written scope and to your change approval process.
Which Grafana edition do we need for SAML or SCIM?
SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, according to the Grafana authentication documentation. Open-source Grafana supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. If your identity provider requires SAML or SCIM, plan for an Enterprise subscription or confirm that OAuth or OIDC can meet your access requirements. Check licensing terms directly with Grafana Labs licensing before you decide, since the AGPLv3 licensing of the core projects affects how you distribute modifications.
How do upgrades and support affect NIS2 compliance?
Compliance depends on keeping the monitoring stack patched and supported. Grafana's upgrade guidance describes major releases once a year, minor releases every other month, and patch releases at least monthly, with each minor release supported for 9 months and the last minor release of a major version for 15 months. Plan a repeatable upgrade routine with testing in a staging environment, and record each change for your evidence. Retainers for ongoing support, upgrades and continuous testing are available from DeployOpen, and the scope of any retainer is agreed in writing. Confirm response expectations and version coverage with the provider before you rely on them.
What does point 3.2 require beyond dashboards?
Point 3.2 requires monitoring and logging tools that detect potential incidents, with automation where feasible, regular log review for unusual trends, and alarm thresholds that trigger alarms followed by a timely, qualified response. It also expects logs to be kept, backed up and protected, time sources to be synchronized where feasible, and monitoring availability to be checked independently. Grafana covers the alerting and visualization layer, but a log platform or SIEM often holds the logs themselves. Confirm with your own assessor which control covers which requirement before you size the build.
Where DeployOpen fits in a NIS2 monitoring project
DeployOpen plans, implements, hardens, documents and supports the self-hosted Grafana stack inside your own cloud accounts, data centers or restricted networks. For NIS2 monitoring, that means designing the alert rules and alarm thresholds for point 3.2.4 of the Annex to Implementing Regulation 2024/2690, configuring the notification routing and the independent monitoring of the monitoring system required by point 3.2.6, and assembling the evidence an assessor will ask for, such as configured thresholds and records of past alarms. DeployOpen can also run retainers for upgrades and continuous testing of the platform after the initial build. Your team keeps ownership of the risk decisions, including which events count as incidents and who is on call to respond.
Scope, deliverables and timelines are agreed in writing before work starts, so the boundary between your team and DeployOpen is settled before any configuration changes. DeployOpen does not issue audit reports, attestations or certifications. NIS2 has no certificate of compliance, and national competent authorities oversee compliance through inspections, security audits and information requests. The evidence DeployOpen prepares supports those reviews, but the assessment itself belongs to the authority or the independent auditor you engage. Confirm with your national competent authority and legal counsel which evidence they expect, since the ENISA guidance of June 2025 is non-binding.
To scope the work, prepare the inputs in advance: the list of systems in scope and their owners, the log sources and data sources you want Grafana to query, the names of the people who receive alarms and their escalation hours, and the existing incident response procedure. You also need to decide where the Grafana database lives (MySQL or PostgreSQL, since SQLite is not suitable for production), who holds administrator access, and where backups and any secondary monitoring node will run. Ask any prospective partner to show how they will test the alerting path end to end and how the written scope handles changes after the build.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Grafana stack, its alert rules and its evidence stay under your control. For NIS2 monitoring, we start from the point 3.2 expectations your authority will test, then configure the dashboards, thresholds and notification paths that answer them.
How we scope
- Map your in-scope systems, log sources and monitoring tools against the point 3.2 expectations before any configuration starts.
- Agree in writing which alarm thresholds, dashboards and notification routes are in scope, along with the deliverables and timeline.
- Confirm with your team which controls stay in Grafana and which need a SIEM, log platform or other tool to cover them.
How we build
- Deploy Grafana with MySQL or PostgreSQL as the configuration database, sized for your user count and high availability needs.
- Define data sources, dashboards and alert rules as provisioned files so changes are versioned and reviewable.
- Test alarm thresholds against known conditions and confirm notifications reach the responders you name, out of hours included.
How we hand over
- Document each alarm threshold, its rationale, its owner and the response expected when it fires.
- Set up monitoring of the Grafana instance itself so a failure in the monitoring system is noticed independently.
- Provide a walkthrough and runbook so your team can review alert records and evidence without relying on us.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Track Grafana releases and plan upgrades against the supported minor and patch cadence your team can absorb.
- Review threshold and routing changes periodically so the configuration keeps matching your systems and your authority's expectations.
