What a security design package should contain

There is a simple, brutal test for a security design package. Hand it to two competent contractors who have never spoken to each other and ask them to price it. If they come back with different device counts, different pathway assumptions, or different ideas about who supplies the power supplies, the package is not finished.

Why the package exists

A design package is not a picture of the system. It is a set of contract documents that make three bids comparable and one installation predictable. Every item in it is there because somebody once argued about that item on a jobsite with a concrete pour waiting.

The gap between two bidders’ assumptions does not disappear when you award the work. It reappears as a change order, after the cheapest bidder is already on site and you have no leverage left. That is the economic argument for paying for design: the difference between comparable bids and incomparable ones is usually larger than the design fee.

The eleven deliverables

Not every project needs all eleven — a four-camera retail refresh needs three; a hospital wing needs all of them plus coordination drawings. Start from the list anyway: arguing about what to leave out beats discovering an omission during construction.

1. A basis-of-design narrative. What the system must accomplish, area by area, in language the owner recognises. The assumptions behind every number. What is explicitly out of scope. This is the document people skip and then wish they had when the objective is disputed a year later.
2. Device plans. Every camera, reader, contact, panel, intercom and sounder located on a floor plan, with a tag, a mounting height and an orientation. Tags tie the plan to the schedule and to the label in the field.
3. A camera field-of-view study. For each camera: the lens, the resulting coverage, and the pixel density achieved at the plane where the image has to be useful. This is the single deliverable that separates a design from a shopping list.
4. A riser or one-line diagram. How everything connects — head end to telecom room to device, which network each system rides on, where power comes from. A reviewer should be able to trace one camera from lens to recorded file on one sheet.
5. Schedules. A camera schedule, a device schedule, and a door-by-door matrix covering hardware, electronics, locking mode, alarms and access groups. The schedule, not the plan, states what the product actually is.
6. A network, PoE and power budget. Port counts, switch models, aggregate PoE draw against the switch’s real budget, line-voltage circuits and standby power. Add headroom; systems grow.
7. A bandwidth and storage model. Assumed bitrate per camera, recording mode, retention target, and the resulting usable terabytes — with the assumptions visible so they can be challenged and rerun.
8. Head-end and IDF layouts. Rack elevations showing what lives where, with rack units left over. A rack drawn exactly full on day one is a rack that will be a mess by year two.
9. Details. Drawn for the mounts, backboxes, penetrations and terminations that words did not settle. A detail sheet is cheap; a field improvisation on a rated wall is not.
10. A bill of material. Priced or unpriced, but complete — including the mounts, surge protection, patch cords, connectors and labelling stock that never make anyone’s first list.
11. Specification and acceptance test. The requirements the work must meet, and the written test that decides whether it is finished. Both written before anyone bids, not after somebody claims to be done.

How much is enough, and when

The most expensive mistake in buying design is paying construction-document prices for a budget number, or accepting a napkin sketch as a construction document. Three stages, three levels of finish:

• Concept. A narrative, a device count by area, a rough order-of-magnitude budget and the major infrastructure implications. Enough to decide whether to proceed and to reserve money. Days, not weeks.
• Design development. Plans, schedules, the camera study, the storage and power budgets. Enough to coordinate with the other trades, to confirm the infrastructure, and to get a credible budget from a contractor.
• Construction documents. Everything above, plus details, specification and acceptance test procedure. Enough to competitively bid and to build from without interpretation.

Be explicit about which one you are buying. “A design” means something different to every party in the conversation.

The three things left out

The same three omissions produce most of the money lost after award.

Pathway responsibility. Conduit, sleeves, backboxes, cable tray, core drilling and firestop are usually drawn by the electrical engineer, priced by the electrical contractor and assumed by the security contractor. The gap between those three assumptions is the single most expensive ambiguity in low-voltage work. Name the responsible party, in the scope of work, in a sentence.

Line-voltage power. Every panel, power supply, UPS and rack needs a circuit. Someone has to run it, someone has to label it, and somebody has to decide whether it is on the generator. A design that shows a power supply but not the circuit feeding it has moved a cost, not eliminated it.

Acceptance criteria. Without a written test, “complete” is whatever the contractor says it is on the day they want to invoice. With one, it is a signed document listing what was tested and what was observed. Write it during design, attach it to the bid, and witness it.

There is a fourth, and it is newer: credentials. Who holds the administrator passwords at handover, and are they unique per device? A system whose owner cannot log in is not really owned.

How to judge a package

Five questions will tell you more than reading every sheet:

1. Is there a stated objective per area, and does the camera study show it is met? If coverage is described only as “full coverage,” nothing has been designed.
2. Do the schedules and the plans agree? Pick five tags at random and trace them. Disagreements between plan and schedule are the most common defect in security documents.
3. Is the storage figure derived or asserted? A number with no assumptions attached is a guess wearing a spreadsheet.
4. Does the door matrix state fail-safe or fail-secure per opening, with a reason? This is the line that gets audited after an incident.
5. Is there a written acceptance test? If not, you are buying an opinion about completion.

One more thing worth knowing about the document in your hands: who benefits from its contents. A design produced by the contractor who intends to build it is not automatically bad — it is often very practical — but it is written by a party with an interest in the quantities. If you want documents you can competitively bid, get them from someone who is not bidding the labour.