Treat OT telemetry as a separate governed stream, not as ordinary log volume. Enrich and classify it before ingestion, then route high-value signals to the SIEM and lower-value data to cheaper storage. That preserves detection value while avoiding runaway ingestion costs and gives analysts the context they need at the moment of triage.
Why OT Telemetry Should Not Enter the SIEM as a Single Undifferentiated Feed
ot telemetry behaves differently from conventional IT logs because it is often high-volume, repetitive, and operationally time-sensitive. If SOC teams treat it as one more log source, the SIEM quickly becomes a cost centre and a triage bottleneck. Governance starts with deciding which signals deserve real-time attention and which signals still matter, but only after enrichment and classification.
That separation matters because not every telemetry point has the same detection value. Some events support immediate threat detection, such as changes to controller state, remote access, or unusual command patterns. Others are better retained for later analysis, compliance, or engineering review. A governed pipeline keeps those categories distinct instead of forcing the SIEM to absorb everything equally.
Well-governed OT telemetry also needs context before ingestion. Asset identity, zone, protocol, process state, and normal operating pattern change how a SOC should interpret an event. Without that enrichment, the SIEM sees volume, but analysts do not see meaning, which increases false positives and hides the few events that actually matter.
How to Separate Detection Value From Storage Value
The practical model is to classify telemetry at the edge or in a staging layer, then route only the highest-value records into the SIEM. High-value signals are those that support detection, correlation, alerting, or incident response in near real time. Lower-value telemetry still has operational value, but it belongs in cheaper storage, historian systems, or searchable archives rather than the main detection plane.
This is less about suppressing data and more about governing its destination. SOC teams should define retention and routing rules by use case: incident detection, forensic reconstruction, engineering troubleshooting, and long-term trending do not all require the same pipeline. NIST SP 800-82 Rev 3, OT Security Guide is useful here because it frames OT environments around architecture and operational constraints that should shape telemetry handling.
A sensible split usually places protocol-aware parsing, enrichment, and prioritisation before ingestion, not after the SIEM has already paid the cost. That design makes it easier to preserve fidelity for important events while reducing noise from routine polling, repetitive status messages, and machine-generated chatter. In practice, the SIEM becomes the place for security decision-making, not the place where raw OT data is first normalised.
What a SOC Should Control Before the SIEM Sees the Data
The control point is the pipeline, not the dashboard. SOC and OT teams should be able to answer three questions for every telemetry class: why is it collected, what does it prove, and where should it live. If those answers are unclear, the stream will either be over-ingested into the SIEM or underused in storage where no one can find it during an investigation.
That governance model is strongest when the SOC keeps ownership of detection requirements while OT engineering defines process-critical context. The result is a tiered telemetry policy that preserves safety and visibility without forcing all data into the same analysis lane. CISA Industrial Control Systems resources are a strong reference point for the operational context, and ENISA Threat Landscape helps teams keep the telemetry strategy aligned to current threat pressure on critical infrastructure.
The main failure mode is assuming the SIEM should be the universal landing zone because it is the security platform of record. That assumption usually creates higher licensing cost, slower searches, and poorer analyst focus without improving detection. A better governed design makes the SIEM selective by design and uses the rest of the telemetry estate to support investigation depth and retention economics.
Risk and Threat Considerations
Overloading the SIEM with raw OT telemetry creates both operational and security risk. Operationally, high ingestion cost can cause teams to reduce coverage, shorten retention, or suppress sources that are actually useful. Security-wise, analysts lose signal quality, which makes it easier for abnormal commands, remote access abuse, or lateral movement into OT segments to blend into background noise.
Failure mechanism: Excessive raw telemetry inflates volume and weakens triage by burying high-value events beneath repetitive or low-context records, especially when enrichment is deferred until after ingestion.
Impact: The SOC may miss early indicators of compromise, spend more on storage and parsing than on detection, and lose the ability to investigate OT events at the speed required for industrial environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | OT telemetry routing depends on defining what must be logged and reviewed. |
| AU-6 — Audit Review, Analysis, and Reporting | The question is about filtering telemetry so analysts review high-value events. | |
| SI-4 — System Monitoring | OT telemetry governance is a monitoring design problem that must preserve detection value. | |
| Recommendation — Define which OT events must reach the SIEM and which may remain in lower-cost storage. Prioritise review paths that surface only operationally meaningful OT alerts. Tune monitoring pipelines so OT signals are monitored without flooding the SIEM. | ||
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | The subject is about continuously monitoring OT without creating log overload. |
| GV.RM-01 — Risk Management Strategy | Telemetry governance balances detection value, cost, and operational risk. | |
| Recommendation — Implement continuous monitoring with source-specific routing and enrichment rules. Set telemetry retention and routing policy based on risk and detection value. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | OT telemetry must be curated, retained, and reviewed as logs and events. |
| Recommendation — Centralise only high-value logs and retain the rest in fit-for-purpose storage. | ||
Practitioner Guidance
What to prioritise: classify telemetry by detection value before ingestion, and treat protocol detail, process state, and asset context as gating factors for SIEM routing. If a record does not help an analyst decide or correlate, it probably does not belong in the primary detection stream.
What to verify: confirm that every telemetry source has an explicit destination rule, retention owner, and review cadence. The test is whether the SOC can explain why a given feed is in the SIEM instead of storage, and what decision it supports there.
Practitioner takeaway: The goal is not to send less OT data everywhere, but to ensure the SIEM receives only the telemetry that improves detection and response while the rest remains searchable, governed, and affordable.
Related resources from NHI Mgmt Group
- How should security teams govern autonomous SOC actions without losing control?
- How should SOC teams use correlated endpoint and network telemetry without creating false confidence?
- How should security teams monitor AI coding agents without overwhelming the SOC?
- How should security teams govern AI SOC triage without losing accountability?