How to Design Security Systems

What should the Design phase address?

High Level Design

The High Level Design should establish the overall architecture of the security solution and demonstrate how the defined requirements will be satisfied.

It should describe the principal systems, their operational relationships and the infrastructure required to support them, without yet defining every implementation detail.

Before progressing, the project should define:

• the overall system architecture;
• the principal security systems and subsystems;
• the boundaries and responsibilities of each system;
• the principal information, alarm and control flows;
• the key network, power and infrastructure dependencies;
• the required resilience, capacity and scalability principles.

The High Level Design should provide a coherent architectural response to the defined requirements and establish the basis for detailed engineering.

Low Level Design

The Low Level Design should translate the approved architecture into sufficient technical detail to support procurement, installation, configuration, commissioning and testing.

It should define how the solution will be implemented at system, subsystem and device level, while maintaining traceability to the requirements established during the Define phase.

Before progressing, the project should define:

• device types, quantities and locations;
• system connectivity and communication paths;
• network, addressing, bandwidth and storage requirements;
• power, resilience and uninterruptible power supply requirements;
• mounting, environmental and physical installation requirements;
• configuration, interface and performance parameters;
• the drawings, schematics and schedules required for implementation.

The level of detail should be proportionate to the project, but sufficient to minimise ambiguity during procurement and delivery.

Technology Selection

Technology should be selected on the basis of its ability to satisfy the defined requirements and support the approved system architecture.

Selection decisions should consider technical capability, interoperability, resilience, cyber security, compliance, lifecycle support, maintainability and total cost of ownership.

Before progressing, the project should establish:

• which technology categories are required;
• the minimum technical capabilities each technology must provide;
• whether proposed products and manufacturers satisfy the requirements;
• whether the selected technologies are interoperable and supportable;
• any capability limitations, dependencies or lifecycle risks;
• the technical and operational rationale for the selection.

Technology selection should be requirements-led and justified by operational need rather than familiarity, preference or unsupported manufacturer claims.

Integration Strategy

The Integration Strategy should define how individual security systems, business systems and supporting infrastructure will interact to deliver the required operational outcomes.

Each integration should have a clear operational purpose and should be designed with appropriate consideration for ownership, security, resilience and failure behaviour.

Before progressing, the project should define:

• which systems require integration;
• the operational purpose of each integration;
• the information, alarms, commands or credentials to be exchanged;
• the source, destination and ownership of each interface;
• authentication, permissions and cyber-security requirements;
• expected behaviour during communication or system failure;
• testing responsibilities, dependencies and limitations.

Integration should improve operational performance without creating unnecessary complexity, unmanaged dependencies or unacceptable single points of failure.

Engineering Documentation

The completed design should be communicated through coordinated engineering documentation that clearly defines the intended solution and supports its controlled implementation.

Documentation should be proportionate to project scale and complexity, but sufficiently detailed to reduce ambiguity, support technical review and provide an auditable record of the design.

Before progressing, the project should produce, where applicable:

• design reports and architecture diagrams;
• layouts, schematics and system drawings;
• device, equipment, network and power schedules;
• integration and interface specifications;
• bandwidth, storage, power and capacity calculations;
• installation, configuration and testing requirements;
• design assumptions, exclusions, dependencies and constraints;
• revision, review and approval records.

Engineering documentation should provide a clear and controlled definition of the design, enabling procurement and project delivery to proceed without relying on undocumented assumptions.

What should be in place before moving to the Assure phase?

The Design phase can be considered complete when there is a coordinated, justified and fully documented engineering design capable of supporting procurement, implementation, commissioning and subsequent operational assurance.

The project should be able to demonstrate that:

• the High Level Design has been completed and approved;
• the Low Level Design provides sufficient detail for implementation;
• selected technologies satisfy the defined requirements;
• system integrations have been fully defined;
• capacity, resilience and lifecycle considerations have been incorporated;
• engineering documentation is complete, coordinated and under revision control;
• design assumptions, dependencies and constraints have been recorded;
• the available information is sufficient to support procurement and project delivery.

The Security Design Process can progress once the engineering solution has been fully defined. Following procurement and implementation, the completed system proceeds into the Assure phase, where it is verified and validated against the defined requirements.

Typical evidence of completion

The exact documentation will vary according to project scale and complexity, but there should normally be evidence covering:

• High Level Design;
• Low Level Design;
• system architecture diagrams;
• equipment, device, network and power schedules;
• technology selection and design rationale;
• integration and interface specifications;
• engineering calculations, including bandwidth, storage, capacity and power;
• design assumptions, dependencies and constraints;
• design review and approval records;
• confirmation that the design is ready to support procurement and implementation.

The form of that evidence may vary according to the project and the methodology being followed. What matters is that the design is complete, coordinated, technically justified and capable of supporting successful implementation and subsequent assurance.

Transition to Procurement & Project Delivery

The Security Design Process concludes the design activities with a complete, coordinated engineering solution. At this point, responsibility typically transitions into procurement, project management, installation and commissioning, where the approved design is delivered by the appointed project team.

These delivery activities are essential to the successful implementation of the project but sit outside the Security Design Process itself. Once implementation has been completed, the installed solution returns to the methodology through the Assure phase, where it is verified and validated against the defined requirements, acceptance criteria and success measures.

Alignment with the RIBA Plan of Work & Security Overlay

The outputs of the Design phase typically align with RIBA Stage 2 – Concept Design, Stage 3 – Spatial Coordination and Stage 4 – Technical Design, where the agreed requirements are progressively developed into a coordinated and implementable engineering solution.

Within a security project, this generally represents the point at which:

• the High Level Design has established the overall security architecture;
• the Low Level Design has translated that architecture into implementable engineering detail;
• appropriate technologies have been selected and justified against the defined requirements;
• system integrations, interfaces and supporting infrastructure have been coordinated;
• the engineering documentation provides sufficient information to support procurement and implementation.

This phase aligns with the progressive development of the Security Strategy described by the RIBA Security Overlay. The strategy evolves from a high-level architectural response into a coordinated engineering design that integrates with the wider project and demonstrates how the defined security requirements will be achieved.

Procurement, project delivery, installation and commissioning occur outside the Security Design Process. Once implementation has been completed, the project enters the Assure phase, where the installed solution is verified and validated against the defined requirements, acceptance criteria and success measures.