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 offline and air-gapped environment support 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 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.
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.
Operating domains
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.
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.
Remote access, identity, and third-party control
The operating domain governing who can reach which industrial resource, for which approved task, through which path, with which credential, privilege, device, time window, supervision, file flow, emergency process, and retained session evidence.
Endpoint, removable media, and controlled transfer
The controls and evidence for protecting constrained industrial endpoints and moving software, files, updates, logs, and operational data across security boundaries.
Product security and software supply chain
The lifecycle evidence connecting industrial product design, components, firmware, provenance, secure development, vulnerabilities, updates, support, suppliers, integrators, customers, and end-of-life responsibilities.
Resilience, recovery, and cyber-informed engineering
The integration of cybersecurity with physical mission, safety, reliability, design, spares, configuration baselines, backups, manual capability, tested restoration, and recovery decision authority.
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 offline and air-gapped environment support 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?