What CIP-007-6 R4 asks you to monitor and why audits fail on it
An operator or compliance lead preparing for a CIP audit needs to show three things about CIP-007-6 R4: security events on the applicable systems are logged, alerts go out for the events that matter, and someone reviews those events on a schedule. Part 4.1 requires logging at the BES Cyber System or Cyber Asset level, covering at minimum detected successful logins, detected failed access and login attempts, and detected malicious code. Part 4.2 requires alerts for security events the entity decides need one, and the standard names two floors: detected malicious code and failure of event logging itself. Part 4.3 requires keeping the Part 4.1 logs for at least the last 90 consecutive calendar days where technically feasible, unless CIP Exceptional Circumstances apply. Part 4.4 requires reviewing a summary or sample of logged events at intervals no greater than 15 calendar days to find incidents that alerting missed, and for high impact BES Cyber Systems it extends to their associated EACMS and PCA.
Audits tend to fail on the connection between these parts, not on the existence of a logging tool. Teams often have logs on many hosts, but cannot show which logs belong to which Applicable Systems, so the logging scope does not match the impact rating from CIP-002. Retention is frequently assumed rather than shown, with no record of the actual oldest retained event on each in-scope system. Review under Part 4.4 is often informal, with no dated record of who reviewed which summary, what was sampled, and what was escalated. Confirm with your Compliance Enforcement Authority how it expects scope and review to be documented, and confirm which of your systems count as high impact, since that decides the review obligation. The stakes are significant: the maximum civil penalty referenced in NERC's Sanction Guidelines under 18 CFR 385.1602 is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906, so an unmonitored or unreviewed system can carry a large exposure long before anyone notices.
The practical work is to map each in-scope asset to its logging source, set the alert rules and retention period, and schedule a review that leaves a dated record. A self-hosted platform can produce much of that evidence, but only if its configuration is tied to the asset list. Log sources, alert rules, retention settings and review records should all trace back to one scoped inventory, so an assessor can pick any in-scope system and follow the chain. Whether a given tool can meet Part 4.3 on a particular asset depends on its storage and configuration, so confirm feasibility per system and document any technical limit.
Which systems, teams and providers R4 covers
Scope decides how much of R4 applies and who does the work. The decisions below set which assets, people and third parties must be inside the logging and review program, and each one must be confirmed against the entity's own CIP-002 categorization.
Applicable systems column
CIP-007-6 scopes each Part through an Applicable Systems column, so R4 does not reach every asset the same way. Read the column for Parts 4.1 to 4.4 and record which BES Cyber Systems, EACMS, PACS and PCA fall under each row. Confirm this against your own CIP-002 categorization before you size the logging work. Illustrative example: a medium impact system with no External Routable Connectivity may sit outside a row that a high impact system must meet.
High impact systems and 15-day review
The 15-day review of summarized or sampled events applies to high impact BES Cyber Systems and their associated EACMS and PCA. Medium impact and low impact systems do not carry that review interval under R4 Part 4.4. Identify which assets carry high impact status under your CIP-002 analysis, then list the EACMS and PCA linked to them. Those linked devices are the ones that need the 15-day cadence.
Logging at the Cyber Asset level
Part 4.1 requires logging at the BES Cyber System or Cyber Asset level, so the unit of logging is a device or system, not a network segment or a central collector. Build an inventory that maps each in-scope asset to its log source, its operating system or application, and the events it emits for successful logins, failed access attempts and detected malicious code. Gaps often appear on devices that log only to a local buffer.
Operations and security operations roles
Operations staff own the BES Cyber Systems that generate the logs, so they must confirm which events each system writes and how long they stay on the device. Security operations staff own the alerting rules for malicious code and logging failures under Part 4.2, plus the investigation path when an alert fires. Document who receives each alert and who has authority to escalate to the CIP Senior Manager.
Reviewers and the CIP Senior Manager
The people who perform the Part 4.4 review must be named, trained for the work, and able to tell a routine event from a possible undetected Cyber Security Incident. The CIP Senior Manager, or a delegate recorded under CIP-003, should approve the review method and receive exceptions. Keep reviewer assignments current so the 15-day cycle does not depend on one person.
Third parties that host or monitor logs
A managed security provider, a cloud logging service or a hosted SIEM that stores or analyzes CIP logs becomes part of the R4 program. Confirm in writing where the logs reside, who can access them, how long the provider retains them, and how the entity can export them for a 90-day retention check. Any BCSI in those logs also brings CIP-011 and cloud considerations into scope. Ask providers to confirm that their monitoring service supports the alerting and review workflow you need.
How an assessor tests R4 and what they ask to see
This table walks through the test steps a Regional Entity auditor typically follows for CIP-007-6 R4, from confirming asset scope to checking review records. Read each row as a question the auditor asks, the records they request, and the gap that most often leads to a finding.
| Test step | Evidence requested | Common finding |
|---|---|---|
| Confirm asset scope and applicable systems | Asset list showing which BES Cyber Systems, associated EACMS and PCA fall under R4, with impact rating from CIP-002 | Scope list omits EACMS or PCA, or does not match the CIP-002 categorization |
| Sample logged events for successful logins (Part 4.1) | Log extracts from sampled Cyber Assets showing successful login events with timestamps and account identifiers | Successful logins are not logged on some device types, or logs lack a user or source field |
| Sample logged events for failed access and login attempts (Part 4.1) | Failed login and failed access records for the same sample period, with the logging configuration in effect | Failed attempts are captured on servers but not on network or applications, or logging was disabled during maintenance |
| Sample logged events for detected malicious code (Part 4.1) | Malicious code detection events from the anti-malware or detection tool, linked to the asset and date | Detections exist in the tool console but are not forwarded to the central log store |
| Check alert configuration for malicious code and logging failure (Part 4.2) | Alert rules or notification settings, recipient lists, and a documented list of security events the entity decided need alerts | Alerts for malicious code are not configured, or no alert exists for loss of event logging |
| Check alert handling (Part 4.2) | Sample alert tickets or notifications with acknowledgment, investigation notes and closure | Alerts fire but no record shows who reviewed them or what action followed |
| Request retention records for 90 consecutive calendar days (Part 4.3) | Log storage configuration and proof of retained logs covering any 90 consecutive days in the audit period, plus any documented CIP Exceptional Circumstances | Retention is shorter than 90 days on some systems, or gaps appear after log rotation or storage migration |
| Request review records at intervals no greater than 15 calendar days (Part 4.4) | Dated review records or summaries for each interval, with the reviewer's name and the high impact systems covered | Review intervals exceed 15 days, reviewer identity is missing, or reviews cover only a subset of high impact assets |
How to implement R4 in six steps
This sequence takes a team from the CIP-002 asset list to a working CIP-007-6 R4 program, with each step producing a record the compliance lead can hand to an auditor. The steps follow the order the work naturally happens, so later steps depend on the outputs of earlier ones.
Confirm the applicable asset list from CIP-002
Start from the approved CIP-002 categorization and extract every BES Cyber System, with its impact rating, that falls under the Applicable Systems column for Part 4. For high impact systems, include their associated EACMS and PCA, because the 15-day review applies to them. Engineering confirms the list against the asset inventory and the compliance lead signs it off. The output is a dated asset register that maps each Cyber Asset to its system, impact rating and role.
Define the required event types per asset
For each asset on the register, document which events meet the Part 4.1 minimums: detected successful logins, detected failed access and login attempts, and detected malicious code. Record the log source that produces each event type, such as operating system authentication logs, application audit logs or antivirus detections. Where a device cannot produce one of these events, record that gap and the compensating control now in place. The output is an event matrix showing each asset, each required event type and its source.
Configure log sources and time synchronization
Enable logging on each source identified in the matrix and forward events to the central collection point so that every entry is captured at the BES Cyber System or Cyber Asset level. Confirm that clocks on all sources are synchronized to a common reference, so that events from different devices can be ordered during an investigation. Test by generating a known failed login and a known malicious code test event, then verifying both arrive at the collector. The output is a configuration baseline and a test record showing each required event type was received.
Set retention storage and deletion controls for 90 days
Build a retention store that keeps the Part 4.1 logs for at least the last 90 consecutive calendar days where technically feasible. Restrict who can modify or delete log data, and configure automated deletion so that records are removed only after the retention period, unless a CIP Exceptional Circumstance applies and is documented. Confirm the retention setting with a test that shows logs older than 90 days are removed while newer logs remain intact. The output is a retention configuration with access rights and a documented result of the deletion test.
Define alert rules and the logging failure alert
Create alert rules for detected malicious code and for any failure of event logging, since Part 4.2 requires both at minimum. Then have the entity decide which other security events need an alert, document each decision with its reason, and assign a responder for every alert channel. Test each rule by triggering it and confirming the notification reaches the responder. The output is an alert rule register that lists each rule, its trigger, the responder and the test evidence, along with the entity's written rationale for the additional alerts it chose.
Create the 15-day review procedure with recorded output
Write a procedure for reviewing a summarization or sampling of logged events at intervals no greater than 15 calendar days, aimed at finding undetected Cyber Security Incidents on high impact BES Cyber Systems and their associated EACMS and PCA. Name the reviewer, describe the summary or sample method, and list the questions the reviewer answers, such as unusual login sources or repeated failures. Schedule the reviews and store each completed review with its date, reviewer, sample scope and any follow-up ticket. The output is the signed procedure and a log of completed reviews that the compliance lead can present as evidence.
Evidence that passes an R4 review
An auditor testing CIP-007-6 R4 wants to see that logging is configured, that alerts fire and reach people, that logs are kept, and that someone reviewed them on schedule. The cards below cover the artifacts that prove each of those points and how to refresh them between audits without rebuilding the file at audit time.
Logging configuration per asset type
Keep a current table that lists each BES Cyber System, EACMS, PCA and other in-scope Cyber Asset, the event types it logs, and the log destination. Part 4.1 expects logging at the Cyber Asset level for successful logins, failed access attempts and detected malicious code, so a single platform-wide statement is weak evidence. Export the actual configuration (for example, the Nextcloud admin_audit settings or the OpenBao audit device list) and date it. Refresh the export monthly and whenever a log source is added or changed, with a change record that names who made the change.
Sample exports of logged events
Keep dated exports that show the three required event types: successful logins, failed access and login attempts, and detected malicious code. An examiner will ask for a specific device and a specific time window, so exports should carry hostnames and timestamps rather than summaries alone. For OpenBao, the audit device log records each API request and response, with most sensitive values hashed. Pull a sample for each event type each month so the file always contains recent proof that the logging works.
Alert rule definitions and delivery records
Part 4.2 requires alerts for the security events you decide need one, and at minimum for detected malicious code and failed event logging. Keep the rule definitions as text or exported files, with the rule owner and the date each rule last changed. Pair them with delivery records such as Slack or email logs, or Wazuh entries in alerts.json, showing that alerts reached a monitored channel. Test one rule each month and retain the test ticket. Confirm which alert channels your platform supports before you rely on them as evidence.
Logging failure test results
Alerting on failed event logging is a distinct requirement from logging itself, so the file needs proof that you tested the failure path. Stop or disconnect a log forwarder on a non-production asset, confirm that an alert fires, then restore the feed and record the result. Keep the test plan, the timestamps, the alert received and the ticket that closed the test. Repeat the test on a schedule you define and after any change to the logging pipeline. Repeat this test in each period you claim, so an auditor does not find a single test from years earlier.
Retention settings and storage proof
Part 4.3 requires keeping the Part 4.1 logs, where technically feasible, for at least the last 90 consecutive calendar days. Show the retention setting in the platform, the storage location and a current listing that proves the oldest retained log is at least 90 days old. Document any asset where retention is not technically feasible and the basis for that decision, and check whether any CIP Exceptional Circumstance applies. Keep a dated storage report each month. Confirm with your platform vendor how its indexer or log store applies retention, because default settings vary by product.
Dated review records with reviewer names
Part 4.4 requires reviewing a summary or sample of logged events at intervals no greater than 15 calendar days, to find undetected Cyber Security Incidents, for high impact systems and their associated EACMS and PCA. Each review record should show the date, the reviewer's name, the method (sample or summary), the log window covered and any findings with their ticket numbers. Use a fixed calendar so the gaps between reviews stay visibly within 15 days. Reviewers should work from saved searches or dashboards so that the same method repeats across cycles.
What meeting R4 costs in money and effort
This table lists the cost components of running CIP-007-6 R4 monitoring, who is paid for each, and what moves the total up or down. Use it to build a written scope and quote request, because the total depends on your asset count and log volume rather than on any single license fee.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Log platform or licenses | Recurring if commercial; none for the software itself if self-hosted open source | Commercial per-volume or per-host pricing, premium modules for correlation or analytics, and extra editions needed for features you require | Confirm each component's license and edition limits in writing before choosing; self-hosted open-source tools remove license spend but not the cost of running them |
| Storage for 90 days of logs | Recurring, scaling with retention and volume | Number of Cyber Assets in scope, verbose logging levels, and retention on fast storage instead of archival tiers | Set logging levels to what Part 4.1 requires plus what you need to investigate, and size storage from measured daily volume in a pilot |
| Engineering to configure sources and alerts | One-time, with ongoing changes | Number of device types with different log formats, custom parsers, and the number of alert rules you must define for Part 4.2 | Standardize device types, reuse tested rule sets, and document the alert criteria once so changes stay small |
| Recurring 15-day log review | Recurring labor | Number of high impact BES Cyber Systems and associated EACMS and PCA, and how much manual sampling is done each cycle | Automate summarization and triage, define a repeatable sampling method, and record each review so the work is quick to repeat |
| Evidence upkeep | Recurring | Number of review cycles, retention checks, and alert tests that must be shown to an auditor, plus changes to the asset list | Keep evidence generation automated where possible, with a fixed folder and naming scheme tied to each 15-day review |
| External review or testing | Usually one-time or periodic, by engagement | Scope of the review, number of systems tested, and whether logging failures are simulated against live assets | Agree a fixed scope in writing, test on representative systems first, and avoid open-ended retainers until the process is stable |
| Auditor sampling time | Recurring, set by the audit cycle and the Compliance Enforcement Authority | Volume of logs, number of review records requested, and gaps in documentation that cause follow-up requests | Prepare a sample-ready evidence set before notification, since the auditor's time is driven by how quickly they can verify records |
Self-hosted open-source tools that can produce R4 evidence
Part 4 of CIP-007-6 asks for logs, alerts, retention and periodic review, and an assessor will want to see where those records come from and how they are kept. The four tools below each produce a different kind of record, so most programs will combine more than one. None of them makes an entity compliant on its own.
Wazuh alerting on collected logs
Wazuh decodes the logs it collects and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matches are written to alerts.log and alerts.json and forwarded to the Wazuh indexer for review in the dashboard. Check that the collection scope covers every in-scope BES Cyber System and Cyber Asset, and that the rules you rely on detect the successful logins, failed attempts and malicious code that Part 4.1 names. Confirm the rule coverage against your own asset list.
OpenSearch Security Analytics detectors
Security Analytics runs detectors that match ingested logs against prepackaged or custom Sigma rules and records each match as a finding with its rule, log type and severity. Findings can be sent as alerts to Slack or email, and the correlation engine links related findings across log types in a correlation graph. This is the place to define which security events require an alert under Part 4.2, and to test that a missing log source or failed logging is itself alerted. Confirm how long findings and indexed logs are kept in your deployment.
Nextcloud admin_audit logging
The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. For a CIP program, this covers administrative activity on a self-hosted Nextcloud instance if that instance is in scope as a BES Cyber System or an associated system. Confirm that the log path sits on storage that is protected and retained for the required period, and that the file is forwarded to the central log platform rather than left only on the host. Nextcloud is licensed under AGPL-3.0-only, so check the license terms with your legal team before modifying the app.
OpenBao audit device records
OpenBao audit devices keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256 so the log does not expose secrets in plain text. This is useful evidence for successful and failed access to secrets and authentication endpoints. Confirm that the audit device is enabled before any access occurs, that a failure to write to it blocks requests where your design requires that, and that the logs are retained for the full period your program sets. OpenBao is licensed under MPL-2.0.
Who does what for R4: your team, a partner and the auditor
Your organization owns CIP-007-6 R4 from start to finish. That starts with the applicable-asset decisions: confirming which BES Cyber Systems are high impact, which Cyber Assets fall within the BES Cyber System level, and which associated EACMS and PCA are in scope for the Part 4.4 review. It also covers the Part 4.2 determination of which logged security events need an alert, because that judgment reflects your own risk assessment and cannot be delegated to a vendor's default rule set. Your staff perform the periodic log summary or sample review, document what they found, escalate possible Cyber Security Incidents, and sign off on the results.
- Applicable-asset scoping: Maintain the list of systems in scope for R4 and keep it aligned with your CIP-002 categorization.
- Alert determinations: Decide, in writing, which events besides detected malicious code and logging failures need alerts, and why.
- Review performance: Assign named reviewers and record each review at intervals no greater than 15 calendar days for high impact systems.
- Retention decisions: Own the 90-day retention setting and any use of CIP Exceptional Circumstances, with written justification.
- Sign-off: Approve procedures, review records and any incident escalation before they are presented to an auditor.
Check that every reviewer and approver can explain the procedure without reading the vendor documentation.
An implementation partner such as DeployOpen can do the technical preparation that R4 depends on. Work is carried out inside your own environment, on infrastructure you control, and the partner's deliverables are configurations, procedures and exported evidence that your team reviews. The partner does not decide what is in scope, does not perform the reviews the evidence supports, and does not issue any compliance conclusion. Engagements are typically fixed-scope, with the scope and deliverables agreed in writing before work starts.
- Log source configuration: Connect in-scope hosts, applications and network devices to the central log platform and verify that the Part 4.1 event types are captured.
- Tool deployment: Install self-hosted tools such as Wazuh, OpenSearch Security Analytics or the audit devices of other platforms inside your network or accounts.
- Detection rule work: Build and tune alert rules against the events your team has determined need alerts, and document the rule logic.
- Evidence packaging: Set up exports that show logged events, alerts, retention settings and review records in a form your team can hand to an auditor.
- Procedure documentation: Write the R4 procedure and runbooks for your staff to adopt, then test them with your team.
Ask the partner to state in the scope which tasks it will not perform, including the review and the determinations, so that responsibilities stay on paper.
The auditor is the Compliance Enforcement Authority, which is a Regional Entity or NERC staff, or an assessor acting for that body. Compliance is monitored through Compliance Audits, Spot Checks, Self-Certifications and similar mechanisms, and there is no CIP certificate. The auditor tests whether your controls operate as documented, samples logs and review records, and issues findings. Because the auditor must be independent of the work it examines, a partner that built the monitoring cannot perform the review it prepared evidence for, and cannot certify the result.
- Independent testing: The auditor samples events, alerts and review records across the audit period rather than accepting a demonstration.
- Evidence sufficiency: The auditor checks that logs show the required event types and that retention covers the required 90 consecutive calendar days.
- Review verification: The auditor compares review records against the 15-calendar-day interval and asks how reviewers identified undetected incidents.
- Findings and mitigation: Any gap becomes a finding, which your organization addresses through its own mitigation plan.
- Independence: A partner may support your readiness, but its role ends at preparing systems and evidence.
Before an audit, confirm the audit period and evidence retention with your Regional Entity and make sure your team can explain each record without the partner present.
Where R4 programs usually fall short and how to close each gap
Most R4 findings come from logging that exists in configuration but cannot be shown for the right systems, for the full retention window, or with a record of who reviewed it. The gaps below connect scope, retention, alerting, review and change planning, so each fix produces evidence an auditor can sample.
Logs not scoped to applicable assets
Logging is often enabled on the systems that are easiest to reach, while Part 4.1 applies to the BES Cyber Systems and Cyber Assets within the standard's applicable systems. Build an inventory from your CIP-002 categorization, then record each in-scope asset's logging source and the event types it sends. Test the inventory against a few assets an auditor might pick, including associated EACMS and PCA where they apply. Any asset missing from the list is a finding waiting to happen.
No proof of 90-day retention
Part 4.3 requires keeping the Part 4.1 logs, where technically feasible, for at least the last 90 consecutive calendar days, unless CIP Exceptional Circumstances apply. Retention settings that are never checked can fail silently, and a log store that rolls over early will fail a sampled date. Set retention in configuration, then export a dated report showing the oldest retained event for each source. Document any case of technical infeasibility with its approval and compensating steps.
Logging failures never alerted or tested
Part 4.2 requires alerts for at least detected malicious code and detected failure of event logging. Many programs alert on malware but say nothing when a log forwarder stops, so a silent gap goes unnoticed for weeks. Configure an alert for missing log sources using whatever rule or pipeline monitor your platform supports, and confirm that capability with the vendor before relying on it. Then stop one forwarder in a test environment, and keep the dated result as evidence.
Review without a dated record or reviewer
Part 4.4 requires reviewing a summarization or sampling of logged events at intervals no greater than 15 calendar days to find undetected Cyber Security Incidents, for high impact BES Cyber Systems and their associated EACMS and PCA. Auditors look for who reviewed, which sample or summary was used, when it happened, and what was found. Keep one signed review record per cycle, with the saved query, the named reviewer and any escalation linked to the incident ticket.
Malicious code alerts without a response path
An alert on malicious code only supports R4 when someone acts on it under a defined procedure. Programs often send these alerts to a shared mailbox with no owner, no severity levels and no link to the CIP-008 response plan. Assign an accountable owner, define triage steps and escalation into incident handling, and run one tabletop alert through the path. Export matching alerts with their disposition, so the record follows each event from detection to closure.
Planning for CIP-007-7.1 by 1 July 2028
FERC Order No. 919 approved a set of revised standards for virtualization, including CIP-007-7.1, which NERC lists as effective 1 July 2028. Virtualized environments change where logs originate, such as hypervisors, guest systems and management planes, so a logging scope drawn for physical hardware may no longer match. Compare the approved text with your current R4 sources, confirm which hypervisor and management logs your platform can export, and schedule the changes well before the effective date.
Questions buyers ask about R4 cost, effort and outside help
How much effort does CIP-007-6 R4 take for a small set of assets?
No supplied figure gives hours or cost for R4, so the effort depends on what you must do, not on a fixed number. R4 asks for four things: logging successful logins, failed access attempts and detected malicious code, alerting on malicious code and logging failures, keeping logs for 90 consecutive calendar days where technically feasible, and reviewing a summary or sample of events at intervals no greater than 15 calendar days for high impact systems. For a small set of assets, the main drivers are how many log sources exist, whether logs already leave each device, where they are stored, and how much review time the sampling process needs. Ask any partner for a written breakdown by log source, alerting rule, retention store and review cadence, and confirm each item against your own environment.
Can our in-house staff meet CIP-007-6 R4 without outside help?
Yes, an entity can meet R4 with in-house staff, because the standard places the obligation on the registered entity, not on any vendor or consultant. The practical question is whether your team has the skills to configure logging at each BES Cyber System or Cyber Asset, build alert rules, manage retention, and perform and document the 15-day review. Teams that already operate a SIEM or log platform often need less help than teams starting from scratch. Consider outside help if you lack engineers who can configure log sources, if your environment has many device types, or if your team cannot staff a recurring review. Your compliance lead should decide, and the record of who reviewed what and when must stay under your control.
How long does R4 implementation take, and what must we confirm first?
No supplied fact gives a implementation duration, so treat any timeline you receive as a claim to verify. Start by confirming which BES Cyber Systems, EACMS and PCA fall under R4 for your impact rating, since high impact systems carry the 15-day review obligation. Then confirm which devices can generate the required events, whether logging is enabled today, where logs will be retained, whether retention meets the 90-day rule or a CIP Exceptional Circumstance applies, and who is accountable for the review. A written scope should state these assumptions so that any change to them is visible.
What does the work need from our team?
R4 needs three things from your team before any tool is configured. First, an accurate asset inventory that shows which Cyber Assets belong to each applicable system category. Second, access to log sources, including administrator access to each device or platform that produces authentication, access and malicious code events. Third, named reviewers with time in their schedule for the summarization or sampling review, plus a backup reviewer so the 15-day interval is not missed during leave. Expect your security operations and system administration staff to be involved in configuration and testing, and expect your compliance team to define the evidence they will show an auditor.
Can a partner certify that we are compliant with CIP-007-6 R4?
No. A partner cannot certify compliance, and no CIP certificate exists. Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through audits, spot checks, self-certifications, self-reports and other mechanisms. DeployOpen plans, implements, configures and documents systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Your organization owns the controls and the compliance decision, and the independent assessor or the Regional Entity makes the determination. Ask any provider to state in writing what it will and will not deliver.
Do open-source tools remove the need for licenses for R4?
Open-source tools remove the need for a license fee for the software itself in many cases, but they do not remove license terms or support costs. Each project carries its own license, and the license governs how you may use, modify and distribute it. Wazuh is licensed under GPL-2.0-only, OpenSearch under Apache-2.0, and OpenBao under MPL-2.0. Check the license and the edition you deploy, since some features may depend on paid editions or add-ons. Also budget for the people who configure, operate and review the tools, and for any support or retainer you choose. Confirm the license and edition limits for each component before you commit to an architecture.
What should we ask for in a written scope for R4 work?
A written scope should list the applicable systems, the log sources in each category, the events to be logged against the four R4 parts, the alert rules and recipients, the retention store and retention period, the review procedure and interval, and the evidence the engagement will produce. It should also state who owns each control, what the partner will not do, the assumptions about your environment, the acceptance criteria, and the change process when scope shifts. Ask for deliverables, dependencies you must provide, and a fixed price or fee basis tied to that scope. The scope is the basis for a quote, so ask for it in writing before work starts.
How DeployOpen scopes and prepares R4 evidence
DeployOpen plans, implements and documents the event logging, alerting, retention and log review that CIP-007-6 R4 expects, inside the client's own infrastructure. The organization owns its controls and its CIP program, and an independent Regional Entity or NERC auditor is the only party that assesses compliance.
How we scope
- Confirm which BES Cyber Systems and Cyber Assets fall under R4 based on the client's CIP-002 categorization.
- Identify which systems are high impact, so the 15-day log summary review in Part 4.4 applies to the right assets.
- Document scope, deliverables and timelines in writing before any work starts, as engagements are fixed-scope.
How we build
- Configure log collection for successful logins, failed access attempts and detected malicious code at the Cyber Asset level.
- Set alert rules for malicious code detections and event logging failures, and test that alerts reach the responsible team.
- Set retention for at least 90 consecutive calendar days, and confirm storage capacity and any CIP Exceptional Circumstances handling with the client.
How we hand over
- Deliver a written R4 procedure that names the logged events, alert recipients, retention period and review cadence.
- Provide evidence records such as log samples, review sign-offs and alert test results, mapped to each Part of R4.
- Walk the client's compliance and operations staff through the evidence set so they can answer an auditor's sampling requests.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, including re-checking logging after system changes.
- Ask the client to confirm which team owns the 15-day review and how reviewer independence will be recorded.
- Ask any implementation partner for a written list of what they will not do, since only the auditor issues compliance findings.
