Requirements and procurement

Write requirements that can be tested against a product and version. Specify the required profiles, operations, failure behaviour and acceptance evidence.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.

Verification and testing

On this page

Overview#

A claim such as supports ONVIF, OSDP, MQTT, HTTPS, BACnet, REST, or encryption isn't an acceptance requirement. Specify the exact profile/version, mandatory and optional features, secure mode, identity model, failure behaviour, scale, evidence, and supported product/firmware combination.

Requirement anatomy#

Write each requirement with:

actor and operational purpose;
exact standard/profile/API and edition;
required roles, services, operations and optional features;
transport, secure mode, authentication and authorisation;
topology, network direction, discovery and port behaviour;
capacity, latency, retry, failover and offline expectations;
malformed/unauthorised input behaviour;
logs, metrics, timestamps and audit correlation;
compatibility and migration constraints;
acceptance method and evidence;
lifecycle, security advisory, support and update obligation.

Conformance versus interoperability#

Standards conformance is version and implementation specific. Require an official conformance listing where a programme exists, tied to exact model and firmware/software, then validate the deployment's selected feature combination. A vendor statement that a product supports a standard isn't equivalent to certification or successful system interoperability.

Security questions#

Are unique device identities and credentials supported at scale?
Can plaintext and legacy fallback be disabled?
How are certificates/keys enrolled, renewed, revoked, backed up and destroyed?
Which roles can view media, export evidence, administer users, update firmware or actuate outputs?
Which outbound cloud/support connections exist and can they be disabled or constrained?
Are update artefacts signed, and what is the supported rollback/recovery path?
What are the disclosure channel, support period and end of support notice?
Is an SBOM or equivalent component disclosure available and versioned?
How are logs exported securely, and which events identify security degradation?

Acceptance evidence#

Require architecture and data flow diagrams, port/flow matrix, protocol/API references, conformance listing, hardening guide, security advisories, update/recovery documentation, role matrix, certificate workflow, event schema, capacity assumptions, backup/restore procedure, known limitations and exact test environment. Environment specific acceptance remains necessary; documentation review can't establish runtime behaviour.

Sources#

NIST 800 161, NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices, final update dated 1 November 2024, accessed 25 August 2026.
NIST SSDF, NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, final supplier and secure development vocabulary; SP 800-218 Rev. 1 / SSDF Version 1.2 remains an Initial Public Draft, accessed 25 August 2026.