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 IT security-operations integration and APIs 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. 4 pre-draft
NIST initiated revision work to align the OT guide with current frameworks, standards, practices, and threat conditions and asked whether dynamic resources should replace several appendices. Teams should monitor the revision without silently relabeling Rev. 3 mappings as Rev. 4 or presenting proposed structural changes as final requirements.
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.
CISA Secure by Demand for OT
The guide presents security considerations and questions for OT buyers addressing product configuration, logging, identity, updates, vulnerability handling, support, and secure-by-design behavior. It turns cybersecurity into a procurement and lifecycle evidence decision rather than an after-deployment add-on.
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.
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.
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.
Governance, authorities, and assurance
The system for identifying applicable authorities and commitments, assigning accountable roles, translating requirements into controls, collecting evidence, testing effectiveness, managing exceptions, reporting risk, and preserving change history.
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 IT security-operations integration and APIs 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.
NIST begins the SP 800-82 Rev. 4 pre-draft process — Programs should preserve Rev. 3 as current final guidance while tracking the revision through explicit development states.