How should OT teams govern shared telemetry for maintenance and security use?

How to set ownership when one telemetry stream serves both maintenance and security

Shared telemetry only works when teams treat it as a governed asset, not a free-for-all data feed. The key decision is who owns the signal definition, who can change filters or thresholds, who approves retention, and who must resolve ambiguity when maintenance goals and detection goals collide. That ownership should be explicit before the stream becomes operationally critical.

In practice, telemetry governance should distinguish between the data producer, the operational consumer, and the decision owner. Maintenance teams often need richer context, while security teams need stable evidence quality and defensible alerting. If both groups can tune the same stream without coordination, the result is usually weaker detection, noisier maintenance analysis, or both.

A useful governance model is to define the stream's purpose, its minimum viable fields, its retention period, and the approval path for any change that could affect evidentiary value. That prevents a common failure mode in OT environments, where one team suppresses or transforms data for convenience and another team later discovers the stream no longer supports incident review or root-cause analysis.

What can go wrong with shared telemetry ownership

Shared telemetry creates a real risk of conflicting optimisation. Maintenance may want higher fidelity, broader retention, and aggressive enrichment, while security may want consistency, integrity, and low-latency alerting. Without a single accountable owner, each team can optimise locally in ways that degrade the other team's outcomes and make the stream harder to trust.

There is also an evidence-quality risk. If parsing rules, sampling, time synchronisation, or retention settings change without joint review, the telemetry can become less useful as proof of what happened. That matters because the same stream may be used for preventative maintenance, intrusion detection, and post-incident reconstruction.

Failure mechanism: Multiple teams modify the same telemetry pipeline or interpretation rules without a shared change-control path, causing dropped context, inconsistent thresholds, or altered timestamps that weaken both maintenance analysis and security detection.

Impact: The organisation may miss early warning signs, investigate false positives, or lose confidence in telemetry as evidence during an incident or reliability event.

How to govern the stream without breaking either use case

Governance should start by separating decision rights from usage rights. Many teams can consume the telemetry, but only one function should own the final policy for retention, escalation, and tuning. That owner should also decide how conflicts are resolved when a maintenance request would reduce security visibility or when a security rule would suppress useful operational data.

Retention should be set to the longest period required by the highest-value use case, but only for the fields that are actually needed. If full-fidelity capture is too expensive or too sensitive to keep everywhere, define a tiered model: short-term high detail for operations, longer-term indexed records for investigations, and explicit exceptions for any data that must not be altered.

The operating model works best when it includes clear handoffs. Maintenance can own the signal's engineering context, while security owns alert logic and incident triage criteria. If the telemetry is ambiguous, the governance rule should say who has the tie-breaker, not ask the teams to improvise under pressure.

OT teams often benefit from a reference architecture and maturity baseline to keep that ownership model consistent across plants and business units. The OT Security Guide provides the broader OT context for segmentation, protocols, and monitoring, while the OT Security Maturity Model helps teams assess whether governance is repeatable or still dependent on local judgment. When telemetry is part of both detection and reliability work, that maturity gap is usually visible first in ownership ambiguity.

What practitioners should verify before trusting shared telemetry

What to verify: Confirm that the stream has a named owner, written retention rules, a change-approval path, and a documented escalation rule for ambiguous events. If any of those are informal, the telemetry is already fragile even if the dashboards look healthy.

What to measure: Track how often telemetry changes are made without cross-functional review, how long it takes to resolve ambiguous signals, and whether the same stream is accepted as valid by both operations and security during drills. Those indicators tell you whether the data is genuinely governed or merely shared.

Common mistake: Treating telemetry sharing as a tooling problem. The hard part is not collecting the data, it is deciding whose objective wins when the same signal supports two different decisions. If that rule is not written down, the team will discover it during a fault, an outage, or an investigation.

Practitioner takeaway: Shared telemetry should be governed like a production control surface, with one accountable owner and explicit rules for evidence quality, retention, and tuning so that maintenance convenience does not silently erode security value.

Risk and Threat Considerations

Shared telemetry becomes risky when its operational value creates pressure to simplify, filter, or repurpose it. That pressure can weaken detection coverage, reduce forensic confidence, or create blind spots if the same feed is tuned to satisfy competing teams.

Failure mechanism: Ad hoc changes to collection scope, parsing logic, alert thresholds, or retention settings introduce drift between what the telemetry shows and what the organisation thinks it is seeing.

Impact: Security teams may miss suspicious activity, maintenance teams may misread asset health, and incident responders may lack trustworthy records when they need to reconstruct events.

Practitioner Guidance

Ownership: Assign one function as the final policy owner for the shared stream, even if multiple teams consume it. That owner should be accountable for resolving conflicts in retention, enrichment, and alert tuning.

Decision rule: If a proposed change improves one use case by reducing fidelity for the other, treat it as a governed exception, not a routine tuning change. Require explicit approval when the change affects evidence quality or alert semantics.

What good looks like: The telemetry definition, retention window, and escalation path are documented, tested, and accepted by both operations and security, with no silent local overrides.

Practitioner takeaway: The best governance model is not perfect data sharing, it is controlled ambiguity, where both teams can use the stream confidently because one party owns the final call when priorities conflict.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?