Unlock the full potential of Wavestore v6.50 -view our launch presentation today and explore the latest innovations in video management.
Integrators sell features. Consultants specify constraints. Most of the distance between a good product and a specified product sits in that gap.
When a consultant writes a security system specification, they are not buying a system. They are writing a document that will outlive their engagement, survive several procurement cycles, and be enforced by people who never met them. That changes what they optimise for entirely — and it explains why a demo that lands beautifully in the room still fails to reach the spec.
In short
A security system specification is the document that defines the performance, standards and equipment a facility's physical security must meet. In construction it sits under Division 28, Electronic Safety and Security. That MasterFormat division was reshaped in 2016: access control was unbundled from intrusion detection, and intelligent devices such as electronic locks moved across from Division 08.
Most are written as a basis of design. A named reference product comes first, followed by a description of the performance it delivers, which any alternative must match.
That last part is where things get interesting.
Most integrators assume the spec is a rigorous piece of engineering, produced by an expert with full visibility. The reality is less tidy.
Security specifications are frequently copied from older specifications. Some are borrowed wholesale from unrelated sectors — documents written for retail or warehousing, pressed into service for environments with entirely different resilience and compliance demands.
Accountability is usually split. Construction divisions scope the perimeter, the fencing, the gates and bollards. The security department handles access control, video and alarms. Neither party owns the whole picture. And the finished document can run past seventy pages of exact model and part numbers, while visibility into what subcontractors actually order downstream stays limited.
None of that is a criticism of consultants. It is a description of the pressure they work under, and it explains every criterion that follows. Someone carrying that much ambiguity is not looking for the most exciting product on the market. They are looking for the choice that is hardest to get wrong.
This is the reframe that changes how you pitch.
A spec is not a purchase decision. It is a durable constraint, and the person writing it is managing professional exposure across a horizon most integrators never think about. The building will change hands. The security manager will move on. The estate will grow, and someone will extend this document to cover sites that do not exist yet.
So the question behind every criterion below is the same: what happens in year seven, when nobody involved in writing this is still in the room?
The pressure is sharpest where the regulatory floor is rising fastest. Data centres are the clearest current example. But the mechanics of a security system specification are the same in a school, a hospital or a port.
Openness is not a technical preference to a consultant. It is a procurement requirement.
A consultant who names a closed system has bound their client to one supplier's roadmap, one supplier's pricing, and one supplier's end-of-life calendar. That is professional exposure, and it has a number attached.
A 2026 comparative analysis of proprietary and open-platform VMS architectures describes vendor lock-in as the primary strategic risk of proprietary systems. Migration means cameras and software replaced simultaneously — effectively a full forklift. The analysis advises budgeting 70 to 90 per cent of the original install cost as a hidden exit cost.
Read that back as a consultant would. Naming the wrong platform can cost a client nearly as much to leave as it cost to install.
This is why ONVIF conformance, hardware-agnostic architecture and documented, open APIs are not differentiators in a security system specification. They are the entry ticket.
An open-platform VMS runs on standard server hardware and connects to cameras from any manufacturer. That keeps the client's options open, which is precisely what the consultant is being paid to protect.
The same logic applies to existing infrastructure. Take a migration path that reuses installed panels — Mercury controllers being the common case. That is a specifiable property, because it lowers the cost of the very change the consultant is trying to make possible.
Here is the part most integrators get wrong, because the industry has quietly agreed to pretend otherwise.
The substitution mechanism everyone relies on — naming a product, then adding "or equal" so competitors can be considered — does not work nearly as well as its ubiquity suggests.
John Gelder, writing for NBS, argues the terms are inherently meaningless and even misleading. A contractor cannot reasonably judge which of a branded product's properties are critical and which are merely incidental. Adding "or approved equal" makes matters worse rather than better: disagreement over what counts as equivalent can bring a job to a halt.
The alternative he sets out is deemed-to-comply. A mandatory generic description comes first, stating the performance the system must deliver. A specific product is then named as predetermined to meet that description. The requirement lives in the capability, not the brand.
For an integrator, this is the single most actionable insight in the whole process. Bring the generic performance description, not the brochure.
Hand a consultant clause language that defines what the system must do, and you are compliant on capability rather than on name. Native event handling across video and access control. Licensing that scales per device. Decision logic that survives a WAN outage. That makes you specifiable everywhere — including on documents you never see.
Physical security is an IT procurement now. Consultants reach for certification because it is auditable and defensible in a way that a vendor's assurances are not.
ISO 27001, 27017 and 27018, SOC 2, and a documented NDAA-compliant supply chain all do the same job in a security system specification. They turn a claim into something a consultant can point at when challenged.
Operating system matters here too, and it is specifiable. A hardened Linux platform with no Windows attack surface is a stated architectural property, not a marketing line. So is encryption strength.
The practical point is blunt. Consultants cannot specify what a vendor will not put in a document. If your platform's security posture lives only in a sales conversation, it cannot be written down — and if it cannot be written down, it cannot be required.
Consultants specify for the bad day. Integrators demo for the good one.
The failure-mode questions separate a serious submission from a glossy one. What happens when the WAN drops? When the head end is unreachable? When a site is isolated and a decision still has to be made at the door? Full decision logic retained at the edge, independent of the network core, is a specifiable resilience property.
There is evidence behind this beyond intuition. Research testing control-room operators on cyber-induced physical events found that when operators were restricted to traditional separate monitoring systems, just three of thirty-six detected the events. Given a single consolidated interface, all thirty-six did — most within around thirty seconds, regardless of experience level.
That is a specification-grade finding. Architecture that reduces the number of decisions a person must make under pressure is not a comfort feature. It is a resilience requirement, and it belongs in the performance description.
Licensing models get read carefully, because they are where year-three budget shocks originate.
Per-operator licensing scales with a client's growth. That is difficult to forecast at specification stage, and easy to resent later.
Seat-free licensing is charged per camera and per reader, with no cost attached to adding operators. That is a commercial property, and it can be written into a security system specification as a requirement.
Consultants who have been through one seat-cost renegotiation tend to specify against it permanently. There is more to say on how the full cost of a physical security estate accumulates, and we will come back to it in a follow-up piece.
The fastest change an integrator can make is translating the pitch into the language of constraint.
Every phrase in the right-hand column can be dropped into a document. Not one phrase in the left-hand column can.
Being specifiable is not about being the most impressive option. It is about being the option a consultant can defend in year seven, to people who were not in the room when the choice was made.
Which means the integrator's real job is not to satisfy a rigorous security system specification. It is to be the person who helps make an imperfect one defensible.
What is the first thing that gets a product struck off your specifications?
By Sebastian Marghella, Marketing Manager · Published 26 August 2026 · Last updated 26 August 2026
Solutions for a world we can't yet see. Discover v6.50 features helping people and businesses.
