How Graylog supports NERC CIP-007 security event monitoring
Graylog can help with the logging, alerting, retention and review-support parts of CIP-007-6 R4, Parts 4.1 to 4.4, but it does not classify assets, issue audit findings or replace your compliance program. The first step is your impact categorization under CIP-002-5.1a, because the Applicable Systems column in the CIP-007-6 tables decides which high impact BES Cyber Systems, associated EACMS and Protected Cyber Assets are in scope. Those scoping decisions determine which logs matter, so build Graylog inputs from that inventory first and widen them only after scope is confirmed. CIP-007-6 is one of 13 CIP standards NERC lists as mandatory and enforceable in the United States as of 17 October 2026, so the monitoring design will also serve other standards' evidence needs. Read the CIP-007-6 standard before you map any input to a requirement part.
Parts 4.1 and 4.2 are the core of the design. Collect successful and failed login events and malicious code detections from in-scope systems through inputs such as syslog, GELF or Beats, then route them with streams and processing pipelines so the security events are easy to isolate. Event definitions can raise alerts on malicious code detections and on a silent source, which is your practical answer to a failure of event logging. Confirm the silence threshold and the alert list with your compliance lead, because the standard leaves the event types needing alerts to your determination. Part 4.3 requires retaining these logs for at least 90 consecutive calendar days where technically feasible. Set time-based index rotation and retention so the oldest indices are deleted only after that window, and size storage with the documented formula of daily ingest times retention days times 120 percent.
Part 4.4 requires a review of summarized or sampled events at intervals no greater than 15 calendar days for high impact systems and their associated EACMS and PCA. Dashboards and saved searches can produce that summary, but the review record, including who reviewed, the period covered and what was found, must be kept by your team. Ask your Regional Entity what review evidence it expects before you finalize the design. Plan access controls early: Graylog Open supports Active Directory, LDAP and trusted header authentication, while SAML, OpenID Connect and Okta single sign-on are Enterprise features, so confirm the edition you need before you commit to an identity design. Also size the message journal at three to five times daily ingest on SSDs, since a full journal can delay the logs you are required to keep.
Mapping CIP-007-6 R4 Parts 4.1 to 4.4 to Graylog capabilities
This table maps each part of CIP-007-6 R4 to the Graylog capability that collects, retains or alerts on the evidence, the settings to confirm, and the point where your own process must take over. Read each row as a split between what Graylog records and what your team must still do and document.
| Requirement part | Graylog capability and configuration to confirm | Where your process takes over |
|---|---|---|
| Part 4.1: Successful login attempts | Syslog or Beats inputs from Cyber Assets in scope feed a stream for authentication events. Confirm each in-scope device forwards successful logins and that the stream captures them with a pipeline rule that tags the source asset. | Deciding which BES Cyber Systems and Cyber Assets are in scope, and documenting which event types you determined are needed to identify and investigate incidents. |
| Part 4.1: Failed login and access attempts | Same input and stream design as successful logins, with separate pipeline rules for failed authentication and access denials. Confirm the parsing matches each vendor's log format and that failed attempts are not dropped by filtering. | Setting the thresholds you consider meaningful and assigning who reviews failed-attempt volume and the response steps for suspicious patterns. |
| Part 4.1: Detected malicious code | Ingest anti-malware and endpoint detection output into a dedicated stream. Confirm event definitions or searches that match malicious code detections from each source are saved and visible on a dashboard. | Confirming that the upstream tool detects malicious code on the in-scope Cyber Assets, and handling the incident response that follows. |
| Part 4.2: Alerts for malicious code and logging failures | Event definitions send notifications for malicious code detections. Separate event definitions watch for gaps in expected log sources, such as a source that stops sending for a set period. Confirm notification channels, such as email or the other channels the product page lists, reach an on-call group. | Defining the other security events you determine need an alert, testing that the alerts fire, and documenting who acts on them. The logging-failure alert design is your decision and should be justified in your evidence. |
| Part 4.3: 90 consecutive calendar days retention | Index sets rotate by size, message count or time and delete the oldest indices. Confirm the retention setting covers at least 90 consecutive calendar days of Part 4.1 data for in-scope sources, with sizing based on daily ingest and retention days. | Determining where retention is technically feasible, documenting any exceptions under CIP Exceptional Circumstances, and proving the retention period was not shortened by a later configuration change. |
| Part 4.3: Restricted access and integrity of stored logs | Use separate index sets for CIP logs and restrict roles so only named users can search or change them. Confirm that index deletion is limited to the retention policy and that changes are recorded. | Setting access approval, periodic access review and the protection controls for the backends that hold the data. |
| Part 4.4: Summarized or sampled review every 15 calendar days | Saved searches and dashboards summarize Part 4.1 events by source, outcome and time window. Confirm the dashboard covers the full 15-day interval and that event definitions catch the most serious events between reviews. | Scheduling the review at intervals no greater than 15 calendar days, choosing the summarization or sampling method, recording who reviewed the logs, the date, and the undetected incidents found or ruled out. |
Which Cyber Assets send logs to Graylog inside the ESP
The scope of CIP-007-6 R4 is set before any Graylog input is configured. Each BES Cyber System has to be sorted into a high, medium or low impact category under the bright-line criteria in Attachment 1 of CIP-002-5.1a, and the Applicable Systems column of the CIP-007-6 table then decides which assets must produce the Part 4.1 events. For high impact systems, that covers the BES Cyber Systems themselves, their associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) and Protected Cyber Assets (PCA). Medium impact systems with External Routable Connectivity are scoped in the same table, and the exact list differs by impact rating. Read the table text yourself in the CIP-007-6 standard before drafting the collector plan, because a Graylog design built on an assumed asset list will fail at the first audit sample.
The impact ratings are the entity's own determination, not something a log platform can infer. Confirm each rating against your CIP-002 identification and approval records, and record which assets fall under each Applicable Systems row. Then map the logging path. Decide which collectors sit inside the Electronic Security Perimeter, which sit outside it, and exactly where traffic crosses the perimeter. A Graylog server node or Data Node placed outside the ESP to receive logs from inside it creates a boundary crossing that CIP-005-7 controls must account for, so the data flow, protocol and access rules should be written down and reviewed with the CIP-005 owner. Logs from in-scope Cyber Assets should not depend on a path that also serves out-of-scope traffic without that being an explicit decision.
Vendor-supplied event sources need their own check. Appliances, controllers, relays and vendor-managed applications often log only some of the events Part 4.1 names, or they log them only when a specific setting is enabled. For each in-scope device type, confirm in vendor documentation or a test system whether it produces successful login events, failed access and login attempts, and malicious code detections, and whether it can send them over syslog or another supported path. Record gaps as open items with an owner, because Part 4.2 also requires alerting on failure of event logging, and that alert depends on knowing which sources are expected to report.
What Graylog evidence auditors can review under CIP-007
A Graylog deployment inside an electronic security perimeter produces configuration and event records that map onto CIP-007-6 R4. The cards below cover the artifacts to export, date and version, and keep for each review cycle, since the Compliance Enforcement Authority assesses the entity's evidence rather than the tool that produced it.
Input and source configuration exports
Export the input definitions that bring login and malicious code events from in-scope Cyber Assets into Graylog, including input type, bind address, port and the assigned stream. These exports show which BES Cyber Systems feed the log platform for Part 4.1. Check that every in-scope asset named in your asset list appears in an input or forwarding rule, and record the date of each export.
Stream and pipeline definitions
Streams and processing pipelines decide which events reach which index set and which rules normalize successful login, failed access and malicious code messages. Keep exports of each stream rule and pipeline rule set, with the change history showing who altered them and when. Auditors will compare these definitions against the event types your CIP-007 procedure says you log.
Index set retention settings
Index set rotation and retention settings are the direct evidence for the 90-consecutive-day retention in Part 4.3. Capture the retention strategy, the number of indices kept and the rotation rule for each index set holding Part 4.1 logs. Confirm that the retained window covers at least 90 days and document any CIP Exceptional Circumstances handling separately.
Event definition and notification records
Event definitions that detect malicious code and failure of event logging, together with their notification targets, answer Part 4.2. Export each definition, its search condition, priority and notification channel, and keep a record of test firings. Confirm that a logging failure alert fires when an in-scope source stops sending, and keep the alert and acknowledgment history.
Dashboards and saved summaries for each review
Part 4.4 requires a summarization or sampling of logged events at intervals no greater than 15 calendar days for high impact systems and their associated EACMS and PCA. Save the dashboards or search summaries used for each review, along with the reviewer name, the date range covered and the findings. Store each summary as a dated, versioned file so the review cadence can be shown across the audit period.
Dated and versioned record keeping
Store every export in version control or an immutable repository with a timestamp, the Graylog version in use and the change author. Graylog 7.2 is the version the current documentation covers, so note the release running at each export. Restrict write access to these records, since an auditor will ask whether the evidence could have been altered after the fact.
Configuring Graylog for CIP-007 logging in order
This sequence takes a CIP-007-6 scope from asset list to a tested logging pipeline, with retention, alerting and the 15-day review in place before the first audit period. Each step produces a record an auditor can ask to see.
Confirm the in-scope asset list
Start from the CIP-002 impact categorization and list which BES Cyber Systems, associated EACMS, PACS and PCA fall under CIP-007-6 Part 4, since the applicable systems table scopes each requirement. The compliance lead and the operations team sign off on the list, and each asset is tagged by impact class and by whether it is high impact or otherwise in scope. The list is the done condition for this step, because every later stream, input and retention setting traces back to it. Confirm the final scope with your Regional Entity's expectations and your own CIP program documents, not with this page.
Deploy Graylog server nodes and backends
Install Graylog server nodes, MongoDB and the search backend using the installation method Graylog documents for your platform, with Data Node recommended as the search backend. For medium to large deployments the multi-node guide describes three Graylog and MongoDB nodes, three Data Nodes and a load balancer, with follower Graylog nodes set to is_leader false. Check the compatibility matrix for your chosen Graylog version before you pick MongoDB and OpenSearch or Data Node releases. The step is complete when all nodes report healthy and the cluster status is visible in the web interface.
Configure inputs for login and malicious code events
Create inputs that receive authentication events and malicious code detection events from each in-scope asset class, using syslog, GELF, Beats or a collector your platform supports. Confirm with each vendor which event IDs cover detected successful logins, detected failed access and login attempts, and detected malicious code, because the standard requires these categories but does not name the product fields. Test with a sample event from each source and confirm it appears in the expected index. The step is done when a failed login and a malicious code test event from each class are searchable in Graylog.
Build streams and pipelines per asset class
Route messages into streams by asset class, such as high impact BES Cyber Systems, their EACMS and their PCA, so that each stream can have its own index set, access rules and event definitions. Add processing pipeline rules to normalize fields and tag event categories consistently across sources. Document each stream rule and pipeline rule in your CIP evidence set, because reviewers will ask how a message reached its stream. The step is complete when a sample from each asset class lands in the correct stream and carries the expected tags.
Set index retention for 90 consecutive days
Configure index set rotation and retention so that the Part 4.1 logs remain searchable for at least the last 90 consecutive calendar days, unless a CIP Exceptional Circumstance applies. Graylog's index model deletes the oldest indices under the retention setting, so size the index sets to hold the full window with margin, using the sizing guidance in Graylog's architecture documentation. Confirm with your storage team how retention is enforced if the platform stores data on shared or tiered storage. The step is done when a test index set shows the configured retention and the oldest retained message is at least 90 days old.
Create event definitions for malicious code and logging failure
Create event definitions that alert on detected malicious code and on a failure of event logging, such as a source that stops sending messages or an input that goes down. Choose notification channels your operations team monitors, such as email, Slack or PagerDuty where your edition supports them. Write the alert condition and the response expectation into the CIP-007 procedure, since Part 4.2 leaves the security events needing alerts to your determination. The step is complete when a simulated malicious code event and a simulated silent source each trigger a notification that reaches the on-call team.
Schedule and record the 15-day review
Define a recurring review of a summarization or sampling of logged events at intervals no greater than 15 calendar days, covering the high impact BES Cyber Systems and their associated EACMS and PCA. Use saved searches and a dashboard so the reviewer produces the same summary each time, and record the reviewer, date, scope and findings in a ticketing or evidence system. Set a calendar reminder that is shorter than the 15-day interval so a missed review is visible. The step is done when the first review record exists with the dashboard export attached and the reminder is active.
Test alerting and retention before the audit period
Run a documented test that injects a malicious code event, stops one log source, checks the 90-day retention setting against the oldest indices, and confirms the 15-day review record. Keep the test plan, timestamps, screenshots or exports and the defect log as evidence. Have someone outside the team that built the setup verify the results, and fix any gaps before the audit period begins. Ask your compliance advisor or auditor what evidence format they expect, since NERC audits are run by the Compliance Enforcement Authority. The step is complete when the signed test record shows every check passing or has an accepted remediation plan.
Questions buyers ask about CIP-007 logging with Graylog
What does a CIP-007 logging deployment with Graylog cost, and what drives it?
The cost depends on scope, not on a Graylog price list. Graylog Open is free to download and run, but a utility still pays for the infrastructure that holds its logs, the engineering time to design and build the collection, and any Enterprise or Security license it needs. The main cost drivers are the number of in-scope Cyber Assets and sources, the daily volume of events, how many days of logs must stay searchable for the 90-day retention in Part 4.3, and whether the team needs features such as the correlation engine or SIEM content. Retention storage is usually the largest recurring cost. Ask any partner for a fixed-scope quote that lists the sources, the storage sizing assumptions, the licensing edition and the handover work, so the figures can be compared line by line.
How long does a Graylog deployment for NERC CIP-007 take?
Duration depends on the environment and the scope agreed in writing, and no fixed timeline applies to every utility. The schedule is shaped by how many systems are inside the electronic security perimeter, whether the team can reach them through approved change windows, how many log sources need custom parsing, and whether the cluster is built on new hardware or on existing infrastructure. Work usually moves in stages: scoping and source inventory, a non-production build, validation of each event type against Part 4.1, alert testing for Part 4.2, and then production cutover. Ask for a plan that shows which stages depend on your change control and access approvals, since those often set the pace more than the software does.
What must our team provide before a Graylog logging project starts?
The project needs accurate inputs from your compliance, operations and network teams before design can begin. The most important items are a current list of BES Cyber Systems and Cyber Assets in scope, the CIP-002 impact ratings that determine which systems are high, medium or low impact, and a diagram of the electronic security perimeter. Engineers also need network paths from each source to the Graylog inputs, service accounts with read access to logs, and firewall changes approved in advance. On the review side, name the people who will perform the Part 4.4 summary reviews every 15 calendar days and the people who will act on Part 4.2 alerts. Clear ownership of these roles is often what determines whether the monitoring runs after handover.
Can our internal team deploy Graylog for CIP-007 without outside help?
A team with Linux, database and log-pipeline experience can build a Graylog deployment internally, because Graylog documents package and Docker installs and multi-node setups. The harder part is the compliance mapping and the operational discipline around it. Internal teams often underestimate the work to classify which logs count as Part 4.1 events, to write event definitions that detect malicious code and logging failures, to restrict access to log data, and to document retention and review evidence. Consider whether your staff can commit time to both the build and the ongoing review cycle. A partner can take on fixed-scope parts such as architecture, hardening and documentation while your team keeps ownership of the operating procedures.
Does Graylog Open alone meet CIP-007-6 R4?
No single product certifies CIP compliance, and CIP-007-6 has no certificate. Graylog Open can collect, index, search and alert on events, and its retention and event definitions can be configured to support R4. However, meeting R4 is an outcome of the entire program: the right sources must be logged, the retention period must be met, the 15-day summary reviews must be performed and recorded, and the logging itself must be protected and monitored for failures. Some features that help with detection and correlation, such as the correlation engine or SIEM content, depend on Enterprise or Security editions. Confirm with your Compliance Enforcement Authority and your own compliance lead which evidence they expect before you rely on any single edition.
How does Graylog state the price of its editions on the pricing page?
The Graylog pricing page states that Graylog Open is free with no volume limits and community support. It lists Graylog Enterprise starting at 15,000 US dollars per year and Graylog Security starting at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, and says licensing is based on processed data with no per-user or per-device fees. These are starting figures from the vendor, and the page does not show a full quote for any given utility. Before budgeting, confirm with Graylog which edition, volume basis and support level your design needs, and whether the figures include the infrastructure and support you will require.
Which parts of the Graylog work recur after the initial build?
The one-time work includes architecture, installation, source onboarding, parsing, event definitions and documentation. Recurring work includes running the cluster, rotating and monitoring indices, applying Graylog patch releases, reviewing summaries every 15 calendar days, testing alerts and handling logging-failure notices. Storage costs also recur as the retention window fills. Upgrades between major Graylog versions need planning because of changes in runtime and database prerequisites, so budget time for them. Ask for a quote that separates the one-time build from an optional support or retainer agreement, so you can see which costs continue after handover.
Decisions to settle before the Graylog build starts
Four decisions shape the rest of the build, and they should be settled before anyone installs a server. The first is topology. Graylog documents a multi-node layout for medium to large deployments: three Graylog and MongoDB nodes with MongoDB run as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes, with is_leader set to false on follower nodes. Confirm with your team whether the Electronic Security Perimeter (ESP) boundaries you draw for CIP-007-6 R4 need separate Graylog deployments per impact zone, because a single cluster that spans zones can widen the set of systems in scope for the audit. A single-node test environment is useful for validating parsers, but it should not be the system that holds the 90-day evidence.
The second decision is storage. Graylog's system architecture guidance sizes log storage as daily ingest multiplied by retention days, multiplied by 120 percent. Your daily ingest must come from measured log volume across every in-scope asset, not from estimates. Retention is set by Part 4.3 at a minimum of 90 consecutive calendar days where technically feasible, so plan for that window plus headroom, and note that Graylog deletes the oldest indices under index rotation, so the rotation settings must never discard data before the window closes. The message journal also needs disk, and the same guidance gives a range of 3 to 5 times daily ingest on SSDs. Ask your storage team to confirm that the chosen SSD tier can absorb a Data Node or Graylog node restart without the journal overflowing.
The third decision is edition. Graylog Open covers collection, streams, pipelines, searches, dashboards and event definitions that can alert on a failed log collection. Correlation, SIEM features and some support levels sit in the paid editions, and the pricing page lists Graylog Enterprise and Graylog Security at annual figures starting from the amounts published there, with a minimum of 10 GB per day or 100 Graylog Compute Units. Map each Part 4.2 and 4.4 requirement to the feature that meets it before choosing an edition, and request a written quote that states the licensed volume. Finally, decide how Compliance Enforcement Authority requests will be answered. Auditors work through Compliance Audits, Spot Checks and self-certifications, so agree in advance which saved searches, exported reports and retained event records will prove logging, alerting and 15-day summary reviews, and who has authority to produce them.
How DeployOpen scopes and delivers CIP-007 logging configuration
DeployOpen plans, builds, documents and supports self-hosted Graylog inside your own infrastructure, including the networks within your electronic security perimeters. For CIP-007-6 R4, we start from the Applicable Systems your compliance team confirms, then configure log collection, alerting, retention and review around those systems. Engagements are fixed-scope, with the written scope agreed before work starts.
How we scope
- Confirm with your compliance team which BES Cyber Systems, EACMS and PCA fall under CIP-007-6 R4 before design begins.
- List the event sources for successful logins, failed logins and malicious code detections on each in-scope asset.
- Agree in writing the retention store, review cadence and evidence outputs that the written scope will cover.
How we build
- Build Graylog server nodes, MongoDB and Data Node in your environment, sized against your daily ingest and retention period.
- Configure inputs, streams and processing pipelines so in-scope events land in the retention index set you approved.
- Create event definitions for malicious code, login events and failure of event logging, and test each alert path end to end.
How we hand over
- Deliver configuration documentation mapping each Part 4 requirement to the Graylog inputs, streams, alerts and dashboards that meet it.
- Provide a runbook for the 15-day summary review, including the saved searches, dashboard exports and sign-off steps your staff will use.
- Walk your operators through alert triage and verification tests so your team can repeat them after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped to your Graylog version and change process.
- Plan Graylog upgrades with your compliance team, since alert logic and retention settings must be re-verified after each change.
- Confirm with your auditors or Regional Entity which evidence they expect. DeployOpen prepares systems and evidence but does not issue audit reports or certifications.
