Why an open source SIEM for energy and utilities starts with the electronic security perimeter
If your organization is a registered entity under NERC CIP, the first design decision for a self-hosted SIEM is where it sits relative to your Electronic Security Perimeter, not which product to buy. A SIEM that ingests logs from BES Cyber Systems must either live inside the perimeter or receive data through a controlled, documented path across it, and auditors will ask which of those you chose and why. The answer depends on your BES Cyber System impact rating, which CIP-002 assigns as high, medium or low using bright-line criteria. Confirm that rating for each system with your compliance lead before you size anything, because it determines which CIP requirements apply and therefore which log sources the SIEM must cover. Entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator should also confirm their audit cycle with their Regional Entity, since the NERC Rules of Procedure set the compliance monitoring framework.
Agents are the second constraint. Many control devices, protective relays, historians and vendor-managed HMIs cannot run a Wazuh agent, and where they can, the vendor or the plant engineers may refuse changes to a validated system. Wazuh supports agentless collection through syslog and periodic API probing, so plan agentless syslog as the default for those devices and reserve agents for Windows and Linux hosts in the control zone where change control allows it. Keep the SIEM server and indexer in the same or a higher-trust zone than the sources they read, and treat any path that carries logs out of an ESP as a remote access and supply chain question that must be answered under CIP-005 and CIP-013 rather than assumed to be safe.
On platforms, a common starting point is Wazuh as the core SIEM and agent manager, paired with Security Onion where you need network visibility from Suricata and Zeek sensors on OT and IT segments. Both are available under licenses that suit an internal deployment, but Security Onion is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved, so have your legal team review its terms against your deployment and any managed service you plan to use. Confirm that each component supports the operating systems on your asset inventory and that the sensors will not interfere with protected control traffic before you deploy them into any ESP.
Which NERC CIP and NIS2 obligations shape the SIEM build
This table maps each relevant NERC CIP standard and the NIS2 energy scope to a concrete SIEM build decision, such as which networks feed the collector, where it sits and how remote access is logged. Read it as a checklist for scoping the design, then confirm each interpretation with your Regional Entity and compliance lead before procurement.
| Obligation | What it means for the SIEM build | What to confirm |
|---|---|---|
| CIP-002-5.1a impact categorization | Classify each BES Cyber System as high, medium or low impact first, since that decides which networks and assets the SIEM must cover and how strictly | Your impact rating for each system, with the rationale documented for auditors |
| CIP-005-7 Electronic Security Perimeter | Keep the SIEM collector and its storage inside the ESP or a defined, protected monitoring zone so log flow crosses the perimeter through controlled points | Whether the SIEM counts as an Electronic Access Point or is outside the ESP, and how log traffic is permitted through it |
| CIP-005-7 Intermediate System | Log every interactive remote access session that passes through the Intermediate System, including authentication events and the MFA result | Which Intermediate System product logs feed the SIEM, and whether session records are retained at the required depth |
| CIP-013-2 vendor remote access and software integrity | Collect vendor login, session and software update events, and alert on vendor access outside approved windows or channels | Vendor access paths and the evidence your supply chain plan requires you to review at least every 15 calendar months |
| CIP-015-1 internal network security monitoring | Plan east-west network monitoring with sensors such as Zeek or Suricata on the networks in scope, sized for the traffic you will inspect | Enforcement from 1 October 2028 and the exact scope of monitored network paths with your Regional Entity |
| Virtualized environments (Order No. 919) | Include hypervisor, management plane and virtual network logs in collection where workloads are virtualized | The effective date of 1 July 2028 and how your virtualized assets are classified |
| NIS2 Annex I energy scope | Electricity, district heating and cooling, oil, gas and hydrogen operators must log and monitor across IT and operational networks for incident handling | Which entities in your group fall in scope and the national authority's expectations for logs and retention |
| Cross-border electricity flows (Regulation 2024/1366) | Where interconnected flows apply, document the cybersecurity rules that shape log sharing with other operators and vendors | Whether the network code applies to your operations and what data you must share or receive |
Which open source platforms fit OT and IT monitoring
An energy or utility SIEM usually combines a host and log platform with passive network sensors, and each piece has different license, operating system and deployment limits. The cards below cover the platforms most often evaluated for this job and the checks to complete before any of them is selected for a control environment.
Wazuh for IT endpoints and servers
Wazuh combines an agent on endpoints, a server that decodes and correlates events, an indexer that stores alerts and a dashboard. Its core is licensed under GPL-2.0, which matters if your legal team reviews distribution terms. Agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, but many OT devices cannot run them, so plan syslog collection and API probing for those assets. Confirm which agent platforms your historian and engineering workstations support, and whether the offline vulnerability repository fits inside your segmented zones.
Wazuh agentless syslog and API collection
For firewalls, serial-to-IP gateways, protocol converters and other devices that cannot host an agent, Wazuh accepts syslog and can probe device APIs on a schedule. This is the usual route for logging from the Electronic Security Perimeter boundary. Check what each device can export, whether events are sent in cleartext across a zone boundary, and how time synchronization is handled, because correlation across IT and OT depends on accurate timestamps.
Wazuh offline vulnerability data
Wazuh correlates the software inventory that agents collect with vulnerability data from its Cyber Threat Intelligence platform or from an offline repository. Where systems cannot reach the internet, the offline repository is the path to use. Ask who imports that data, how often, and how the import is verified before it reaches a segmented network. Vendor patch availability in OT often lags IT, so the inventory and the advisory feed both need an owner.
Security Onion for sensor-based monitoring
Security Onion bundles Suricata, Zeek, osquery and Elastic components into a platform for network monitoring and hunting. It is licensed under the Elastic License 2.0, a source-available license rather than an OSI-approved one, so have counsel confirm it fits your procurement rules. Only x86-64 hardware is supported. For production, the Distributed design with a manager, sensors and search nodes is the recommended model, and the manager outage behavior should be part of your resilience plan.
Security Onion airgap and Pro features
Security Onion supports full installs without internet access, with the ISO carrying packages and detection rules, and the soup tool applies updates from newer media. Confirm the update cadence your OT change process allows. The paid Security Onion Pro edition adds OIDC single sign-on, FIPS mode, OS STIG compliance and professional support. Ask whether those features are required for your environment, and confirm current terms directly with the vendor.
Suricata and Zeek as passive OT sensors
Suricata performs intrusion detection from mirrored traffic, and Zeek produces protocol-level logs for industrial and IT protocols. Both are passive, so they can observe control network traffic through a SPAN or TAP without sending packets to controllers. Confirm which OT protocols each parser covers, whether your sensors can sit on the required segment without changing the ESP, and who maintains the rule sets for protocols vendors do not document publicly.
How the SIEM sits across control, DMZ and corporate zones
Control center and substation networks hold BES Cyber Systems, and many of the devices in them cannot run a third-party agent without vendor approval or a change to a certified configuration. For that reason, the default collection method in these zones is network-based: syslog from devices that support it, and passive sensors that observe traffic on a mirror or tap port. Any host that can run an agent, such as an engineering workstation or a historian server, should be assessed individually against the vendor's support statement and the entity's change management process before an agent is installed. Passive sensors inside the perimeter should be read-only and should not send active probes into control networks.
- Syslog from capable devices: Firewalls, switches, and some protection relays forward security and access events over syslog to a collector placed inside the same zone.
- Passive monitoring: A Zeek or Suricata sensor on a span port records protocol activity for review without injecting traffic.
- Agent exceptions: Install Wazuh agents only on hosts the vendor and the entity have approved, and document each exception.
- Collector placement: Keep the collector inside the ESP so raw OT logs are not replicated outside the perimeter.
- Time sources: Confirm that every device and collector uses a synchronized clock so events can be ordered during an investigation.
Confirm with your OT vendors and your CIP compliance lead which devices are in scope as BES Cyber Systems and which can accept a syslog or agent configuration before you design the sensor layout.
The DMZ is where the perimeter is enforced for remote access and for data crossing between zones. CIP-005-7 requires all Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication, so the session records, authentication events and access decisions created here are some of the most important logs the SIEM receives. Collectors in this zone can forward a summarized or filtered stream outward, which lets the SIEM give the security team visibility without moving full OT payloads beyond the perimeter. Treat the SIEM components in the DMZ as in scope for hardening and access control of their own.
- Intermediate System logs: Forward connection, authentication and session events from the Intermediate System to the collector.
- Firewall and proxy events: Collect allow and deny decisions at each perimeter boundary.
- One-way forwarding: Use a filtered, one-way forwarder or a dedicated relay so events leave the DMZ without granting inbound access to the control zone.
- Collector hardening: Restrict who can administer the DMZ collector and log those administrative actions.
- Encryption in transit: Protect every hop between the DMZ and the corporate SIEM with transport encryption.
Verify with your compliance team how the Intermediate System and the collector are documented in the ESP diagram and the access control evidence before go-live.
The corporate IT zone carries the identity provider, email, endpoints, and the cloud and SaaS tenants that staff use every day. Agents are generally allowed on these systems under standard endpoint management, which makes this the richest source of log data for the SIEM. Corporate logs are also the first place to see credential misuse that could lead to an attack on the OT side, such as a stolen account used to reach the Intermediate System. The SIEM in this zone should correlate identity events with network events, but it should not gain a path into the control zone that the ESP design does not allow.
- Identity events: Collect directory, single sign-on, and multi-factor authentication logs, since these show who requested access to remote paths.
- Endpoint agents: Deploy Wazuh agents to Windows and Linux workstations and servers under the standard software process.
- Vulnerability context: Use the software inventory from agents to correlate with vulnerability data, supporting the supply chain and patching work in CIP-013-2.
- Vendor access records: Capture logs from vendor support tools and ticketing systems that initiate remote sessions.
- Separation of duties: Keep SIEM administrators distinct from the operators who administer OT systems.
Confirm with your IT and CIP teams which corporate logs are used as evidence for the Intermediate System and which correlation rules are allowed to reference OT data.
Deployment limits in OT networks that change the design
Control zones impose limits that IT deployments rarely face: no internet path, devices that cannot host agents, maintenance windows that open only occasionally, and tight vendor access. Each limit is a design decision with a cost, so confirm how the chosen platform and each device class behave under it before the architecture is fixed.
No internet access in control zones
Collectors and the SIEM core inside a control zone may have no route to update servers or threat feeds. Plan for offline installation and updates from media that you verify and carry across the boundary. Wazuh documents an offline installation guide and an offline vulnerability repository in place of its online threat intelligence feed. Security Onion supports airgap installs, with rules and packages carried on ISO media and applied with its update tool. Ask the implementation partner how each release, rule set and vulnerability feed reaches the zone, who approves each transfer, and how the transfer is logged.
Agentless collection from legacy controllers
Many protection relays, programmable logic controllers and human-machine interfaces cannot run a monitoring agent, and the vendor may refuse to certify one. Collect their events through syslog forwarding from a gateway, historian or engineering workstation that can run an agent, and treat that intermediary as a dependency. Wazuh supports agentless monitoring through syslog collection, but the message formats of each device must be parsed and tested. Confirm with the device vendor which event types the controller emits, whether it can send syslog at all, and whether the vendor warranty depends on the forwarding method.
Fixed maintenance windows for changes
Operators often allow changes to monitoring systems only during planned outages, sometimes far apart. Each SIEM component update, rule change and agent upgrade must fit a window, and a missed window can leave a version out of date for months. Wazuh has shipped several 4.14 patch releases in 2026, so the update cadence can outpace a quarterly window. Agree in advance which updates are security fixes that may need an emergency window, and which can wait. Ask the partner to script the upgrade, test it on a non-production copy and state the rollback path.
Restricted vendor and remote access
Control system vendors and integrators often need remote sessions to troubleshoot, and those sessions must pass through an approved, monitored path. The SIEM team must reach the collectors and manager without opening a new route into the control network. Decide whether vendor staff may log into the SIEM, who grants access, and how sessions are recorded and reviewed. CIP-005-7 requires interactive remote access to pass through an Intermediate System with encryption and multi-factor authentication, so the SIEM administration path should follow the same pattern. Confirm the design with your compliance lead.
Hardware sizing for on-site collectors
Collectors and search nodes placed inside substations or plant sites run on hardware chosen for space, power and environmental tolerance, and they cannot always be scaled after installation. Security Onion supports only x86-64 processors, and its documented minimums differ by role, so sensors, search nodes and managers each need their own sizing. Security Onion also documents that if the manager goes down, search nodes stop indexing, so local buffering matters. Ask the partner to size each site for peak event rates, buffer depth during a WAN outage and the hardware lifecycle the site must support.
How a utility rolls out a self-hosted SIEM in phases
The sequence moves from an inventory of BES Cyber Systems and their zones to a SIEM that receives OT and IT logs under change control, with evidence handed over for the audit. Each phase closes with a written output that the utility, its compliance lead and the implementation partner can check before the next phase starts.
Scope the program and inventory BES Cyber Systems
The utility's compliance lead, OT engineering and the implementation partner agree on which registered entities, facilities and systems are in scope for the SIEM. The team uses the utility's existing CIP-002 categorization of BES Cyber Systems as high, medium or low impact to decide which assets must be monitored first and which logs carry the most weight. The phase closes with a signed scope statement and an inventory listing each system, its impact rating, owner and network zone. If the utility has not yet confirmed its categorization, that confirmation is the first item to resolve before any log source is connected.
Map log sources and network zones
Engineers document every candidate log source by zone: corporate IT, the DMZ, control centers and substation networks. For each source they record the protocol, whether an agent can be installed, whether the device can send syslog, and which path the events would take out of the zone. The output is a source register and a zone diagram that shows where the SIEM collectors and forwarders would sit relative to each Electronic Security Perimeter. Gaps, such as devices that only expose serial output or vendor-managed interfaces, are logged as open items for the next phase.
Design the architecture and review it against the ESP
The partner drafts the SIEM architecture, including where the manager, indexer, dashboard and collectors run, how syslog reaches the platform, and how alerts leave the zone. The design is reviewed by the utility's CIP compliance lead, the OT security owner and network engineering against the perimeter rules in CIP-005-7, including how any routable path to the SIEM is controlled and how interactive remote access to the platform is handled. The output is an approved architecture decision record and a list of firewall and data flow rules that network teams can implement. Changes to the design after this point go through the same review.
Pilot in a non-BES or lower-impact zone
Before any high or medium impact source is connected, the team deploys the SIEM stack and onboards a small set of sources from a zone where a failure has limited operational effect, such as corporate IT or a lower-impact environment. Engineers test ingest rates, parsing of the vendor formats they plan to use, alert routing to the SOC, and dashboard access for each role. The pilot closes with a written test report listing parsing failures, dropped events, performance observations and the fixes applied. The utility decides from that report whether the design is ready for OT sources.
Onboard OT sources under change approval
OT sources are added in small groups, each through a documented change request that names the device, the system owner, the change window and the rollback step. Field staff apply the syslog forwarding or agent configuration while the partner verifies that events arrive, are parsed and are time-stamped correctly. Passive or agentless collection is preferred where a device cannot run an agent, and every change to a device is recorded. The phase is complete for a group when its sources appear in the SIEM, the change ticket is closed, and the operations team confirms that the device behaves normally after the change.
Build detections and route alerts
Detection engineers write or adapt rules for the OT sources that matter most, including logins to engineering workstations, changes to control logic, unexpected remote access and events from security devices. They define which alerts reach the SOC, which go to the OT engineers and which are logged only, and they test each rule against recorded or simulated events. The output is a reviewed detection catalog, an alert routing matrix and a tuning log. Rules that could affect plant operations are reviewed by OT staff before they are enabled in production.
Hand over evidence and run operations
The partner prepares the evidence package that the utility will use during a compliance audit. It includes the BES Cyber System inventory, the zone and log source register, the architecture decision record, change records, retention settings, access reviews for the SIEM itself, and samples of alert reviews. The utility's operations team then takes over routine work such as patching, certificate renewal, backup checks and rule tuning, with clear support terms agreed in writing. The phase closes when the evidence package has been reviewed by compliance staff and an operations runbook has been accepted.
What auditors and regulators ask to see from the SIEM
This table maps the evidence items an assessor typically requests for a SIEM protecting BES Cyber Systems to the component that produces each item and what the entity must still document itself. Read it as a checklist: the platform generates raw records, but procedures, ownership and sign-off come from the entity.
| Evidence item | Produced by | What the entity must still document |
|---|---|---|
| Asset and log source inventory | Wazuh agent and syslog inventory, Security Onion sensor and asset data | Which assets are high, medium or low impact BES Cyber Systems, and the CIP-002 categorization behind each source |
| Alert and review records | Wazuh alert index and Security Onion Console case and detection history | Review cadence, reviewer roles and how alerts are escalated and closed under the entity's incident process |
| Retention configuration | Wazuh indexer and OpenSearch index lifecycle settings | The retention period chosen for each log class, the basis for it and who approves changes |
| Access control records for the SIEM itself | Wazuh and Security Onion authentication and audit logs, SSO logs if OIDC is configured | Account provisioning and removal procedure, role assignments and periodic access reviews |
| Vulnerability and patch records for SIEM components | Wazuh vulnerability detection from the software inventory and CTI or offline repository | Patch windows, testing before deployment and records of how findings were dispositioned |
| Remote access logs | Intermediate system and VPN logs forwarded by syslog, Wazuh collection of remote session events | Interactive Remote Access procedure, MFA enforcement evidence and vendor session approval steps |
| Supply chain documentation for SIEM software | Vendor release notes, license files and version records from the platform projects | Vendor risk assessment, integrity verification steps for installers and updates, and CIP-013 plan coverage |
| Network monitoring evidence inside the perimeter | Suricata and Zeek sensor output, Security Onion network records | Sensor placement rationale, Electronic Security Perimeter diagrams and how the CIP-015 expectation is planned for |
What energy and utility buyers ask before hiring a partner
What drives the cost of an open source SIEM project for a utility?
Scope drives cost more than the software, which is free to download under the licenses in use. The main drivers are the number of OT zones and electronic security perimeters you must cover, the count and type of log sources (historians, firewalls, relays, engineering workstations), how many sensors and search nodes you need, the hardware you must buy or reuse, and how many change windows the work requires. Ask any partner for a quote that itemizes discovery, architecture, source onboarding, detection content, testing, documentation and training, and states which items recur, such as support and upgrades. Labor is the main one-time cost, and licensing for an optional paid edition is the main recurring choice you may add.
Can our own staff build a SIEM for OT and IT networks?
Some utilities can, provided they have engineers who know Linux, network segmentation, syslog and their own control system protocols. Wazuh and Security Onion both document standalone and distributed installs, offline procedures and rule management, so the platform work is within reach of a capable IT team. The harder part is OT-specific: knowing which devices emit useful logs, which cannot run agents, how a monitoring tap affects a control network and which events matter to operators. A hybrid model is common, where internal staff own the platform and a partner handles architecture, source onboarding and detection tuning under a written scope.
What do operations and compliance staff need to provide?
Plan for operations staff to supply network diagrams, asset inventories, device lists and access to change control so that log sources can be onboarded without disrupting control systems. Compliance staff need to name the CIP standards in scope, map the controls to the log evidence they will show, and agree on retention periods and who reviews alerts. Security staff should own the detection rules and alert routing decisions. Ask the partner to name these roles in the statement of work, because gaps in OT knowledge or change approval are the most common causes of delay.
How long does a utility SIEM rollout take?
Duration depends on the number of zones, the number of sources to onboard, and how often your plants allow changes. No duration is fixed in this page's research, so treat any single number as a claim to verify. A reasonable quote separates a design phase, a lab or test-zone build, phased source onboarding aligned to outage and maintenance windows, and acceptance testing with evidence capture. Ask the partner to show the change windows they assumed and what happens when a window is missed. Written scope, with each phase tied to a named deliverable, is the best way to compare timelines between bidders.
Do we need Security Onion Pro for an OT monitoring deployment?
Not necessarily. The open source Security Onion release includes Suricata, Zeek, the Security Onion Console and detection management for NIDS, Sigma and YARA rules, and it supports airgapped installs. Security Onion Pro is a paid edition sold on 1 to 5 year terms that adds OIDC single sign-on to the Console, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, an API, external notifications, Manager of Managers and professional support. Decide based on whether your identity provider, encryption, FIPS and STIG requirements must be met by the product itself, and whether you want vendor support. Also note that Security Onion 2.4 reached end of life on October 1, 2026, and that Security Onion supports only Oracle Linux 9 for version 3.
Can we settle CIP applicability before the SIEM design starts?
Yes, and you should do it first, because the impact rating of each BES Cyber System decides which logging, monitoring and perimeter controls apply. CIP-002-5.1a sorts systems into high, medium and low impact using bright-line criteria, and CIP-005-7 requires routable-connected assets of high and medium impact to sit inside an Electronic Security Perimeter. Confirm your registration status with NERC or your Regional Entity, and have your compliance lead document the categorization. Consider also the standards that are now enforceable or approaching enforcement, including CIP-015-1 on internal network security monitoring, which is enforceable from 1 October 2028. A partner should review your categorization as an input, not decide it for you.
Does the SIEM need to sit inside the electronic security perimeter?
It depends on the impact rating and how the SIEM receives data, so confirm the design against CIP-005-7 before you build. Routable-connected high and medium impact assets must sit inside an Electronic Security Perimeter, and interactive remote access must pass through an Intermediate System with encryption and multi-factor authentication. Engineers often place a collector or sensor inside the perimeter and forward only required fields outward, but this changes what evidence you can retain and who can reach it. Ask the partner to show a data flow diagram that traces every log path across the perimeter boundary.
How do we get logs from OT devices that cannot run agents?
Use agentless collection with syslog, and where the device offers an API, periodic polling. Wazuh documents agentless monitoring of devices such as firewalls through syslog collection and periodic API probing, and Security Onion can ingest network metadata through passive sensors on mirrored traffic. Confirm the device's supported log formats, the transport it allows, and whether the sensor placement will affect the control network. Avoid active scanning of OT devices without vendor approval, and test every new source in a lab zone before it reaches production.
Questions to ask an implementation partner for OT monitoring
Start with OT experience and passive collection. Ask the partner which control system networks they have instrumented, whether they have worked inside a generation, transmission or distribution control environment, and how they confirm that collection is passive. A credible answer names the taps or SPAN ports used for Suricata and Zeek sensors, explains how sensors receive mirrored traffic without injecting packets into control links, and describes which Wazuh agents or syslog sources are allowed on each OT asset. Ask for the written change process that a control room operator must approve before any sensor or forwarder is installed or restarted.
Next, ask how the SIEM stays inside the electronic security perimeter for high and medium impact BES Cyber Systems. The partner should show a data flow diagram that marks which collectors cross the ESP boundary, where the manager and search nodes sit, and how Interactive Remote Access to the SIEM passes through an Intermediate System with multi-factor authentication, as CIP-005-7 requires. Ask them to explain how they handle the vendor-facing parts of the stack, and to confirm in writing how the CIP-013-2 supply chain plan covers the SIEM vendors, the open-source components and their update channels, including how software integrity is verified before each patch. Confirm which evidence they will hand over at each review cycle, which must occur at least every 15 calendar months.
Finally, ask how they handle offline updates and licensing. Because many utility networks cannot reach the internet, ask how rules, feeds and packages reach the SIEM by media, and how the partner records the hash and origin of each transfer. Ask for a licensing review of every component: Security Onion is under the Elastic License 2.0, a source-available license, while Wazuh is under GPL version 2. Ask whether the partner will document what the license permits for your deployment and whether a paid edition such as Security Onion Pro is needed for features like OIDC single sign-on. Close by asking what support covers after go-live, including who applies security patches within your maintenance windows and who tests them first.
How DeployOpen scopes and builds an OT-aware SIEM
DeployOpen works from a written scope, builds the SIEM inside the client's own networks, and hands over the hardening and records an assessor will ask for. Each card below covers one step of that path, from the first agreed boundary to ongoing support after go-live.
Fixed scope agreed in writing
Most engagements are fixed-scope, so the log sources, network zones, deliverables and timelines are agreed in writing before any build work starts. For energy and utilities, the scope should name which OT networks, control system segments and IT systems feed the SIEM, and which ones are out of bounds. Ask the partner to list every interface that crosses an Electronic Security Perimeter and who approves each change to it. DeployOpen does not publish a price list, so a quote follows from this written scope.
Build inside your own networks
DeployOpen implements self-hosted platforms in the client's own cloud accounts, data centers or air-gapped networks, so logs from control systems never leave the utility's infrastructure. For Wazuh, that includes the offline installation path and an offline vulnerability repository. For Security Onion, it includes the airgap ISO and the soup update tool. Confirm where the manager, indexer and search nodes will physically sit relative to the perimeter before hardware is ordered.
Agentless collection for OT devices
Many relays, protocol gateways and legacy controllers cannot run an endpoint agent, so their events must arrive through syslog or other forwarding that the SIEM receives from a collector placed in the network. Wazuh supports agentless monitoring of devices through syslog collection and periodic API probing. The design question is which devices can forward logs at all, how they are time-synchronized, and whether a receiver inside the control network is permitted under the segmentation plan.
Hardening for compliance assessments
DeployOpen hardens the SIEM itself, including access to the logs, the platform's own audit trail, backup and retention settings, and documentation of configuration. This produces the evidence set an assessor will sample, such as configuration baselines, change records and access reviews. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those decisions.
Security testing of the deployment
The SIEM is itself a high-value target because it holds network telemetry and alert logic for the control environment. DeployOpen runs security testing of applications, APIs, cloud and infrastructure, so the SIEM console, indexer APIs and collector hosts can be tested before go-live. Ask the partner which findings are tracked to closure, who signs off on accepted risk, and whether testing covers the segment boundaries where the SIEM receives data.
Retainers for ongoing support
Upgrades, patches and rule tuning do not stop at go-live. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so a maintenance plan has to fit the change control process of a utility. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Confirm in the scope which upgrades are included, how maintenance windows are arranged, and how outages in the SIEM are handled if the control network cannot receive alerts.
