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 asset criticality and operational context 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.
NIST CSF 2.0
CSF 2.0 organizes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover and can be applied alongside OT-specific guidance. The Govern function and outcome language help connect OT defense evidence to enterprise accountability without replacing the system-specific detail in SP 800-82 or ISA/IEC 62443.
ISA/IEC 62443-2-1:2024
Part 2-1 defines security-program requirements for asset owners across governance, risk, implementation, maintenance, and continuous improvement of IACS security. It creates an owner-specific program lens that product capability lists cannot satisfy by themselves.
ISA/IEC 62443-3-2
Part 3-2 addresses system-level risk assessment and the use of zones, conduits, and target security levels in IACS design. It provides the central architecture language for comparing discovery, segmentation modeling, enforcement, remote access, and controlled-transfer products.
CISA CPGs
CISA publishes a prioritized set of cybersecurity practices intended to reduce common and consequential risks across critical-infrastructure sectors. The CPGs give buyers a risk-reduction lens for access, segmentation, backups, inventory, monitoring, incident response, and supplier decisions.
Joint OT asset inventory guidance
The joint guide describes a regularly updated OT asset inventory and taxonomy tied to function and criticality as a foundation for risk, vulnerability, architecture, and incident-response work. It raises the evaluation bar from device counts to governed identity, taxonomy, criticality, ownership, dependency, lifecycle, and use across operating functions.
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.
Operating domains
Asset inventory, context, and lifecycle
The maintained operating record for each OT asset's identity, role, location, owner, criticality, communications, dependencies, versions, configuration, support state, exposure, and recovery relevance.
Network architecture, segmentation, and conduits
The design and maintained evidence for security zones, conduits, trust boundaries, routable paths, industrial DMZs, enforcement points, fail states, and allowed communication supporting physical operations.
Vulnerability, exposure, and remediation governance
The operating process that connects a device, product, component, vulnerability, exploit context, exposure path, process consequence, compensating control, vendor guidance, maintenance window, decision, and retained evidence.
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.
Safety, reliability, and engineering coordination
The decision boundary connecting cyber defense with process safety, functional safety, reliability, operations, maintenance, engineering change, and physical consequence.
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 asset criticality and operational context 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
ServiceNow completes the Armis acquisition — Buyers need current evidence for product identity, packaging, workflow, data governance, integrations, and organizational responsibility after the ownership change.
CISA releases eleven ICS advisories — Asset, vulnerability, engineering, maintenance, and evidence records must connect before an advisory can become a safe, authorized decision.
CISA partners release OT asset inventory guidance — Product evaluation should test collection coverage, identity, context, criticality, confidence, ownership, lifecycle, and safe use rather than device counts.