Does Security Onion help meet NERC CIP-015-1 internal network security monitoring?
Security Onion can supply the sensors, network data feeds, detection logic and retained monitoring data that CIP-015-1 Requirements R1 to R3 call for on networks inside an Electronic Security Perimeter. The documented processes, the risk rationale for choosing data feeds and the audit evidence remain the entity's responsibility. If you operate high impact BES Cyber Systems, or medium impact BES Cyber Systems with External Routable Connectivity, start by confirming which networks sit inside each ESP, because that scope drives how many sensors you need and where they go. According to the CIP-015-1 implementation plan, enforcement for Control Centers begins on 1 October 2028, with other medium impact systems phased in over the following 24 months.
Security Onion maps most directly to Part 1.1, which asks for network data feeds selected on a risk-based rationale to monitor connections, devices and network communications. Suricata and Zeek sensors on traffic inside the ESP produce those feeds. Zeek includes support for ICS and SCADA protocols such as BACnet, DNP3, Modbus, OPC UA and S7, but you should confirm that the protocols in your environment are covered and that sensors can see traffic between devices inside the perimeter, not only at its edge. For Part 1.2, the Console Detections interface manages Suricata NIDS rules and Sigma rules, with modify, suppress and threshold tuning. For Part 1.3, analysts evaluate alerts in the Console. Your tuning decisions and evaluation criteria must still be written down and approved, because the platform does not decide what counts as a finding under your process.
Security Onion does not satisfy the documented-process part of R1 by itself. It does not write your risk rationale for choosing data feeds, define what counts as anomalous for your systems, set escalation paths or determine your ESP scope from the CIP-002 impact categorization. Sensor placement and rule tuning need approval records that you keep. For R2, Security Onion can retain data associated with anomalous activity, but you must set retention so that the data survives at least until the related action is complete, and you should test that storage sizing and retention settings hold under load. In a distributed design, the architecture documentation notes that search nodes stop indexing if the manager goes down, so plan for that outage. For R3, the Pro edition adds LUKS data-at-rest encryption, OIDC single sign-on and FIPS mode, but protection against unauthorized deletion or modification also depends on your administrative roles, log separation and change control, which you must design and evidence.
Security Onion is source-available under the Elastic License 2.0, not an OSI-approved open-source license, so have your legal team confirm that the license terms fit your procurement and distribution needs before deployment. CIP also has no certificate. Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through methods such as Compliance Audits, Spot Checks and Self-Certifications. DeployOpen plans and builds Security Onion inside your infrastructure and prepares systems, configuration records and evidence for those assessments. DeployOpen does not certify, audit or issue attestations. Ask any implementation partner, including DeployOpen, to list the evidence they will deliver and the evidence that remains your job to produce.
Mapping CIP-015-1 R1 to R3 to Security Onion capabilities and configuration
This table maps CIP-015-1 Requirement R1, its Parts 1.1 to 1.3, and Requirements R2 and R3 to the Security Onion components that support each one and the decisions the entity must make. Read the configuration column first, because the platform supplies the tooling while the entity sets the risk rationale, tuning baseline, retention and access policy. The main takeaway is that Security Onion can produce monitoring evidence, but compliance depends on documented choices that an auditor can review.
| Requirement | Platform capability | Configuration needed |
|---|---|---|
| R1: Monitor and detect anomalous network activity | Documented monitoring process supported by sensors inside the ESP feeding the Security Onion Console | Entity documents monitored systems and confirms the enforcement date for each asset class, with Control Centers from 1 October 2028 |
| Part 1.1: Network data feeds | Zeek and Suricata telemetry from sensors, including ICS protocol parsing for Modbus, DNP3, BACnet, OPC UA and S7 in a Distributed design | Entity selects feeds by a documented risk-based rationale covering ESP boundaries and ICS protocols, then sizes sensors and receiver nodes |
| Part 1.2: Methods to detect anomalous activity | Suricata NIDS rules and Sigma rules managed in the Detections interface, with modify, suppress and threshold tuning | Entity sets the tuning baseline, rule sources and suppression approvals, and records each change |
| Part 1.3: Methods to evaluate anomalous activity | Analyst triage and tuning of alerts and events in the Console | Entity defines triage procedures, severity thresholds and reviewer roles, with evidence that alerts were reviewed |
| R2: Retain data for anomalous activity | Retention of monitoring data tied to alerts and case records for anomalous activity | Entity sets retention periods that last at least until the related action is complete and links each case to its alerts |
| R3: Protect monitoring data from tampering | Role-based access to the Console, with copy protection depending on controls outside the platform | Entity restricts roles, protects exports and backups, and decides whether Pro SSO and LUKS encryption are required |
Which systems CIP-015-1 reaches before you place a Security Onion sensor
CIP-015-1 Requirement R1 applies to networks protected by the Electronic Security Perimeters (ESPs) of two groups: high impact BES Cyber Systems, and medium impact BES Cyber Systems with External Routable Connectivity. The monitoring obligation attaches to the network protected by those ESPs, so a Security Onion sensor placed on a segment outside those perimeters does not bring that segment into scope. Low impact systems are not reached by R1. Before you decide where a sensor's network data feed comes from, identify which ESPs exist, which systems each one protects, and how each of those systems is classified. Those answers determine the monitored boundary, and the sensor design follows from them.
The category comes from CIP-002-5.1a, which applies bright-line criteria in its Attachment 1 to sort each BES Cyber System into high, medium or low impact. High impact generally covers qualifying Control Centers, such as those operated by Reliability Coordinators. Medium impact includes, for example, generation of 1500 MW or more at one plant, and Transmission Facilities at 500 kV or higher. A system close to a threshold needs its calculation recorded in your classification worksheet. NERC also lists CIP-002-8, which revises the Control Center definition and takes effect on 1 July 2028. If any Control Center classification depends on that definition, check it against the revised text before you size the monitored segments.
Enforcement timing depends on the category. According to the CIP-015-1 implementation plan, R1 becomes enforceable on 1 October 2028 for Control Centers. Other medium impact systems with External Routable Connectivity are phased in over the following 24 months, so the date that applies to a substation or generation site follows that phase-in schedule. Multi-site operators should map each site to its phase before setting a deployment order. Plan the documented processes and sensor coverage for the earliest date that touches any site in your fleet, and confirm the phase assignment in writing with your Regional Entity.
CIP-015-2 extends internal network security monitoring to associated Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). NERC lists it as approved by FERC on 10 August 2026, with an effective date of 1 October 2029. A design that covers only the ESP interior will leave those access control and physical access systems outside the monitored data once that version applies, so it is worth planning for them now. Separately, FERC Order No. 919 approved 11 revised CIP standards that accommodate virtualization, which NERC lists as effective 1 July 2028. If your BES Cyber Systems, EACMS or PACS run as virtual machines or in containers, confirm early with your Regional Entity how those revisions affect the systems in scope and the traffic a sensor can see.
Before any sensor is placed, assemble four records: the CIP-002 classification worksheet with the bright-line results, ESP boundary diagrams that show every External Routable Connectivity path, the list of associated EACMS and PACS, and the virtualization inventory. Ask your Regional Entity which compliance monitoring method is likely to apply to your entity, and whether it will accept the planned monitoring boundary in writing. Record the answers in the design document. A sensor placed before scope is confirmed may need to move later, and a move changes the network data feeds you must justify on a risk basis under Part 1.1.
Choosing network data feeds for Part 1.1 with Security Onion sensors
Part 1.1 requires network data feeds selected through a documented risk-based rationale, and that choice shapes sensor placement, deployment layout, protocol coverage and redundancy. The cards below cover each decision in the order a design team usually meets it. Each one ends with a check to complete before the feed design is final.
Documenting the risk-based rationale
Part 1.1 requires the entity to select network data feeds using a risk-based rationale, and that document is usually the first thing an auditor asks to see. Record which ESPs, asset groups and communication paths each feed covers, the threats or failure modes it addresses, and why any excluded path is acceptable. Security Onion can only monitor what you send to it, so map each feed to named networks and assets instead of describing the platform in general.
Placing sensors at and inside the ESP
Place sensors where they can see traffic crossing each Electronic Security Perimeter, and add sensors inside the perimeter where communications between in-scope assets need visibility. The supplied hardware minimum for a sensor is 4 cores, 12 GB RAM and 2 NICs, so confirm that each planned host meets it and that its NICs can receive mirrored or tapped traffic. Confirm with your network team how span ports, taps and firewall logs are positioned before fixing the sensor count, because placement decides which feeds are possible at all.
Distributed deployment for production
Security Onion's Distributed deployment separates a manager node from one or more sensor nodes and one or more search nodes, and its architecture documentation recommends this design for production. Sensors stay close to the monitored networks while search and storage run on separate hardware. Plan manager, sensor and search node counts together, and confirm that the manager and search node minimums of 4 cores and 16 GB RAM cover the data volume you expect from your feeds.
Confirming ICS and SCADA protocol coverage
Zeek in Security Onion includes support for ICS and SCADA protocols including BACnet, DNP3, Modbus, OPC UA and S7. Product support is a starting point, and actual visibility depends on the protocols present in your network, the ports they use and whether traffic reaches a sensor on each segment. Take a sample capture from each ESP segment, confirm which protocols appear and which Zeek logs they produce, and record any absent or unparsed protocol as a gap in the feed rationale.
Manager outage and receiver redundancy
The Security Onion architecture documentation notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Detection and evaluation under Parts 1.2 and 1.3 depend on indexed data, so a single manager creates a monitoring gap for the length of the outage. Receiver nodes add pipeline redundancy and load balancing, so include them in the design and test the failover behavior your entity needs before relying on it.
Configuring Security Onion for a CIP-015-1 monitoring program
This sequence takes a Security Onion deployment from scoping to a tested monitoring path inside the electronic security perimeters covered by CIP-015-1. Each step produces a written record or configuration that your compliance team and auditors can check.
Confirm applicable systems and ESP boundaries
The compliance lead and the OT network owner list which BES Cyber Systems fall under CIP-015-1 Requirement R1, meaning high impact systems and medium impact systems with External Routable Connectivity, and map the Electronic Security Perimeter around each one. Confirm scope against your CIP-002 categorization and registration records, and check with your Compliance Enforcement Authority contacts where scope is unclear. The output is a boundary diagram showing every network segment inside the ESP where a sensor will be placed. Control Centers are the first systems subject to enforcement, from 1 October 2028, so note which of your systems fall into that group.
Document the risk-based data feed rationale
CIP-015-1 Part 1.1 requires network data feeds selected on a risk-based rationale that cover connections, devices and network communications. For each sensor, record the span port, TAP or mirror point it reads from, the segments it covers, the risk reasoning for choosing it, and any segments left out and why. Security Onion's Zeek includes ICS/SCADA protocol support for BACnet, DNP3, Modbus, OPC UA and S7, so note which of those protocols your segments carry and test parsing on sample traffic before you rely on it. The output is a feed register approved by the OT security owner and kept under change control.
Size hardware and select x86-64 nodes
Security Onion supports only x86-64 processors. The documented minimums are 4 cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node, 4 cores and 16 GB RAM for a manager or search node, and 4 cores, 12 GB RAM and 2 NICs for a sensor. Treat these as floors, not targets: the expected traffic volume on each monitored segment and the retention period you set in step seven will drive storage and memory above the minimums. Ask your hardware vendor for sizing against those inputs. The output is a bill of materials listing each node role, its specifications and its NIC layout, with one NIC dedicated to monitoring and the management interface kept separate.
Deploy the Distributed design or confirm it
Security Onion's Distributed design, with a manager node, one or more sensor nodes and one or more search nodes, is the recommended design for production. Confirm the design on paper first, including whether to add receiver nodes. The architecture documentation notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis, and receiver nodes add pipeline redundancy and load balancing. Where networks have no internet access, install from the Security Onion ISO, which carries packages and NIDS, YARA and Sigma rules, and apply later updates with the soup tool from newer ISO media in airgap mode. The output is a node inventory matching the design and a clean install check on every node.
Load and tune detection rules
Use the Detections interface in the Security Onion Console to manage the three rule sets: NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert, and YARA rules loaded into Strelka. For NIDS rules, you can modify, suppress and set thresholds, and for Sigma rules, you can add custom filters. Every suppression, threshold change and filter needs a ticket that records the rule ID, the reason, the owner, the approver and the date. Review the change log with the OT security owner before go-live. Airgapped sites load rule updates through the same soup process used for software. The output is a tuning log that lets an auditor trace why each alert is or is not raised.
Define anomaly detection and evaluation procedure
CIP-015-1 Part 1.2 requires methods to detect anomalous network activity and Part 1.3 requires methods to evaluate it. Write the procedure that covers how the team builds a baseline of normal traffic for each ESP, which alerts are triaged and in what order, how severity is assigned, who evaluates each alert, and when an alert is escalated to incident response. Analysts record each outcome in a Security Onion case that links the triggering alert, the evaluation and any follow-up action, so the case becomes the evaluation record. Confirm the case fields in your release before you finalize the template. The output is a written procedure and a case template with mandatory outcome fields.
Set retention and access controls
CIP-015-1 Requirement R2 requires retaining monitoring data associated with anomalous activity at least until the related action is complete, and Requirement R3 requires protecting collected and retained data against unauthorized deletion or modification. Set index retention so that data tied to open cases is kept until each action closes, and document any hold or export steps. Limit Console roles to named people, separate administrator accounts from analyst accounts, and review access on a schedule your procedure sets. Security Onion Pro adds OIDC single sign-on, LUKS data-at-rest encryption and FIPS mode, so decide whether your controls need them and confirm availability before you commit. The output is a retention schedule and an access review record.
Test the monitoring path before enforcement
Before the enforcement date that applies to your systems, test the full path from sensor to alert to case. Send known test traffic through each sensor, for example a harmless pattern that a chosen NIDS rule should match, and confirm the alert appears in the Console and can be opened as a case. Test how the team detects a sensor that stops reporting, and record what happens when the manager is taken offline, including the search node indexing behavior described in the architecture documentation. Check time synchronization across nodes. The output is a signed test report that lists each path, the expected result, the actual result and the corrective action for any failure.
How R2 and R3 shape retention and tamper protection in Security Onion
R2 requires the entity to retain monitoring data associated with anomalous network activity at least until the related action is complete. R3 requires the entity to protect collected and retained monitoring data against unauthorized deletion or modification. Security Onion can hold this data, but it does not decide how long data must be kept or who may change it. Those decisions belong to the entity, and they need to be written down before the sensors go into service. The two requirements work together: retention must last long enough to support evaluation and response, and the data must stay trustworthy for as long as it is held.
Retention is set by the entity in the platform, and the starting point should be the end of the related action, not the date the event was ingested. Security Onion stores different data types in different places, including indexed network metadata, alerts and packet capture. Confirm, for your installed version, which data types have their own retention settings and which share one. Then define how an anomalous event that is still under investigation is kept past its normal expiry. Test that a held event survives the expiry cycle before you rely on it. An illustrative example: a sensor flags a suspicious connection in one week, the case stays open for several weeks, and the entity needs the underlying records for that whole span.
Cases and tuning changes both affect what the entity must be able to explain later. A tuning action in the Detections interface, such as suppressing a NIDS rule, a threshold change, or a custom filter for a Sigma rule, changes what the monitoring will report from that point forward. Record the rule identifier, the reason, the author and the date, and link each change to the cases it affected. Ask whether the console keeps its own history of these changes, whether that history can be exported, and whether it can be kept outside the monitoring host. Without those links, an auditor who asks why an alert was silenced may not get a complete answer.
Protection against unauthorized deletion or modification depends on controls the entity has to design. Access to the Console, the manager and the search nodes should follow the entity's access control policy, and administrator roles should be split so that no single person can change retention, delete cases and alter tuning without another party seeing it. Keep copies of retained data and configuration outside the monitoring host, and forward logs of configuration changes to a system that the monitoring administrators cannot edit. Write the procedure for restoring from those copies and test it. The platform provides features, but the entity sets the boundaries.
Security Onion Pro lists OIDC single sign-on for the Console, LUKS data-at-rest encryption and FIPS mode among its features. Each can support R3 objectives, but none should be assumed to fit your environment. Confirm that your identity provider and its group mappings support the role separation you designed. Confirm how LUKS keys are created, stored and recovered, because key loss can make retained data unreadable. Confirm whether FIPS mode meets the cryptographic requirements your compliance team applies. Pro is a paid edition sold on 1 to 5 year terms, so ask for written documentation of each feature and its limits before you decide.
What evidence Security Onion produces for a CIP-015-1 audit
Each category below is a set of records that Security Onion can supply or help keep, and each is only part of the evidence. There is no CIP certificate. The Compliance Enforcement Authority, a Regional Entity or NERC, decides what evidence is sufficient through audits, spot checks or self-certifications. The entity writes the procedures and performs the evaluations, while the platform supplies the raw records.
Documented INSM process and owner
The written R1 process that states which ESPs are covered, which networks and sensors are in scope, how anomalous activity is detected and evaluated, and who owns each step. Security Onion does not produce this document. The entity writes it and names an accountable owner. Keep it in version-controlled storage with dated revisions and approval records, and link each revision to a change ticket. Check that the procedure matches what the Console actually runs, because an auditor will compare the two. Confirm the applicable systems under CIP-015-1 R1 against your asset classification before drafting the scope.
Sensor and feed inventory
A list of each Security Onion sensor node, the network data feeds it receives (connections, devices and communications), and the risk rationale for selecting each feed under Part 1.1. The platform supplies node configuration and deployment type. The rationale is your analysis. Export the node and feed list from your deployment records and store it with the risk assessment, dated and reviewed whenever the network changes. Confirm which Zeek and Suricata logs each feed produces in your version, and record any feed you excluded on purpose, with the reason.
Rule and tuning change history
The record of NIDS, Sigma and YARA rule changes, suppressions and threshold adjustments made through the Detections interface. Security Onion manages NIDS rules in Suricata, Sigma rules in ElastAlert and YARA rules in Strelka, with modify, suppress and threshold tuning for NIDS rules and custom filters for Sigma. Export the rule state on a schedule to versioned storage, and tie each tuning change to a ticket that records the reason and the approver. Auditors look for suppressions that quietly removed detection coverage, so review them periodically and record each review.
Alert and case records
Alert and case records that show detection under Part 1.2 and evaluation under Part 1.3 took place in practice. The Console holds the alerts and cases. The evaluation conclusions, escalation decisions and closure reasons come from your analysts following your procedure. Export case timelines with timestamps and analyst identity, and file them with the evaluation procedure they followed. Check that each case records its disposition and any action taken. An alert that was raised but never reviewed is weak evidence, so confirm that your queue workflow leaves a visible trail.
Retained anomalous activity data
Monitoring data tied to anomalous activity, kept at least until the related action is complete, as R2 requires. Security Onion stores this data in Elasticsearch indices and, where full packet capture is enabled, in Suricata-based capture. Set retention for each index and capture store to cover your longest expected action cycle, and document those settings with the reason for each. Confirm that your retention settings can hold anomalous-activity data longer than routine data if your procedure calls for it. Test a restore from retained data before an auditor asks for one.
Access and configuration logs
Records of who accessed the monitoring platform and what configuration changed, which support the R3 requirement to protect collected and retained data against unauthorized deletion or modification. Collect authentication events, administrator actions, role assignments and changes to retention or storage settings. Confirm which of these the Console and Elasticsearch layer log in your version. Where gaps exist, forward host and operating system logs to a separate store. Review access on a schedule, restrict who can alter retained indices, and file each review. The entity defines the access model and performs the reviews.
Questions buyers ask about CIP-015-1 and Security Onion
How much does a CIP-015-1 Security Onion monitoring implementation cost?
Cost follows from a written scope agreed before work starts. DeployOpen does not publish a price list, so a quote is built from that scope. The main drivers are sensor count and placement, which set how many network data feeds you monitor, and the number of ESPs in scope. Hardware is a separate cost. A Distributed design uses a manager node, sensor nodes and search nodes, and the Security Onion hardware documentation lists minimum resources for each role. Security Onion Pro is a paid edition sold on 1 to 5 year terms, so its license term is a recurring cost if you choose it. Documentation and evidence work, including the risk rationale for data feed selection and the processes R1 requires, is a separate line item. Ask each bidder to separate one-time services, hardware, software licensing and recurring support.
How long does CIP-015-1 internal network security monitoring take to implement?
The enforcement dates set the outer limit. According to the CIP-015-1 implementation plan, R1 becomes enforceable on 1 October 2028 for Control Centers, and other medium impact systems with External Routable Connectivity are phased in over the following 24 months. Your project length depends on the ESP inventory, meaning how many perimeters, routable connections and devices you must map before choosing data feeds. Change control is the next driver. Sensor placement and tap or SPAN changes inside an ESP typically pass through your change process and maintenance windows. Other factors include hardware lead times, the number of sites, the number of Distributed nodes, and how quickly your subject matter experts can supply the risk rationale. Ask any provider for a written schedule tied to milestones and your change calendar, and confirm your applicable systems with your compliance lead first.
What does our team need to provide for a CIP-015-1 monitoring project?
Your team provides access, people and decisions. Expect to share OT network diagrams, ESP boundary documentation and asset inventories, along with supervised access to the network segments where sensors will connect. Subject matter experts must explain the risk-based rationale for each network data feed, because Part 1.1 requires that selection to be risk based. Change approvals are needed for sensor placement, traffic mirroring, and any firewall or routing changes that the sensors depend on. Name one evidence owner who collects, dates and stores artifacts for each requirement and answers auditor questions later. Security staff should also own alert review and anomaly evaluation after go-live, since R1 requires documented processes that run continuously. Confirm these responsibilities and approval paths in the written scope before work begins.
Can our own team implement CIP-015-1 monitoring with Security Onion alone?
Yes, an entity can do this alone if it has staff who understand CIP-015-1 and Security Onion. The team needs people who can map ESPs and classify systems, build a Distributed deployment, write monitoring and evaluation procedures, and collect evidence in a form an auditor can review. Use the gap list as a checklist. It shows which requirement elements are missing from your current program, such as documented processes, the data feed rationale, detection methods, evaluation methods, retention of anomalous activity data and protection of monitored data against deletion or modification. Follow a build sequence: map perimeters first, then select feeds, deploy, tune detections and document each step as you go. Be honest with yourself about how much time your staff can commit alongside operational duties.
Does DeployOpen certify CIP-015-1 compliance for our organization?
No. DeployOpen plans, builds and documents monitoring systems and prepares the evidence that supports them, but it does not issue audit reports, attestations or certifications. CIP has no certificate. The Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance through methods such as Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and periodic data submittals. Independent auditors and that authority assess what your organization can demonstrate. Your compliance lead owns the applicability decisions and any attestations you make to the regulator. Ask any provider to state in writing what it delivers, such as configuration records, runbooks, test results and an evidence index, and who signs off on each item. Treat those deliverables as inputs to your own compliance program, which an assessor will evaluate.
Can Security Onion run on air-gapped networks inside an ESP?
Yes, Security Onion supports full installs on networks without internet access. According to its airgap documentation, the ISO carries packages along with NIDS, YARA and Sigma rules, and the soup update tool can apply updates from newer ISO media in airgap mode. This matters for many ESPs because routable connectivity and vendor access are tightly controlled. Plan how ISO media and rule updates will be transferred, approved and recorded, since those transfers become part of your change and evidence trail. Confirm the operating system path as well. Security Onion 3.0.0 supports only Oracle Linux 9, and the 2.4 line reaches end of life on October 1, 2026, so a new CIP deployment should be checked against that date before it starts. Also confirm that hardware is x86-64 and meets the minimums for each node role.
Does Security Onion's Zeek parse ICS protocols like DNP3 and Modbus?
Yes, according to Security Onion's Zeek documentation, Zeek includes support for ICS and SCADA protocols including BACnet, DNP3, Modbus, OPC UA and S7. Protocol parsing is a starting point for detection, not a complete answer. Engineers should confirm which protocols appear in each ESP, whether the sensor sees both sides of each conversation, and whether the parsed fields include the commands or function codes your anomaly methods need. Test against captured traffic from a lab or maintenance window before you rely on it. Part 1.2 requires methods to detect anomalous activity, so baselines and detection tuning matter, and Part 1.3 requires methods to evaluate what is detected. Document what the sensors cannot see, such as serial links or vendor-proprietary protocols, and route those gaps to subject matter experts for a documented risk decision.
How often are CIP audits held, and what are the maximum penalties?
Entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive a compliance audit at least once every three years, according to the NERC Rules of Procedure. The maximum civil penalty is $1,584,648 per violation per day, as set out in 18 CFR 385.1602. Confirm the audit cadence that applies to your own registration with your compliance team, since it depends on your functions and Regional Entity. Penalty outcomes depend on the facts of each violation, including its duration and how the entity responded. Your practical priority is a documented program that shows detection, evaluation, retention and protection of monitoring data working together, because an assessor looks for evidence that the process runs as written. Ask your compliance lead to map CIP-015-1 items to your current audit preparation calendar.
How DeployOpen scopes and delivers CIP-015-1 monitoring configuration and evidence
DeployOpen plans, builds, documents and supports Security Onion inside your own infrastructure, including sensors inside electronic security perimeters and networks without internet access. The work is organized around the monitoring processes, network data feeds, evidence and tamper protections that CIP-015-1 asks entities to show. Compliance outcomes are decided by your auditors and the Compliance Enforcement Authority, and DeployOpen prepares the systems and evidence they review.
How we scope
- The written scope names the ESPs, applicable BES Cyber Systems and network segments that sensors will monitor.
- Scoping records the risk-based rationale for each network data feed, since Part 1.1 requires selection on that basis.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Sensor and manager design follows the Distributed deployment type, the recommended production design for Security Onion.
- Zeek and Suricata feeds cover the protocols in scope, including ICS protocols such as DNP3, Modbus and S7.
- Detection rules are tuned in the Detections interface, with suppressions and thresholds documented for each change.
How we hand over
- Written procedures map each step to CIP-015-1 Parts 1.1 through 1.3 and R2.
- Retention settings for anomalous activity data are documented against the time needed to complete the related action.
- Access controls and tamper protections for monitoring data are tested and documented against the R3 protection expectation.
How we support
- Retainers cover ongoing support, upgrades and continuous testing of the monitoring stack after handover.
- Version planning tracks end-of-life dates, such as Security Onion 2.4 ending support on October 1, 2026.
- Support tickets and changes to sensors or rules are logged against the documented monitoring procedures.
