Define the operating boundary
A useful definition names the triggering event, required inputs, governing source, accountable owner, decision or action, exception path, evidence retained, and downstream handoff. Buyers should adapt those elements to their own population, jurisdictions, policies, systems, and control model before writing requirements.
The most important distinction is between a label and an operational capability. A provider may document anomaly and behavioral detection while depending on customer-supplied policy, licensed content, third-party data, integration partners, manual review, or services. The demonstration should expose those dependencies rather than hiding them behind a completed interface.
What a demonstration should prove
- Begin with representative source records and a named policy, standard, or controlled rule.
- Show the normal path, an ambiguous case, missing data, an exception, an override, and a material source change.
- Identify who can change rules, who can approve or reject, and how accountability is preserved.
- Trace every output back to inputs, versions, timestamps, user actions, and governing evidence.
- Export the resulting record and reconcile it with downstream systems and retained obligations.
Authority and operating context
NIST SP 800-82 Rev. 3
NIST describes OT topologies, threats, vulnerabilities, safeguards, and risk-management considerations while recognizing performance, reliability, and safety requirements. Provider and architecture claims can be tested against a mature OT-specific control context without pretending the guide certifies a product or environment.
CISA primary OT mitigations
The fact sheet calls attention to exposed OT connectivity and prioritizes defensive actions for owners and operators facing intentional targeting. It makes internet exposure, remote access, credentials, segmentation, inventory, logging, and recovery evidence central to product and architecture review.
NERC CIP-015-1
CIP-015-1 requires documented processes for internal network security monitoring of specified high- and medium-impact BES cyber-system environments, including data feeds, anomaly detection, evaluation, and evidence. The standard creates a concrete evidence and operating-model test for network telemetry, anomaly detection, evaluation, escalation, and record retention.
TSA Pipeline-2021-02F
The directive continued performance-based requirements covering cyber risk assessment, plans, architecture, access, monitoring, incident response, testing, and related evidence for notified pipeline operators. The expired date and separate proposed-rule path make status verification essential; vendor pages must not present an old mapping as proof of current obligation or compliance.
C2M2 v2.1
C2M2 supports evaluation and improvement of cybersecurity capabilities across domains such as risk, assets, access, threat and vulnerability, situational awareness, response, continuity, third parties, workforce, architecture, and program management. It helps frame program and operating-capability evidence without turning a product feature into a maturity score.
ATT&CK for ICS
ATT&CK for ICS organizes publicly reported adversary tactics, techniques, software, groups, mitigations, and data sources relevant to industrial control systems. Detection claims can name exact techniques, data sources, evidence, and coverage limits instead of claiming complete ATT&CK coverage.
Operating domains
Detection, investigation, and operational response
The connected defensive workflow from approved telemetry and detection content through triage, process-context review, evidence preservation, incident decision, engineering coordination, containment, recovery, and learning.
Evidence and comparison limits
Official provider documentation can establish product positioning. Provider confirmation can clarify package or availability. Independent observation requires a disclosed scenario, environment, date, inputs, and reproducible result. None of those sources alone establishes buyer-specific legal, clinical, regulatory, quality, or operational fitness.
Buyer questions
- What exact outcome and evidence should anomaly and behavioral detection produce?
- Which source, version, and customer facts govern the workflow?
- Which decisions remain human and who is accountable for them?
- What is native, configured, integrated, service-delivered, or planned?
- How does a changed source affect open and historical records?
Recent changes
Dragos releases its 2026 OT cybersecurity year in review — Readers should preserve sample, denominator, method, source population, and provider-research classification beside every reported finding.
FERC approves NERC CIP-015-1 — Covered entities need evidence for selected network feeds, anomaly detection, evaluation, escalation, and implementation within controlling scope and dates.
CISA partners publish primary mitigations for OT — Owners should review exposure, access, architecture, credentials, monitoring, and recovery through site-authorized engineering processes.