Graylog for energy and utilities: why the build starts from CIP scope
Graylog can serve as the central log platform for an energy or utility operator, but only when the design follows the CIP applicability of each asset. An operator with CIP-registered assets, segmented OT networks and auditors asking for evidence should first decide which BES Cyber Systems are high, medium or low impact under CIP-002-5.1a, because that classification sets which systems must feed the log platform, how long their records are kept and who may review them. Build the log scope from that list, not from a generic inventory of servers and firewalls. Confirm the current enforceable version of each standard against the NERC CIP standards page before you write any control into a design.
Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license. The community edition is free with no volume limits and community support, and it covers the core work: inputs such as syslog and Beats, streams, processing pipelines, search, dashboards and index retention. Several capabilities that utility teams often need sit in the commercial editions. Graylog Enterprise adds a data lake with archive restore, data tiering and a correlation engine, and Graylog Security adds SIEM features such as investigations, compliance packs and prebuilt threat detection content. Single sign-on through Okta, generic OpenID Connect or SAML is also an Enterprise feature, while Active Directory and LDAP authentication are available in Open. Before the design is fixed, map each required control to a specific edition and get that written into the quote, so that a compliance gap does not appear during the audit.
Treat the licensing check as part of the CIP scoping exercise. Ask the operator's compliance lead which Applicable Systems generate the events that must be retained and reviewed, then ask which of the needed Graylog features they depend on, and confirm the license tier for each. Note that Graylog pricing is based on processed data with no per-user or per-device fees, so the volume of in-scope logs will drive the commercial conversation as much as the feature list. Keep the scoping record, the edition decisions and the vendor's written license terms together, because an auditor will ask how the log platform was chosen and whether it meets the obligations it was bought to support.
Which CIP and sector requirements shape the Graylog build
This table maps each NERC CIP and NIS2 requirement that touches logging to what the Graylog design must provide. Read each row as a question to answer before sizing inputs, streams and retention. The main takeaway is that scope is set by impact classification and applicable systems, not by how much data Graylog can hold.
| Requirement | What it asks for | What the Graylog design must provide |
|---|---|---|
| CIP-002-5.1a impact categories | Sorts BES Cyber Systems into high, medium or low impact using bright-line criteria in Attachment 1 | A confirmed asset list with impact ratings, so log sources are tagged by impact and only in-scope systems feed the CIP streams |
| CIP-005-7 Electronic Security Perimeter | Places routable-connected high and medium impact assets inside an ESP and routes Interactive Remote Access through an Intermediate System | Logs from firewalls, Intermediate Systems and access points at ESP boundaries, with separate inputs and index sets so perimeter events can be shown on their own |
| CIP-007-6 event monitoring | Scopes logging and alerting requirements by Applicable Systems, including EACMS, PACS and Protected Cyber Assets | Per-system stream routing and event definitions for each applicable system class, with retention and review evidence kept per class |
| CIP-013-2 vendor remote access and software integrity | Supply chain plans covering vendor incident notification, vulnerability disclosure, software integrity verification and vendor-initiated remote access, reviewed at least every 15 calendar months | Searchable records of vendor remote sessions and software update events, plus dashboards for review of vendor access against the plan |
| CIP-015-1 internal network security monitoring | Approved by FERC on 26 June 2025, enforceable from 1 October 2028 (NERC CIP standards page) | A planned path for network sensor data and capacity headroom now, since later versions extend monitoring to EACMS and PACS (CIP-015-2 effective 1 October 2029) |
| NIS2 Annex I energy coverage | Lists electricity, district heating and cooling, oil, gas and hydrogen as high-criticality subsectors for EU operators | Confirmation of which EU entities and subsectors are in scope, with log retention and incident-handling workflows matched to the national transposition in each member state |
| Retention and review schedules | Auditors check that retention periods and review cadence match the entity's documented compliance program (NERC Rules of Procedure Appendix 4C) | Index rotation and retention settings per index set, plus recorded review of alerts and events on a schedule the compliance team has approved |
How CIP-002 impact categories decide which logs go into Graylog
The impact classification of each BES Cyber System under CIP-002-5.1a decides which logs belong in Graylog. The standard sorts systems into high, medium and low impact using bright-line criteria in its Attachment 1. High impact mainly covers qualifying control centers, medium impact includes, for example, generation of 1500 MW or more at one plant or Transmission Facilities at 500 kV or higher, and low impact covers other BES Cyber Systems at listed assets. Most CIP requirements are then scoped in tables by Applicable Systems, such as high impact BES Cyber Systems, medium impact systems with External Routable Connectivity, and their associated EACMS, PACS and Protected Cyber Assets. Before building any input, map each asset to its impact category and then to the Applicable Systems rows that reference it, because a log source is in scope only through that chain.
The reader must confirm this scope with their own Compliance team and their Regional Entity, not with DeployOpen. The Compliance Enforcement Authority, a Regional Entity or NERC, judges whether an entity's classification and evidence are adequate, and the classification record is part of what gets reviewed. Ask for the current impact classification list, the Applicable Systems mapping for each CIP-007 and CIP-005 requirement you intend to evidence, and any documented exceptions. Then record which hosts, EACMS, PACS and PCA sources feed Graylog for each category, so that a later review can trace a Graylog stream back to a rule.
Check the scope against the NERC CIP standards page at the time of the build, not from memory or from an earlier design. NERC lists 13 CIP standards as mandatory and enforceable in the United States as of 17 October 2026, and several revisions take effect later, including CIP-003-9 and CIP-012-2 already enforceable in 2026, CIP-015-1 from 1 October 2028 and virtualization-related revisions from 1 July 2028. Each revision can change which systems fall under a requirement, so the Graylog input plan, retention periods and review schedule should be re-checked against the version effective on the date the logs are collected.
Graylog configuration for segmented OT and control environments
Control centers that host high impact BES Cyber Systems hold the most scrutiny in the CIP program, so the Graylog design here should favor complete capture and a short path from event to a responsible operator. Confirm the scope with your compliance team before building, because the impact rating comes from the bright-line criteria in CIP-002, not from the size of the site.
- Inputs: Use syslog over TLS or a message queue where your devices support it, and GELF or Beats for Windows and Linux hosts. Confirm which input types your edition licenses before you commit to a design.
- Forwarders: Place a forwarder inside the Electronic Security Perimeter so logs leave the segment through a controlled path. Document each forwarder as a monitored component.
- Streams and pipelines: Route events from high impact assets into a dedicated stream, and tag records that map to CIP-007 monitoring, such as authentication failures, configuration changes and malicious code alerts.
- Event definitions: Build alerts for failed logins on console and jump systems, unexpected changes on BES Cyber System hosts, and loss of log sources.
- Ticketing and paging: Send alerts to your ticketing system and on-call paging tool, and confirm which notification types your edition supports.
Before go-live, confirm with your auditors which assets are in scope and how alert evidence will be retained for review.
Medium impact sites, such as generation plants at or above the CIP-002 threshold and transmission facilities at 500 kV or higher, often run separate plant networks and corporate links. The design challenge is to collect from several segments without letting the collection path weaken the perimeter. Scope tables in CIP-007 distinguish medium impact systems with External Routable Connectivity, so confirm which assets fall in that group before setting the routing rules.
- Inputs: Accept syslog from protection relays, historians and firewalls that support it, and use Beats agents on Windows engineering workstations where the vendor allows it.
- Forwarders: Deploy one forwarder per segment, with rules that allow only the outbound flows required for log delivery. Test that each forwarder keeps buffering when the link to Graylog is interrupted.
- Streams and pipelines: Separate records by plant and by applicable system category, so a reviewer can pull the evidence for one asset class without browsing unrelated data.
- Event definitions: Alert on login activity at remote access points, changes to security event logging settings, and gaps where an expected source goes silent.
- Integrations: Connect the same alert routes used by the control center, so operators at each site follow one escalation path.
Check that each source's clock is synchronized, because timestamps are what auditors use to reconstruct an event across segments.
Low impact assets and remote substations usually have narrow bandwidth, limited local staff and intermittent connectivity. Logging design must account for the constraints, and the CIP-003 requirements for low impact assets have their own timeline, so confirm which version applies to your assets and its effective date before scoping the work. Keep the design simple enough that the same procedures apply across many sites.
- Inputs: Use syslog from substation devices that support it, and avoid agents that require frequent updates on constrained hardware. Confirm device-specific log formats with the vendor.
- Forwarders: Use a small local forwarder or store-and-forward device at each substation, with buffering sized to cover typical outages. Ask the vendor for the buffer behavior of any device you plan to use.
- Streams and pipelines: Tag records by site identifier and asset class, and drop only the noise your reviewers have agreed to exclude in writing.
- Event definitions: Keep the first set small. Alert on remote access, authentication failures and log source silence, then expand after reviewing volumes.
- Integrations: Route alerts to a central queue that the security operations team monitors, with escalation to field staff for site-level issues.
Verify that each remote site can deliver logs after a simulated link outage, and that buffered records arrive intact when the link returns.
Rollout phases for a CIP-regulated Graylog deployment
This sequence moves a CIP-regulated operator from scoping its BES Cyber Systems to a Graylog platform that collects, retains and reviews security event logs, with each phase closing on evidence an auditor can inspect.
Confirm CIP applicability and asset inventory
Start by establishing which CIP standards apply. Your compliance lead confirms your NERC Compliance Registry status and your impact categorization under CIP-002-5.1a, identifying high, medium and low impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems and Protected Cyber Assets. You provide the current asset inventory, network diagrams and the list of standards in force for your registration. DeployOpen maps which log sources feed each applicable requirement, including CIP-007-6 security event monitoring. The step closes with a signed scope register that names every in-scope system and the standard that governs it, so later design decisions trace back to documented obligations.
Design the Electronic Security Perimeter crossing
Decide how log data leaves each Electronic Security Perimeter without weakening it. The design covers where forwarders sit inside segmented OT networks, which ports and protocols cross the boundary, how traffic is encrypted and which direction flows are permitted. You supply firewall rules, zone definitions and change authority for the boundary devices. DeployOpen documents the forwarder placement, the data flow for each source and the access paths for Interactive Remote Access, which CIP-005-7 requires to pass through an Intermediate System. The step closes with an approved data flow diagram and a firewall change request set that your security and operations teams have reviewed.
Deploy the multi-node Graylog and Data Node cluster
Build the production cluster following Graylog's multi-node guidance: three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster and a load balancer in front of the Graylog nodes. Follower Graylog nodes run with is_leader set to false. Storage is sized from daily ingest, retention days and the 120 percent factor in Graylog's architecture guidance, and the message journal is placed on SSDs with 3 to 5 times daily ingest. You provide the host platform, network segments and storage capacity. The step closes with a healthy cluster that survives a single node stop in test, with journal and index health confirmed.
Configure authentication and role-based access
Connect Graylog to your identity source so investigators sign in with named accounts. Graylog Open supports Active Directory, LDAP and trusted header authentication, while Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on, so confirm which edition your organization licenses before choosing the method. You provide the identity provider details, group mappings and the list of roles that may search or export sensitive logs. The step closes with a tested login per role and a record showing that shared accounts are not used for investigations.
Build streams and retention index sets
Route each source into streams that match the impact category and system group, then assign index sets whose rotation and retention settings reflect the retention period your CIP evidence plan requires. Index rotation by message count, size or time and deletion of the oldest indices are configured per index set, so retention must be set deliberately rather than left at defaults. You confirm the retention periods with your compliance lead and provide the source list per stream. The step closes with a retention matrix that maps each stream to its index set, rotation rule and deletion behavior, which becomes a reviewed artifact.
Run test events and capture evidence
Validate that the monitoring chain works end to end. Event definitions are created for the security event types your CIP-007-6 controls require you to detect and alert on, and test events are generated from each forwarder with controlled, planned activity. Notifications are checked for the channels your staff actually use. Operations and OT staff agree in advance on any test that could affect uptime, since OT testing is planned around safety and reliability. The step closes with a test record showing trigger time, alert delivery and investigator review for each event type, stored where auditors can retrieve it.
Establish review cycles and change control
Set the recurring duties that keep the system compliant over time. This includes scheduled review of alerts and retention evidence, backup and restore checks, access recertification and a change process for Graylog version upgrades, which is tied to the Graylog release calendar and the compatibility matrix. You confirm the internal review cadence and change approvers. DeployOpen prepares runbooks for these tasks and tests one upgrade in a non-production copy before any production change. The step closes with an approved calendar of reviews and a documented upgrade procedure that names the compatibility checks to pass before cutover.
Compliance considerations auditors check for logging evidence
Graylog can collect, retain and help review the log evidence that CIP requirements ask an entity to produce, but no product makes an entity compliant. The cards below cover the CIP standards that shape logging decisions, the entity's own plan that sets retention and review, and how auditors actually test the evidence.
CIP-007 security event monitoring evidence
CIP-007-6 expects in-scope Cyber Assets to log security events and to review those logs on a defined schedule, with the logs retained long enough to support investigations. In Graylog, this means confirming that each in-scope source has an input, that the stream and index set for it is documented, and that the review cadence is recorded. Ask your auditor which Applicable Systems your entity has scoped in, then check that every one of them appears in your Graylog source inventory.
CIP-011 protection of log data
CIP-011-3 addresses how BES Cyber System Information is identified and protected, and logs can contain that information, such as network addresses, asset names and configuration details. Treat the Graylog cluster as an information store in scope: restrict search and export to named roles, encrypt traffic between nodes and the data backend, and document who can read archived indices. Confirm with your compliance team how your entity classifies log content before you decide what the search team can see.
CIP-013 vendor and software integrity
CIP-013-2 requires a supply chain risk management plan that covers vendor incident notification, vulnerability disclosure, and verification of software integrity and authenticity. Graylog is software your entity will patch, so the plan should name how you obtain packages, verify them, track security advisories and handle the license terms of each edition. Because Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved license, record the edition in use and the license review in the same file.
Retention and review schedules
The CIP standards do not set one retention period for every log, so the schedule your entity writes is the number auditors will test against. Set index rotation and retention in Graylog to match that schedule, then keep a record that shows each index set kept its data for the stated period. Review the schedule when standards change, since several CIP versions take effect in 2026, 2028 and 2029. Ask for a documented schedule before you configure retention.
Audits and Spot Checks, not certificates
There is no CIP certificate. The Compliance Enforcement Authority monitors compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and periodic data submittals. Entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive a compliance audit at least once every three years. Keep Graylog evidence ready at any time, such as configuration exports, review records and alert histories, because a Spot Check can arrive without a long lead time.
Penalty exposure for violations
Civil penalties for CIP violations can be significant, with a maximum of $1,584,648 per violation per day under 18 CFR 385.1602. The exposure makes a logging gap a board-level risk, not only an engineering task. Use this figure to justify the time needed for evidence collection, review records and access controls, and confirm the current adjusted amount with your legal or compliance advisers before you cite it in internal decisions.
What utilities ask before hiring a Graylog partner
What drives the cost of a Graylog deployment for a utility?
Scope, the number of log sources and the daily volume you ingest drive most of the cost. Log storage is sized from daily ingest multiplied by retention days multiplied by 120 percent, so retention length and volume set the disk footprint directly. The Graylog system architecture guidance also advises giving the message journal 3 to 5 times daily ingest on SSDs, which adds to hardware needs. Ask any partner for a written quote that lists the number of OT and IT sources, the ingest estimate per source, the retention period required for each CIP evidence type, the number of Graylog and Data Node hosts, and whether the work covers forwarder deployment in segmented networks. Infrastructure you pay for in your own cloud or data center is separate from the services fee.
How long does a Graylog build for CIP monitoring take?
Duration depends on how many Electronic Security Perimeters, asset classes and log sources must be onboarded, how much network access is available for forwarder work, and how quickly your CIP owners approve the monitoring design. The multi-node reference layout (three Graylog and MongoDB nodes, three Data Nodes, and a load balancer) adds build and testing steps that a single-node proof of concept does not. Outage windows for OT-adjacent work also set the schedule, since NIST SP 800-82 Rev. 3 frames OT testing around safety and uptime. Ask for a timeline tied to written milestones and to the specific systems in scope, rather than a generic duration.
Can our in-house team run Graylog after the build?
Yes, if your team has Linux administration, MongoDB and search-backend skills and clear ownership of the on-call and review process. Day-two work includes watching the cluster, handling journal and buffer problems, taking backups, checking capacity against retention, and applying version upgrades on the documented path. Graylog 7.0 to 7.2 need MongoDB 7.x up to 8.2.x and support OpenSearch from 1.1.x up to 3.7.x, and use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so upgrade planning becomes a standing task. Ask whether your staff will own the runbooks, or whether a retainer will cover upgrades and testing.
What must our utility provide before a Graylog partner starts?
Partners need an inventory of BES Cyber Systems and their impact categories, network diagrams that show where Electronic Security Perimeters and segmented OT zones sit, and a list of the systems that produce security event logs. They also need named CIP owners who can approve retention periods, review schedules and access rules, and who can decide how evidence will be shown to auditors. Access to change windows, forwarder placement approvals and a test environment matters as much as documentation. Confirm these inputs in writing during scoping, because missing asset lists are a common reason for rework.
Do we need a Graylog Enterprise or Security license for utility monitoring?
It depends on the features your monitoring design uses. Graylog Open covers ingestion through inputs such as syslog, GELF and Beats, streams, processing pipelines, search, dashboards and event definitions with notifications. Graylog Enterprise adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support, while Graylog Security adds SIEM features such as risk scoring, anomaly detection, investigations and compliance packs. Pricing starts at 15,000 US dollars per year for Enterprise and 18,000 US dollars per year for Security, each with a minimum of 10 GB per day or 100 Graylog Compute Units, and licensing is based on processed data with no per-user or per-device fees. Ask for a feature-by-feature license map before you commit.
How does Graylog's SSPL license affect procurement?
Graylog Open has been licensed under the Server Side Public License version 1 since Graylog 4.0 in 2020, which is not an OSI-approved open source license, so it does not fit procurement rules that require OSI-approved software. Earlier releases were under GPL v3. Your legal and procurement teams should review the license text in the Graylog server repository and confirm whether SSPL terms are acceptable for your use, including any hosting-as-a-service implications. If Enterprise or Security features are required, those are licensed commercially under the Graylog pricing terms. DeployOpen does not provide legal advice on licensing, so confirm the position with counsel.
Testing Graylog changes without disturbing OT operations
Changes to Graylog that touch OT collection must be scheduled with operations staff, because NIST SP 800-82 Rev. 3 frames OT security countermeasures around performance, reliability and safety. A forwarder restart, a new input or a parsing change on a segment that feeds industrial control data can affect the systems it observes if it adds load, blocks a polling cycle or triggers a vendor-specific behavior. Before any change, confirm with the control engineers which hosts, ports and protocols are in scope, what the maintenance window is, and who can halt the change. Ask the operations team to name a rollback owner and a stop condition, such as a rise in CPU or network utilization on the monitored asset, that ends the test immediately.
Start with non-intrusive collection and a single staged segment. Prefer passive or outbound-only collection: forwarders that read local logs and push them to Graylog, rather than active queries or scans against PLCs, RTUs or historians. Deploy the forwarder configuration to one segment first, validate that the message journal on the Graylog side drains normally, and confirm that no OT device logs an unexpected change in state. Keep the Graylog server and Data Node changes separate from the forwarder changes so that a fault can be traced to one layer. Document what each stage changed so the same steps can be repeated for the next segment.
Use the MITRE ATT&CK for ICS matrix to choose which detection content to test, not to generate test traffic against live systems. The matrix lists 12 tactics, from Initial Access through Inhibit Response Function and Impair Process Control to Impact, and each technique maps to log sources you can check for coverage. Pick the techniques that match your assets, then replay recorded or synthetic events into a non-production Graylog stream to confirm that event definitions fire and that notifications reach the right on-call group. Any active testing in the OT environment should be a separate, approved exercise with the asset owner present, and its scope should be written down before it begins.
How DeployOpen scopes and delivers Graylog for energy operators
DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside the client's own infrastructure, including control networks that operators keep separate from corporate IT. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map which systems fall under CIP-002 impact categories and which logs each in-scope asset must produce.
- Agree in writing which Graylog edition, inputs, forwarders and retention periods the engagement covers.
- Confirm with your compliance team and auditors which evidence and review schedules the scope must support.
How we build
- Design forwarder placement across segmented OT networks and the paths through each Electronic Security Perimeter.
- Build Graylog server nodes, MongoDB, Data Node storage and load balancing on infrastructure you control.
- Test collection, time sync, index retention and event definitions against documented scenarios before sign-off.
How we hand over
- Deliver runbooks for the review schedule, retention checks, backups and access reviews your team will run.
- Document configuration, data flows and the evidence location for each CIP-007 requirement in scope.
- Train operators and compliance staff on searches, dashboards and investigation steps used during audits.
How we support
- Offer ongoing support, upgrades and testing as a retainer, with upgrade planning for each Graylog release.
- Review retention, storage capacity and forwarder health on a schedule agreed in the support scope.
- Confirm response terms, maintenance windows and change control with your team before the retainer starts.
