Security design basis: turn risk findings into buildable requirements

Protective projects lose clarity when teams jump directly from a vulnerability list to product selection. The security design basis closes that gap. It records the assumptions, performance objectives and interfaces that architects, engineers, security professionals, contractors and operators must carry through the project.

The document does not replace discipline-specific design. It creates a controlled reference so that a wall, door, camera, access-control sequence and response plan are evaluated against the same owner decision.

Define scope before selecting countermeasures

State the protected people, functions, spaces and equipment; the credible undesirable events; the required operating condition after an event; and the boundaries of the project. Separate mandatory criteria from owner-selected objectives and recommendations. If threat information is sensitive, establish a controlled appendix rather than deleting the rationale from the project record.

Also record exclusions. A team should know whether the project addresses unauthorized entry, ballistic attack, vehicle impact, blast, civil disturbance, theft, sabotage or only a subset. Unwritten assumptions invite substitutions that may meet a different threat than the owner intended.

Write performance objectives in testable language

“Harden the building” is not a design requirement. A useful objective identifies the assembly, threat or action, expected outcome and evidence. For example, an owner may require a selected room boundary to resist a defined test threat as a complete assembly, including doors and penetrations, with documentation traceable to the proposed configuration.

Where a performance standard is not available, define analysis methods, design loads, acceptance criteria and responsible professionals. Avoid turning preliminary dimensions, material strengths or product names into unexamined proxies for actual performance.

Control interfaces and priorities

Assign evidence to project stages

Identify what must be submitted at concept, design, procurement, installation and closeout. Typical evidence includes risk decisions, drawings, calculations, test reports, product listings, deviation logs, inspection records, photographs, commissioning results and training records.

Make acceptance responsibility explicit. The manufacturer may provide product evidence, the engineer may review structural integration, the contractor may document installation and the owner may accept residual risk. Those roles should not be blended into a vague statement that the “vendor will certify” the finished project.

Keep the basis alive after occupancy

The security design basis should become an operations reference. New penetrations, tenant changes, equipment replacements and revised access patterns can invalidate an assumption even when the protective product remains intact. Change-control procedures should require review against the original performance objective and record the approved disposition.

Frequently asked questions

Who should own the security design basis?

The facility owner should control it, with qualified security, design, engineering, life-safety and operations input appropriate to the project.

Is a threat assessment the same document?

No. The assessment supports the rationale; the design basis translates the selected risk response into coordinated project requirements and evidence.

Can a product specification serve as the design basis?

Usually not. A product specification rarely addresses the complete assembly, adjacent systems, operations, response and acceptance responsibilities.