Purpose
The Specify Technology phase of ICAT turns risk findings into a written specification a vendor can bid on and a project can verify. A good specification states what the system must do and how you will judge success. It does not just list parts. This article gives a template, a section checklist, and the reasoning behind a performance-based approach.
Why Performance Beats a Product List
A copy-paste product list ties the project to one vendor’s catalog. It hides the real goal, makes fair comparison impossible, and dates quickly as products change. A performance-based specification describes the outcome, such as readable facial detail at a stated distance and light level, and lets qualified vendors propose how to meet it. You get competition, current equipment, and a clear test for acceptance.
This site takes a merit-based, independent stance. Specify on requirements and quality. Name products only as a basis of design, meaning an example that sets the expected standard, with wording that allows equivalents. That keeps the specification honest and keeps you free of any single supplier.
Specification Structure
Objectives
State the security objective in plain language, traced to the risk register. Example. Detect and record any person entering the rear yard after hours and alert the monitoring station within a set time.
Performance Requirements
Describe measurable behavior, not brand names. Cover detection, identification, recording retention, response time, coverage areas, environmental tolerance, and integration with existing systems. Every requirement should be testable.
Standards References
Cite the standards that apply so quality is defined, not assumed. For networked systems and access control where security data is involved, reference ISO/IEC 27001 for information-security management and NIST SP 800-53 for control selection. For any life-safety interface, such as fire alarm integration or door release, reference the applicable NFPA codes and the local authority having jurisdiction. In Canada, confirm provincial and municipal code requirements early, since they govern.
Acceptance Criteria
Define how each requirement will be proven at commissioning. Tie each criterion to a performance requirement so there is no ambiguity at handover. Example. Camera output is verified by recording a test subject at the stated distance under minimum rated light, reviewed and signed off against the readability standard.
Basis of Design
Where a product example helps bidders gauge expected quality, name it here and mark it clearly as a basis of design open to equivalents. Set out how equivalence will be judged so substitutions are evaluated on merit.
Section Checklist
- Project scope and reference to the risk findings
- Objectives stated in plain language
- Measurable performance requirements per system
- Standards and code references, including local authority having jurisdiction
- Integration and interoperability requirements
- Cybersecurity requirements for networked devices
- Power, environmental, and physical mounting conditions
- Documentation and as-built deliverables
- Warranty, support, and training expectations
- Acceptance and commissioning criteria
- Basis of design with an equivalence clause
Writing for Fair Bids
Keep the language product-agnostic. Avoid requirements that only one product can meet unless a genuine operational need demands it, and if so, record that need. Group requirements so a bidder can respond point by point. Ask for compliance statements against each requirement, which makes evaluation a comparison of facts rather than marketing.
Handing Off to Delivery
The finished specification feeds the Deliver and Verify phase. Its acceptance criteria become the commissioning checklist, and its standards references become the quality baseline. A specification written this way protects the owner, gives honest vendors a fair shot, and leaves a record you can defend.
References
Last updated 2026-06-14.