5 Questions to Ask Before Your Security System Is Specified

Before a security system is specified, proposed, or contracted, leadership should be able to answer five questions. Most organizations find they can’t — not because the questions are difficult, but because the people they’ve been talking to have had an interest in keeping them unasked.

1. What operational outcomes are we actually protecting?

2. Most security specifications are built around features and coverage, not outcomes. A multifamily property specifies cameras at entrances and in common areas because that’s what the vendor proposed, not because someone independently identified what incidents the property was actually managing and what coverage would address them. A healthcare facility adds access control to clinical areas because that’s what other facilities have done, not because anyone mapped out which staff movements and visitor patterns actually created exposure. Knowing what you’re protecting against changes what gets specified.

2. Who is making the recommendation, and what is their financial interest in the outcome?

3. A vendor recommending a system they also install has a financial stake in the specification. That’s not automatically disqualifying, but it means the recommendation needs to be evaluated against an independent baseline. If no independent baseline exists, the organization is evaluating a proposal against the vendor’s framing of its own problem.

3. What does this environment actually require — not what can be installed in it?

4. Installation capacity and operational suitability are different things. A hotel can install any number of camera configurations — but which configuration actually serves the operational pattern of its specific property, its staff coverage, its guest flow, its service areas? A school can install access control at every entry point — but which deployment actually reflects how the campus is used and how staff manages it? The answer to what can be installed is always wider than the answer to what the environment actually requires.

4. What are the long-term operational implications of this direction?

5. Security decisions made during planning become embedded in the organization’s operational reality for years. Vendor lock-in. Maintenance dependencies. System limitations that only become apparent after the warranty expires. For property managers overseeing multiple buildings, for government facilities planning infrastructure upgrades, for commercial real estate operators planning long-term, these implications compound. They deserve scrutiny before commitment, not after.

5. Have the assumptions behind this recommendation been independently challenged?

6. Every security proposal rests on assumptions — about the environment, the risk profile, the operational requirements, and what constitutes an acceptable outcome. Those assumptions are usually made by the vendor and rarely examined by anyone without a stake in the answer. Having them independently reviewed before a commitment is made is the difference between a decision made with full visibility and one made on the vendor’s terms.