Why Apache Superset for energy and utilities needs a scope decision first
A utility analytics lead usually wants dashboards across grid, asset and customer data at once, but some of that data sits inside or next to BES Cyber System boundaries. Apache Superset fits when the deployment runs on infrastructure you control and its data path is designed around those boundaries from the start. The scope decision comes first: which datasets are read by Superset, which network zone hosts it, and who can reach it. Superset is licensed under the Apache License 2.0 and has no paid edition, so the software itself carries no license fee. The cost and risk sit in the work around it: hosting, identity, database connections, and the controls your compliance team will ask about.
A utility differs from a generic deployment in three places. First, every data source needs a documented classification, because a meter feed, a SCADA historian extract and a customer billing table do not belong in the same Superset environment by default. Second, network placement decides what Superset can query: its metadata database, cache, and Celery workers all need to sit in a zone the reliability program has approved, and the Superset architecture documentation describes the components you will need to place. Third, geospatial maps for substations, feeders and outage areas add tile sources and data that must be checked against the same classification.
Confirm these points with your compliance and OT security teams before any build begins: the impact rating of each source system, whether any dashboard reads OT data directly or through a copy, and which tile or map services would reach outside the perimeter. Compliance outcomes depend on your own controls and an independent assessment, and DeployOpen prepares the Superset side of that evidence without issuing it. Write the scope decision down as a short data flow diagram, and use it to decide which datasets Superset may query before anyone builds the first chart.
Which energy and utility requirements shape the Superset build
This table maps the energy and utility obligations most likely to affect a Superset deployment to the design decisions they create. Read each row as a question to settle with compliance counsel before architecture work starts, since applicability depends on how your assets are classified. The main takeaway is that the classification of your BES Cyber Systems, not the Superset software itself, determines how tightly the platform must be isolated.
| Requirement | Source | What it means for the Superset build |
|---|---|---|
| NERC CIP applicability and impact classification | CIP-002-5.1a; NERC Rules of Procedure, Section 400 | Confirm whether any dashboard data or the Superset host touches a BES Cyber System. If it does, its impact rating (high, medium or low) sets the controls the platform inherits. |
| Electronic Security Perimeter for routable assets | CIP-005-7 | If Superset reads from or sits near high or medium impact systems, keep it outside the operational network and feed it through a one-way or controlled data path. |
| Interactive Remote Access to Superset | CIP-005-7 | Administrator and analyst sessions into Superset must pass through an Intermediate System with encryption and multi-factor authentication. Plan this access path before go-live. |
| Vendor supply chain obligations | CIP-013-2 | Software integrity checks, vulnerability disclosure, vendor remote access and a review at least every 15 calendar months must be documented for each component, including Superset and its database drivers. |
| Information protection for BES Cyber System Information | CIP-011-3 | Dashboards, exports, cached query results and logs can carry protected information. Define which datasets may be published and how exports and caches are controlled. |
| NIS2 Annex I energy coverage for EU entities | Directive (EU) 2022/2555 | Energy, including electricity, district heating and cooling, oil, gas and hydrogen, is listed as a high-criticality sector. Confirm your entity classification and national transposition before scoping. |
| Cross-border electricity flow cybersecurity | Commission Delegated Regulation (EU) 2024/1366 | If your operations cross EU borders, confirm whether this network code applies to any data or systems Superset will serve. This is a scope question for counsel. |
| Civil penalty exposure | 18 CFR 385.1602; NERC Rules of Procedure | Penalties apply per violation per day. Dashboard exposure of protected data is a risk that justifies documented access reviews and logging from the first build. |
How Superset components sit inside a utility network
The placement decision starts with one rule: keep the Superset web application and its connections on the corporate side of the boundary, and never let Superset sit inside an OT network. Superset is a Flask and React application backed by a metadata database (for dashboards, charts, users and roles), an optional caching layer, and optional Celery worker and beat processes, as described in the Superset architecture documentation. Analysts reach the web application from the corporate network. The application then queries analytical copies of grid, asset and customer data in a data warehouse or historian replica. Live SCADA or EMS systems should not be exposed to it as query targets. Your team should confirm which data reaches the warehouse, through which one-way or controlled transfer, before any dashboard is built on it.
The caching layer and Celery workers are what make alerts, scheduled reports, async queries and dashboard thumbnails work, according to the same architecture documentation, and most installations use Redis and Celery for them. Each of these components opens its own connections, so each needs a documented network path. Workers must reach the warehouse and the metadata database, and they must be able to send reports or alert messages outward, which often means a controlled relay rather than direct internet egress. Place the workers in the same zone as the web application, not in the OT zone, and size and monitor the queue so a stalled report does not block interactive use. Ask your architecture team to write these flows down before the design review, because they will be the first items an auditor or a utility security reviewer asks about.
The metadata database should be PostgreSQL or MySQL in production. The SQLite default used by Quickstart and PyPI installs, and the PostgreSQL container in the Docker Compose file, are not recommended for production in the architecture documentation. The Superset configuration documentation lists supported versions as PostgreSQL 10 to 17 and MySQL 5.7 and 8.x, so confirm the version you deploy falls within that range and that your database team can back it up and restore it. Keep that database in the corporate zone with its own backups, and treat its contents, which include user records and connection definitions, as sensitive. Your team should decide early which database platform it already operates and supports, because adding a new database engine to a utility's estate usually carries more review effort than the Superset install itself.
Which Superset modules and settings matter for utility dashboards
Utility dashboards mix grid, asset and customer data with sensitive operational context, so the choices that matter most are about where Superset runs, who can query what, and how its background services reach the data. The cards below cover the modules and settings that decide those answers before the first dashboard is built.
Geospatial maps and tile sourcing
Map charts for substations, feeders and outage areas depend on where map tiles are fetched from. A browser that calls an external tile server reveals asset locations to a third party and may fail on isolated networks. Confirm which map tile options your Superset version supports offline, whether you can host tiles inside your network, and which geographic data may leave the control environment before any asset layer goes live.
Row level security by region or operating company
Utilities often run several operating companies, districts or service territories on shared data. Row level security filters each dataset by a rule such as territory or company code, so a regional planner sees only their area. Test each rule with real user accounts from every group, and confirm that charts, saved queries and exports all respect the same filter.
OAuth2 or LDAP with AUTH_ROLES_MAPPING
Superset can authenticate users through OAuth2 providers or LDAP, and AUTH_ROLES_MAPPING translates directory groups into Superset roles. Map the groups your utility already uses for control room, engineering and customer service staff, and keep privileged operational groups separate. Review group membership on a schedule, because a role granted through a directory group persists until that group changes.
SECRET_KEY and PREVIOUS_SECRET_KEY rotation
Superset requires a user-specified SECRET_KEY before it starts, and PREVIOUS_SECRET_KEY lets you rotate it without breaking existing sessions and encrypted values. Store both in your approved secrets system rather than in a configuration file in source control. Plan rotation as a documented change with a named owner, and confirm how your utility's cyber security program records that change.
Database connections on read replicas or historian copies
Superset should query a read replica of the operational database or a copy of the historian, never a live control system. Create a dedicated database user with read-only privileges and restrict it to the schemas each dashboard needs. Confirm with the operations team which systems sit inside the trust boundary before any connection is added, because a dashboard query can load a database that also supports operations.
Reports and alerts through workers inside the boundary
Scheduled reports, alerts and async queries run through the caching layer and Celery workers, so those components must sit inside the same trust boundary as the data they read. Confirm where workers run, where Redis stores results, and where report files are delivered. Keep outbound email and chat destinations approved, because a scheduled report can carry asset or customer figures out of the environment.
On-premises, air-gapped or utility cloud: choosing where Superset runs
An on-premises data center keeps Superset, its metadata database, cache and workers on hardware the utility owns, usually inside the corporate network or a dedicated analytics zone. The utility controls the hosts, storage and network paths, which suits teams that already run PostgreSQL, Redis and Linux servers under change control.
- Image and package sourcing: Superset is Apache-2.0 licensed and distributed as a PyPI package and container build, so the utility must decide where it pulls artifacts and mirror them into its internal repositories.
- Patching cadence: The utility owns the schedule for applying Superset releases, base image updates and operating system patches, and must test each upgrade in staging first.
- Warehouse access: Superset connects to analytics databases over network paths the utility opens, typically through service accounts with read-only privileges and firewall rules limited to specific ports.
- Kubernetes option: If the utility runs Kubernetes on premises, the 6.1.0 Helm chart documentation applies to that version, but the current development documentation marks the chart as deprecated and points new installs to the alpha Kubernetes Operator, whose API may change between releases.
- Utility team duties: Staff must cover hosting, backups, certificates, monitoring and on-call support.
Confirm with your platform team which Superset version and deployment method your standards will approve before selecting the hosting model.
An air-gapped or restricted network has no direct route to the internet, so every package, container image, documentation set and vulnerability feed must cross a controlled transfer process. This environment is common for control-system-adjacent analytics and for utilities whose security policy limits outbound connections from the enterprise zone.
- Image and package sourcing: Artifacts are downloaded outside the enclave, verified, and imported through an approved media or diode process, with checksums recorded for each release.
- Patching cadence: Patches arrive in batches on the utility's transfer schedule, so the team must track Superset release notes and security advisories and plan for delays between a release and its installation.
- Warehouse access: Only internal database endpoints are reachable, so connections must be confined to approved hosts and ports, and any dependency on external services such as map tile providers or identity services must be replaced with internal equivalents.
- Kubernetes option: Mirroring the Helm chart or Operator images and their dependencies into an internal registry is required, and the Operator's alpha status makes version pinning and rollback testing more important.
- Utility team duties: Staff must own the transfer workflow, internal registries, offline documentation copies and evidence that each import was reviewed.
Confirm the transfer process and its lead time with your security team before you commit to a release calendar.
A utility-controlled cloud account places Superset in a cloud subscription or tenancy that the utility administers, with its own network boundaries, key management and logging. The utility keeps data control and governance while using managed networking and compute that its cloud team already operates.
- Image and package sourcing: Container images and packages are pulled into the utility's private registry, and the team should confirm which regions and registries its policies allow before deployment.
- Patching cadence: The utility sets the schedule for host, container and Superset upgrades, and should align it with its change management windows and vulnerability management process.
- Warehouse access: Connectivity to on-premises or cloud warehouses runs over private links, VPN or peering that the utility's network team approves, with service identities scoped to read-only access.
- Kubernetes option: Managed Kubernetes can host the Superset components, but the team must decide between the Helm chart documented for 6.1.0 and the Operator, and should prefer whichever has a documented upgrade path for the version it will run.
- Utility team duties: The utility must provide account administrators, network engineers, key management ownership, and logging and retention settings that meet its records rules.
Confirm with your cloud governance team which services and regions are approved for operational analytics data before choosing this option.
How a utility rollout of Superset usually runs
The sequence moves from classifying data by grid impact and OT boundary to a piloted, operated deployment with a documented upgrade path. Each phase produces a written decision or test result that the next phase depends on.
Classify data sources by impact and OT boundary
Start by inventorying every dataset you want in Superset and labeling where it originates: enterprise systems, historians, SCADA-derived stores, customer information or GIS. Compliance and security staff, with operations engineers, assign each source a boundary zone and confirm whether any BES Cyber System information is involved, since that determines which CIP controls apply. The step is done when each source has a recorded owner, impact classification and an agreed rule on whether it may leave its zone. Ask your compliance lead to confirm these classifications against your own CIP-002 asset list before any connection is made.
Agree dashboard and access scope in writing
Define which dashboards, charts and maps will exist, who will view each one, and which users may export data or see unaggregated records. Operations, planning, customer service and compliance teams usually have different needs, so write them down as separate use cases. The output is a signed-off access matrix that maps each group to datasets, row-level filters and export permissions. Confirm the scope with the data owners before building, because changes after the build tend to touch roles, datasets and tests at once.
Build the analytics zone and data path
Place Superset and its metadata database in the analytics zone your architecture defines, separate from control networks, and create the data path that carries only approved data into it. This usually means read-only database accounts, replicated or curated tables instead of live operational connections, and firewall rules that permit only the required ports. The step is complete when the network team can show the allowed flows and a test account cannot reach systems outside the agreed path. Superset's metadata database should be PostgreSQL or MySQL in production, since the SQLite default is not recommended for production use.
Configure identity, roles and row-level security
Connect Superset login to your directory or identity provider, map directory groups to Superset roles, and apply row-level security so that regional or asset-owner users see only their own data. Set the SECRET_KEY deliberately, because Superset requires one to start, and document how it will be rotated. The check is a test matrix of user accounts showing that each role sees the expected rows, cannot open unapproved datasets and cannot export restricted data. Keep the test results as evidence for your access review.
Test the full stack in staging
Deploy the same configuration, versions and network rules in a staging environment that mirrors production as closely as your architecture allows. Run functional tests on dashboards, maps and scheduled reports, then test failure cases such as a lost database connection, an expired session and a blocked network path. Include security tests for role boundaries and SQL execution limits. The step ends with a written test record and a list of defects resolved or accepted by the data owners. Upgrade and rollback steps should also be rehearsed here so that production changes follow a tested procedure.
Run a pilot with one operating group
Release the platform to a single operating group, such as one regional planning or asset performance team, with a defined list of dashboards and a named support contact. Collect feedback on data accuracy, load on the source databases, map performance and the clarity of access rules. Watch query activity to confirm it does not burden operational databases during peak use. The pilot is complete when the owner accepts the dashboards, load tests show acceptable behavior and any access gaps found are fixed and retested. Expansion to other groups should repeat the access review rather than assume the pilot's configuration covers them.
Operate with a documented upgrade path
Before each Superset upgrade, back up the metadata database, then run superset db upgrade and superset init as the upgrade guide describes. Read UPDATING.md for breaking changes between the versions involved and rehearse the upgrade in staging first. Keep a written runbook covering backup restoration, secret key rotation and rollback. The step produces an operating record that compliance and security teams can review, including change tickets, test results and the date each version was deployed. Confirm with your vendor or internal team which release line you will follow, since pre-release builds should not reach production.
Compliance considerations auditors will ask about
Utilities and energy firms face auditors who test boundaries, vendors, data handling and reporting obligations, often under more than one regime. The cards below cover the questions a Superset deployment is most likely to raise, and what evidence to have ready before an assessment starts.
CIP-005 boundary and remote access
If any Superset path reads from, or sits near, systems in scope for CIP-005-7, the analytics platform must be placed and documented on the correct side of the Electronic Security Perimeter. Auditors will ask whether routable connections into high or medium impact BES Cyber Systems pass through the defined controls, and whether interactive remote access to Superset uses an Intermediate System with encryption and multi-factor authentication. Confirm the network diagram, access paths and MFA records before the assessment.
CIP-013 vendor obligations for Superset
CIP-013-2 requires a supply chain risk management plan that covers vendor incident notification, vulnerability disclosure, software integrity verification and coordination of vendor-initiated remote access. Apache Superset is Apache-licensed open-source software with no paid vendor, so the plan must name the project, its release channel and the open-source dependencies you run, such as the metadata database, Redis and Celery. Record how you verify release integrity and how you learn of vulnerabilities, and review the plan at least every 15 calendar months.
CIP-011 information protection for exports
Dashboards that show BES Cyber System Information, such as asset configurations or network diagrams, can leak through CSV exports, scheduled reports, screenshots and embedded views. Auditors will ask how BCSI is identified, who can export it, and where exported files are stored and deleted. Decide which datasets are excluded from export roles, restrict report recipients, and confirm the handling procedure covers files Superset generates.
NIS2 and Delegated Regulation 2024/1366
For EU entities, energy is a sector of high criticality under NIS2, which covers electricity, district heating and cooling, oil, gas and hydrogen. Delegated Regulation (EU) 2024/1366 adds sector-specific cybersecurity rules for cross-border electricity flows. Determine whether your Superset instance supports a regulated function, then document how it is covered by your risk management measures, incident reporting and supplier security. Confirm the national transposition and sector rules with your regulator, since obligations vary by member state and entity type.
Penalties and audit frequency
Under the NERC framework, entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive a compliance audit at least once every three years. The maximum civil penalty is $1,584,648 per violation per day, so an undocumented analytics path can carry material exposure even when the dashboard itself is low risk. Map each Superset control to a CIP requirement and keep evidence current between audits, not only before them.
What DeployOpen does and does not issue
DeployOpen plans, configures, hardens and documents Superset inside your infrastructure, and prepares the systems, controls and evidence your assessment will test. DeployOpen does not issue audit reports, attestations or certifications. NERC-registered entities work with their Regional Entity for compliance monitoring, and EU entities work with their designated authorities. Ask your auditor early which evidence they expect, and agree in writing which artifacts DeployOpen will produce.
What utilities ask before hiring help for Superset
What drives the cost of a Superset implementation for a utility?
The scope decides the cost: how many data sources connect, how many dashboards and map views are built, how far identity and role mapping reach, and how much of the OT boundary work must be documented. Costs fall into one-time work (architecture, build, testing, cutover, training) and recurring work (patching, upgrades, backups and monitoring). Ask a partner to price each component separately so you can see which parts your team can absorb. DeployOpen provides a quote from a written scope, not a standard price list.
How long does a Superset pilot take at a utility?
A pilot is paced by approvals and data access more than by Superset itself. The main drivers are how quickly the OT and IT security teams classify the proposed data flows, how long data owners take to approve each dataset, whether the metadata database and network paths exist, and how many dashboards the pilot covers. Ask for a timeline that lists each approval gate as a separate milestone, and confirm which gates your change board requires.
What must our team provide before a partner starts?
Expect to supply four things: a current OT and IT network architecture showing where the proposed Superset host would sit, named data owners for each grid, asset and customer dataset, your identity directory details and group structure, and the approved list of database accounts Superset may use. Your security team should also confirm which zone the Superset host and its metadata database will occupy. Missing any of these items usually moves the schedule more than any technical issue.
Can our own team deploy Superset without outside help?
Yes, a capable platform team can deploy Superset, but utilities should check the skills needed for the parts that carry regulatory weight. The team needs experience with Flask-based applications, PostgreSQL or MySQL administration, Redis and Celery if alerts, reports or thumbnails are used, and hardened Linux or Kubernetes operations. Upgrades also need a tested process, since the upgrade guide asks you to back up the metadata database, run the upgrade commands, test in staging and read UPDATING.md before each major version. Decide early whether you will staff that work continuously.
Does running Superset on our network put it in CIP scope?
Superset alone does not settle CIP scope. The question is how the Superset host, its metadata database and its data connections relate to BES Cyber Systems, which your entity must first classify under CIP-002-5.1a. If Superset reads from or sits near high or medium impact systems, the Electronic Security Perimeter and Interactive Remote Access requirements in CIP-005-7 may apply to it. Your compliance team should document the classification and boundary decisions before the build, and an independent auditor makes the final determination.
What should we ask a partner to include in a written quote?
Ask for a scope that names each deliverable, the environments covered, the data sources and dashboards in scope, the identity integration, the backup and restore test, and the handover documentation. The quote should separate one-time work from any retainer for support or upgrades, list the assumptions about your network and approvals, and state what happens if a boundary decision changes the design. Also ask how supply chain evidence for the software will be provided, since CIP-013-2 expects vendor software integrity and vulnerability disclosure to be planned. Confirm these points against your own procurement template.
Which Superset components need the most attention in a utility environment?
Engineers should focus on the metadata database, the caching layer and the worker processes, because alerts, reports, async queries and thumbnails depend on them. The metadata database must be PostgreSQL or MySQL, not the SQLite default or the Docker Compose PostgreSQL container, which the architecture documentation does not recommend for production. Secrets handling also matters: Superset requires a user-specified SECRET_KEY to start, and PREVIOUS_SECRET_KEY supports rotation. Plan these items in the design review, not after go-live.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Apache Superset inside the utility's own infrastructure, including its cloud accounts, data centers or isolated networks. Work starts from a written scope that separates corporate analytics from any data tied to operational technology.
How we scope
- Inventory which dashboards draw on customer, asset or grid data and which touch operational technology sources
- Confirm the network zones, data flows and connections to each database that Superset would reach
- Agree the identity model, role mapping and row level security rules before any build starts
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
How we build
- Deploy Superset with an external PostgreSQL or MySQL metadata database, not the SQLite default
- Configure caching, workers and alerts only where the design needs them, and document each component
- Map identity provider groups to Superset roles and test access for each dashboard owner group
- Test geospatial layers and dashboards with representative utility datasets in a staging environment
How we hand over
- Deliver architecture, network, access and data source documentation mapped to the utility's own security policies
- Provide an upgrade runbook covering metadata database backups, staged testing and review of UPDATING.md
- Walk operations staff through user administration, role changes, report troubleshooting and audit log review
- Record which evidence supports internal reviews, while the utility's auditors determine compliance outcomes
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainer scope can cover planned Superset version upgrades and reviews of new dashboards and data sources
- Ask for the support hours, response expectations and change process in the quote before signing
- Confirm with the utility's compliance team which changes need a documented review before deployment
