Grafana for energy and utilities: why operators self-host it inside the control network
Energy and utility operators should self-host Grafana inside their own control network because dashboards over SCADA historians, network telemetry and control room data are only useful if the data never leaves the perimeter that the operator already protects. Grafana connects to data sources rather than copying them into a vendor's cloud, so the monitoring layer can sit beside the historian, the metrics store and the log platform on infrastructure the utility controls. Grafana Labs relicensed Grafana from Apache License 2.0 to AGPLv3 on April 20, 2021, and Grafana Enterprise is offered as a non-AGPL commercial option. An operator should have its legal and procurement team confirm which edition and license terms fit its own use, including any modifications it plans to make and distribute.
A generic Grafana deployment does not account for how energy systems are classified. Before any data source is connected, the operator should decide which assets fall under CIP-002-5.1a impact categories (high, medium or low) and which monitoring paths touch BES Cyber Systems or their associated access control and monitoring systems. A Grafana server that reads from a medium impact system may itself need to sit inside an Electronic Security Perimeter, and any remote access to it must follow the rules set out in CIP-005-7. Access separation also changes: operators usually split operations, engineering and corporate viewers into different organizations or folders, and they confirm with their compliance team whether the Enterprise authentication features, such as SAML and team sync, are required to enforce that split.
Evidence is the third difference. Auditors under the CIP standards look for documented configuration, access records and change history, so the operator should plan how Grafana's provisioning files, backups of its database and its audit trail will be kept under version control and retained. The operator should ask its compliance lead which of its Grafana controls will count as evidence for each applicable standard, and then confirm that with the Regional Entity or auditor that will review them. DeployOpen can plan and implement that setup in your infrastructure, but the classification decisions and the audit conclusions remain with your organization and the auditor.
Which energy regulations shape a Grafana build, and what each means for the design
This table maps each energy regulation or standard to the design decision it changes in a self-hosted Grafana stack, including server placement, access paths and software verification. Read each row alongside your own impact rating and regulatory scope, because applicability must be confirmed by your entity and not assumed from this summary.
| Requirement | What it asks for | Design consequence for Grafana |
|---|---|---|
| NERC CIP-002-5.1a impact rating | Sorts BES Cyber Systems into high, medium or low impact using bright-line criteria | Confirm the rating first, since it sets which Grafana components fall in scope and how tightly they are isolated |
| CIP-005-7 Electronic Security Perimeter | Routable-connected high and medium impact assets sit inside an ESP, and interactive remote access passes through an Intermediate System with encryption and MFA | Place Grafana servers and their database inside the perimeter or document why they are associated systems; route all remote viewer and admin access through the Intermediate System |
| CIP-013-2 supply chain risk management | Plans covering vendor incident notification, vulnerability disclosure, software integrity verification and vendor remote access, reviewed at least every 15 calendar months | Pin and verify Grafana, plugin and Helm or container artifacts from approved sources, and record vendor access to the stack in the supply chain plan |
| CIP-015-1 internal network security monitoring | Approved by FERC on 26 June 2025, enforceable from 1 October 2028 (NERC CIP standards page) | Plan dashboards and data source connections so network telemetry can feed the monitoring program before the enforcement date, and confirm whether your systems fall within its scope |
| CIP-015-2 extension (EACMS and PACS) | Extends monitoring to associated EACMS and PACS, approved by FERC on 10 August 2026, effective 1 October 2029 | Treat access control and physical security systems as future monitoring sources and size retention and data source connections with that scope in mind |
| CIP-012-2 real-time data availability | Protects availability of Real-time data between Control Centers, enforceable from 1 July 2026 | Design Grafana dashboards that read real-time data paths for Control Centers with alerting and redundancy, and confirm the data flows that the standard covers |
| NIS2 energy sector scope | Annex I lists energy, including electricity, district heating and cooling, oil, gas and hydrogen, as a high-criticality sector (Directive (EU) 2022/2555) | Confirm whether your organization is in scope and under which national transposition, then apply incident reporting and supply chain expectations to the Grafana stack and its vendors |
| Commission Delegated Regulation (EU) 2024/1366 | Network code on sector-specific cybersecurity rules for cross-border electricity flows, published 24 May 2024 | If you operate cross-border electricity flows, confirm which cybersecurity obligations apply to monitoring tools and whether your transmission operator requires specific controls |
Which Grafana modules, settings and integrations matter for grid and plant monitoring
Six decisions shape a Grafana deployment for grid and plant monitoring: where the server sits, what database holds its state, how people sign in, how configuration is kept, which data sources are connected, and how alerts are delivered. Each one touches a monitoring system that regulators and asset owners will expect to be controlled, so settle them together before the first dashboard is built.
Server placement relative to the perimeter
Decide whether the Grafana server sits inside the Electronic Security Perimeter or outside it, and what crosses the boundary. CIP-005-7 requires routable-connected assets of high and medium impact BES Cyber Systems to sit inside an Electronic Security Perimeter, and all Interactive Remote Access to pass through an Intermediate System. A Grafana instance that reads control-network data is part of that design, so document every data flow across the boundary and confirm with your compliance team how the instance is classified before deployment.
Production database backend
Use MySQL or PostgreSQL for configuration storage rather than the SQLite default. Grafana's installation docs state that SQLite does not scale for production, and high availability requires a shared MySQL or PostgreSQL database. Supported versions are MySQL 8.0 or later and PostgreSQL 12 or later. Plan the database inside the same asset boundary as Grafana, include it in your backup scope, and confirm that its backup and restore process is tested.
Identity provider sign-in
Connect Grafana to the utility's existing identity provider so operators sign in with their assigned accounts. Generic OAuth, Entra ID, Okta and LDAP are available in every edition, while SAML, team sync, active sync and SCIM provisioning require Grafana Enterprise or Grafana Cloud. If your access review depends on automated deprovisioning through SCIM or SAML group mapping, price the Enterprise edition into the scope, and confirm the chosen protocol with your identity team before the build begins.
Provisioning as code
Define data sources, dashboards, plugins and alerting resources in YAML or JSON files that Grafana loads at startup, so the production configuration can be reviewed, versioned and rebuilt. Grafana also documents Terraform and Git Sync as as-code options. For a utility, this gives change records that an auditor can trace, and it makes restoring a failed control room instance a matter of redeploying files rather than clicking through screens. Keep credentials out of these files and load them from a secrets store.
Historian and time-series data sources
Connect Grafana only to the historians and time-series stores that operations genuinely need, and use read-only database accounts for each one. Common targets include plant historians, SQL databases and time-series platforms reached through built-in or plugin data sources. Each connection is a path from the monitoring network toward operational data, so list the source, the account, the network route and the query types allowed. Confirm each data source plugin is supported in your Grafana version before it is added to production.
Alerting and high availability
Plan alert routing for an active-active pair before enabling it. Grafana's high availability setup uses two or more Grafana servers behind a load balancer with a shared database, but the docs note that alerting needs additional configuration to avoid duplicate notifications, and Grafana Live has limitations in HA. Test that a single grid alarm reaches the operator once when one node fails, and document which node sends notifications. Confirm this behavior in your target version before relying on it for operational alarms.
How the build differs across control centers, generation plants and substations
Control centers are where the high impact context usually sits. CIP-002-5.1a places high impact BES Cyber Systems mainly at qualifying control centers, so a Grafana instance that displays or stores their data should be designed with the same care as the systems it observes. Confirm with your compliance team whether the Grafana host falls within any applicable systems table before the architecture is approved.
- Network path: Run Grafana inside the Electronic Security Perimeter defined for the control center, reading from a historian or data replica on the boundary. Confirm whether any direct query to live control system networks is allowed in your design.
- High availability: Plan two or more active-active Grafana servers behind a load balancer on MySQL or PostgreSQL. Alerting needs extra configuration to avoid duplicate notifications, and Grafana Live has limitations in HA, so test the display features you depend on.
- Display walls: Drive wall screens from kiosk workstations with read-only accounts and dashboards that have no write paths. Test refresh behavior under expected load before commissioning.
- Updates: Stage each patch and minor release in a test environment that mirrors production. Patch releases arrive at least monthly, so the change process must be quick enough to apply them and controlled enough to satisfy change management.
- Access model: Use enterprise identity through LDAP or generic OAuth, which all editions support. Interactive remote access must pass through an Intermediate System with multi-factor authentication under CIP-005-7. SAML requires Grafana Enterprise.
Confirm with your registered entity which CIP-002 category and applicable systems table cover the control center and the Grafana host.
Generation plants are often medium impact when they meet a bright-line criterion, such as generation of 1500 MW or more at one plant under CIP-002-5.1a. Below that threshold or in a low impact arrangement, the controls differ, so the classification is the first decision. Plant monitoring usually reads local historians and must keep working when the wider network is unavailable.
- Network path: Read from the plant historian or a local replica on the plant network. Avoid routable connectivity to corporate or cloud sources unless the connection passes through a documented boundary that your compliance team has reviewed.
- Local reads: Configure data sources so dashboards keep showing plant data during a WAN outage. Test this as a failure scenario rather than assuming it works.
- Offline update path: Mirror Grafana packages for your operating system or Docker images into an internal repository, then move them through your approved transfer process. Verify checksums and plugin provenance before installation, and keep the plugin set fixed between releases.
- Access model: Use local directory accounts through LDAP where the plant has a directory. Document a sealed break-glass administrator path and avoid shared operator accounts.
- Sizing: The installation docs size small deployments under 25 concurrent users at 2 cores and 2 to 4 GB of RAM, a reasonable starting point for a single-node plant instance. Measure actual use before settling on final capacity.
Confirm with your compliance team whether the plant's asset class is medium impact, low impact or outside BES Cyber Systems, because that decides which CIP requirements reach the Grafana host.
Corporate and enterprise networks host business systems such as enterprise resource planning, work management, outage ticketing and market or customer systems. Monitoring these in Grafana helps operations understand dependencies, but the data path into operational networks is where risk concentrates. Define the boundary first, then decide what data is allowed to cross it.
- Network path: Place Grafana in the IT zone and pull from business APIs and databases. Any feed toward operational data should use a tightly scoped integration reviewed as part of the perimeter design.
- Identity: SAML, team sync and SCIM provisioning are available only in Grafana Enterprise, so the edition choice should follow from your identity requirements. OAuth through Entra ID or Okta works on the open-source edition.
- Updates: Apply your standard IT patch cadence. Minor releases arrive every other month and patch releases at least monthly. Provision dashboards and data sources as code so rebuilds are repeatable.
- Vendor and supply chain: If a vendor or integrator has remote access to the stack, the supply chain expectations in CIP-013-2 apply when the system is in scope. Keep a record of the source of every plugin and package.
- Scope check: Corporate systems are often outside BES Cyber Systems, but any system that can affect operational systems, including historians, may not be. Map every data flow before assuming exclusion.
Confirm which corporate systems feed operational decisions and whether any data path crosses an Electronic Security Perimeter, since that changes the classification of both ends.
How a Grafana rollout for an energy operator is sequenced
The sequence starts with classifying assets and impact, then fixes the trust boundary and proves the build in a test environment before any operator-facing display goes live. Each phase closes with evidence the compliance team can review, and the schedule follows the written scope.
Classify assets and impact with compliance
DeployOpen works with your compliance team to inventory the systems the Grafana stack will touch and decide which ones fall under CIP-002-5.1a impact categories. The team confirms which data sources are in scope, whether any BES Cyber System data is involved, and which Regional Entity or internal owner signs off. The step closes with a signed scope register listing each data source, its owner and its impact classification, so later design choices trace back to a documented decision.
Review architecture and trust boundaries
Engineers map where the Grafana server, its database, the load balancer, plugins and any image rendering service will sit relative to the Electronic Security Perimeter and any Intermediate System used for remote access. The review covers which network paths carry queries, alert notifications and outbound traffic, and where authentication is enforced. The output is an annotated architecture diagram and a list of approved flows that your security team has accepted in writing.
Build a test environment that mirrors production
DeployOpen builds a non-production Grafana instance inside your restricted network with the same version, database engine, proxy layout and plugin set planned for production. Test data sources point at historian replicas or recorded exports rather than live control systems. The step is done when the test instance passes a documented smoke check covering login, dashboard load, alert evaluation and backup restore, and the results are recorded for the change file.
Configure provisioning and enterprise authentication
Data sources, dashboards and alerting resources are defined as provisioning files or as-code assets kept under version control, so the production configuration can be reproduced and reviewed. Sign-in is set up through your identity provider, with SAML, team sync and SCIM only where your licensing supports them. Role mappings are tested against named test accounts. Completion means the provisioned configuration deploys cleanly from version control and every role matches the access model approved in the first phase.
Validate data sources against historians
Each data source is tested for query correctness, time alignment, timezone handling and retention behavior against the historian or log platform it reads from. Engineers confirm that queries are read-only, that credentials are scoped, and that long-range queries do not load the source system beyond agreed limits. The step closes with a validation table per data source showing expected and observed values, signed by the operations owner.
Release controlled displays and alerts
Operator dashboards, control room displays and alert rules move to production through a change window agreed with operations. Displays are deployed in read-only mode, with kiosk or shared access configured as your access model requires, and alert routing is confirmed against on-call contacts. A rollback path is rehearsed before release. The step is complete when a test alert reaches the intended recipient, and the display behaves as validated in the test environment.
Hand over runbooks and compliance evidence
DeployOpen delivers runbooks for backups, restores, patching, upgrades, access reviews and incident response for the Grafana stack, along with the configuration baseline, change records, validation tables and access review results. Your team runs a hands-on session to perform a restore and a version upgrade in the test environment. DeployOpen does not issue audit reports; the evidence package is what your compliance team and any independent assessor review. The handover closes when your owners accept the runbooks and the evidence index in writing.
Compliance considerations for monitoring systems in energy
A Grafana stack can produce some of the records that CIP and NIS2 reviewers ask about, such as configuration history, alert records and access trails. Many other controls, including the perimeter, vendor risk program and network monitoring, sit in other systems, and the cards below separate the two.
Configuration as code and version history
Data sources, dashboards and alert rules can be defined in files loaded at startup, which gives you a reviewable record of what the monitoring system was set to do. Store those files in a version control system with reviewed changes, so a change to an alert threshold or a data source has an author, a date and an approval. Confirm with your Regional Entity or auditor which change records they expect to see, because the file history alone rarely answers questions about who approved a change.
Alert records and notification history
Grafana Alerting can show when rules fired, how notifications were routed and which contact points received them. Those records help show that abnormal operating conditions were noticed and escalated. They do not show that operators acted on them, so pair them with your shift logs or ticketing system. Test that alerts still fire after upgrades and failovers, and keep a dated copy of the rule set that was active at each point in time.
User access and sign-in records
Grafana records authentication and administrative actions at the level your edition and identity provider allow. SAML, team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so an open-source deployment relies on LDAP, OAuth or proxy-based sign-in and on your directory for joiner and leaver control. Document who can edit dashboards and data sources, and confirm how access reviews will be produced from directory records.
Perimeter controls for routable assets
Where Grafana reads from control system networks, CIP-005 expects high and medium impact BES Cyber Systems with routable connectivity to sit inside an Electronic Security Perimeter, with interactive remote access passing through an Intermediate System that uses encryption and multi-factor authentication. Grafana does not provide that boundary. Your firewalls, jump hosts and remote access tooling must. Place the Grafana server, its database and its data source connections on the defined side of the perimeter, and confirm the scoping with your compliance team before deployment.
Vendor risk and supply chain program
CIP-013 expects a supply chain risk management plan covering vendor incident notification, vulnerability disclosure, software integrity verification and coordination of vendor remote access, reviewed at least every 15 calendar months. Grafana's release notes, patch cadence and plugin signatures feed that plan, but the plan itself is an organizational document. Keep a record of how each Grafana release and plugin was verified before installation, and name the owner who reviews vendor advisories.
Network monitoring and incident reporting
CIP-015-1 covers internal network security monitoring, and it is enforceable from 1 October 2028. Grafana can visualize the output of a network monitoring tool, but it does not collect traffic itself, so choose and document that tool separately. NIS2 incident reporting follows its own timelines and is handled through your national authority, not through dashboards. Confirm which of your monitoring signals must feed those reporting processes and who is authorized to make the notification.
Questions utilities ask before a Grafana implementation
What drives the cost of a Grafana implementation for a utility?
The cost depends on the number of data sources, how many restricted network zones the stack must reach, the number of dashboards and alert rules to rebuild, and the compliance evidence the work must produce. Fixed-scope work is priced from a written scope, so ask each quote to separate one-time build effort (architecture, database and high availability design, identity integration, provisioning as code, data source connections, dashboard migration) from recurring items (patching, upgrades, backups, retainers). Ask whether the quote includes plugin vetting and whether historian or SCADA-adjacent data sources need separate access approvals, since those often add the most effort. The licensing choice also affects cost, covered in the Enterprise question below.
Can our internal team build a Grafana stack without a partner?
Often yes, if the team has Linux, database and container operations skills and time to own the stack after handover. The open-source edition installs on Debian, Ubuntu, RHEL, Fedora, SUSE and other platforms, and Docker images and Helm charts are available. The harder parts for utilities are usually outside the install: running high availability with a shared MySQL or PostgreSQL database, connecting to historians and OT-adjacent sources through approved paths, and producing change records and evidence that a compliance audit will accept. Assess these honestly against your staff. A partner can cover part of the work, such as the architecture review or the build, while your team keeps operational ownership.
How long does a Grafana rollout for a utility take?
The duration follows the scope, not a standard timeline. A single control room display set on an existing, reachable data source is a much smaller job than a multi-site rollout with high availability, several restricted network zones, an identity provider integration and a migration of existing dashboards and alert rules. Ask for the phases in the written scope and the approvals each phase depends on, such as network change requests, data source owner sign-off and security review of plugins. Those approvals, rather than the build itself, usually set the calendar. No fixed duration is given here because none has been researched for this work.
What do we need to provide before the work starts?
Plan to provide the inputs the design depends on:
- An asset and data source list covering historians, SCADA-adjacent databases, time series stores, logs and network monitoring tools, with the owner of each
- Network diagrams showing zones, firewalls, jump hosts and where Grafana would sit relative to the control environment
- Read-only service accounts and the approved access paths for each source, agreed with the system owners
- Access to your identity provider, with the administrators who can register applications
- Named contacts for historian owners, OT security and change management
- The existing dashboards, alert rules and their notification routes, so they can be inventoried and migrated
Missing inputs are the most common reason an estimate changes after kickoff, so ask for a list of inputs in the scope document.
Do we need Grafana Enterprise for SAML and team sync?
Only if you need those features. Grafana's authentication docs state that all editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT, while SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. Many utilities run SAML-based identity providers, so confirm your provider can use OIDC or LDAP as an alternative before choosing a license. Grafana Enterprise is a commercial option that is not licensed under the AGPL. Its price is not published on the sources used here, so request a written quote from Grafana Labs and compare it with the cost of an OIDC-based design.
How do Grafana upgrades and release cadence affect a regulated stack?
Grafana's upgrade guidance describes major releases once a year in April or May, minor releases every other month and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months. For a utility, this means a change process must absorb patch releases regularly and plan major upgrades around data source and plugin compatibility. Ask how the work will test upgrades in a non-production environment, record the change, and keep the configuration in version control through provisioning. The compliance mapping should then show how patching evidence is produced for each release.
How long retention of time series changes the Grafana design
The retention period for operational time series and audit evidence is the first design input for a utility's Grafana stack, and it should come from the utility's compliance obligations and engineering needs, not from whatever default a tool ships with. Grafana itself does not hold metric or log data. It queries the stores you connect, so retention is decided by the data sources behind it. Before choosing between a time series database, a log platform or an object-storage-backed store, confirm with compliance and engineering how long each class of data must stay queryable, how long it must be kept as evidence, and who may read it. A CIP-related evidence question and a trend-analysis question for planners often need different answers.
Those answers drive storage sizing and the split between an operational store and a long-term archive. A short window of high-resolution data supports control room and troubleshooting dashboards, and it can sit on fast local storage. Older, downsampled series or retained event records usually move to cheaper storage. Ask your data source owners what downsampling, compaction and tiering they support, and whether a query over the archive returns the same results as the operational store. Also confirm where the Grafana configuration database sits, because dashboards, alert rules and provisioning files are not time series and need their own backup and recovery plan. The configuration store must be MySQL or PostgreSQL in production, not SQLite, according to the Grafana installation docs.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Grafana inside the operator's own infrastructure, including restricted and segmented networks. Work starts from a written scope that sets out which data sources, dashboards, alert paths and compliance evidence the stack must support.
How we scope
- Map which grid, plant or network data sources feed Grafana and which network zones they sit in.
- Identify the systems in scope for NERC CIP or NIS2 and which monitoring evidence each needs.
- Agree retention periods, user groups, control room display needs and the upgrade approach in writing before work starts.
How we build
- Deploy Grafana with a production database, not SQLite, and a high availability design if uptime requires it.
- Define data sources, dashboards and alerting resources as code so changes are reviewed and repeatable.
- Configure identity, access control and secrets handling for the zones where the instance runs, and test each control.
How we hand over
- Document architecture, network paths, data source connections, provisioning files and backup and restore steps.
- Provide runbooks for alert routing, shift displays, plugin control and the upgrade process.
- Deliver the compliance evidence list so the operator's auditors can see which controls the monitoring stack covers.
How we support
- Offer ongoing support, patching and upgrades as a retainer, aligned to the Grafana release schedule.
- Plan and test each upgrade against the operator's data sources, plugins and offline update process before rollout.
- Review access, hardening settings and monitoring coverage as CIP or NIS2 obligations change, under a separate written scope.
