How to Conduct Security Assurance

Phase 5 – Assure

Purpose of the phase

Conducting Security Assurance during this phase verifies and validates that the implemented security solution satisfies the requirements established during the earlier phases of the Security Design Process.

Its purpose is to confirm that the system has been installed, configured and commissioned correctly, and that it delivers the required operational outcomes under realistic conditions.

Assurance should extend beyond checking that equipment has been provided. It should determine whether the completed solution performs as intended, supports the required operational procedures and provides sufficient evidence for formal acceptance.

By the end of the phase, the project team should be able to explain:

  • whether the implemented solution conforms to the approved design;
  • whether individual systems and interfaces operate correctly;
  • whether the defined acceptance criteria have been satisfied;
  • whether users can operate the system effectively;
  • whether the required operational outcomes have been demonstrated.

The Assure phase provides the evidence required to determine whether the completed solution can be accepted and transferred into operational use.

Security Design Process Phase 5 – Assurance, showing Factory Acceptance Testing (FAT), Site Acceptance Testing (SAT), Operational Validation, User Acceptance, Handover Documentation and the resulting operational readiness.

What should the Assurance phase address?

Factory Acceptance Testing

Factory Acceptance Testing should verify that major systems, assemblies or configured components satisfy the agreed technical and functional requirements before they are delivered to site.

The extent of testing should be proportionate to the scale, complexity and consequence of failure. It may be undertaken at a manufacturer, integrator or specialist test facility where representative equipment and configurations can be examined under controlled conditions.

Factory Acceptance Testing should consider, where applicable:

  • equipment conformity and configuration;
  • system functions and workflows;
  • interface and integration behaviour;
  • performance under representative operating conditions;
  • resilience and recovery behaviour;
  • identified defects, limitations and corrective actions.

Factory Acceptance Testing does not replace site testing. Its purpose is to identify significant issues before installation and reduce the risk of discovering fundamental defects during commissioning.

Site Acceptance Testing

Site Acceptance Testing should verify that the security solution has been installed, configured and commissioned in accordance with the approved design and applicable requirements.

Testing should examine the completed system within its actual operating environment, including the infrastructure, interfaces and dependencies that could not be fully represented during factory testing.

Site Acceptance Testing should confirm, where applicable:

  • correct equipment installation and identification;
  • correct configuration and system operation;
  • compliance with drawings, schedules and specifications;
  • performance of networks, power supplies and supporting infrastructure;
  • operation of alarms, interfaces and integrations;
  • resilience, failover and recovery behaviour;
  • resolution or formal recording of defects and deviations.

Testing should be based on predefined procedures and acceptance criteria rather than informal observation or installer confirmation.

Operational Validation

Operational Validation should determine whether the completed solution delivers the security outcomes for which it was designed.

This requires the system to be assessed through representative operational scenarios rather than solely through individual technical tests. Validation should consider the interaction between technology, people, procedures and the operating environment.

Operational Validation should examine:

  • whether defined operational scenarios can be completed successfully;
  • whether alarms and events are detected, presented and managed correctly;
  • whether users receive the information required to make effective decisions;
  • whether response procedures can be carried out within the required time;
  • whether the system performs under realistic environmental and operational conditions;
  • whether the defined success measures have been achieved.

A system may pass technical testing and still fail operationally. Operational Validation provides the evidence that the complete solution is fit for its intended purpose.

User Acceptance

User Acceptance should confirm that authorised stakeholders are satisfied that the completed solution supports the agreed operational requirements and can be used effectively.

Acceptance should involve the people responsible for operating, managing, supporting and governing the system. It should not be treated solely as a technical approval by the project delivery team.

Before acceptance, the project should confirm:

  • users have received appropriate training;
  • roles, responsibilities and escalation routes are understood;
  • operating procedures are complete and usable;
  • known defects and limitations have been recorded;
  • outstanding actions have agreed owners and completion dates;
  • authorised stakeholders have formally accepted or conditionally accepted the solution.

User Acceptance should be supported by evidence and should clearly distinguish between full acceptance, conditional acceptance and rejection.

Handover Documentation

Handover Documentation should provide the information required to operate, maintain, support and manage the completed security solution throughout its lifecycle.

The final documentation should reflect the system as implemented rather than simply reproducing the original design. Any approved changes made during procurement, installation or commissioning should be incorporated into the final record.

Handover information may include:

  • as-installed drawings and schematics;
  • final equipment and device schedules;
  • configuration and commissioning records;
  • test results, defect records and acceptance certificates;
  • operating procedures and user instructions;
  • maintenance, support and warranty information;
  • licence, software and firmware information;
  • training records and competency requirements;
  • asset information required for lifecycle management.

Handover is complete when the operating organisation has both the system and the information required to manage it effectively.

What should be in place before moving to Lifecycle Management?

The Assure phase can be considered complete when the implemented solution has been verified against the approved design, validated against the operational requirements and formally accepted by the appropriate stakeholders.

The project should be able to demonstrate that:

  • required factory and site acceptance testing has been completed;
  • the installed solution conforms to the approved design or agreed variations;
  • the defined acceptance criteria have been satisfied;
  • operational performance has been validated through representative scenarios;
  • users have been trained and are able to operate the solution;
  • defects, limitations and outstanding actions have been resolved or formally accepted;
  • complete and accurate handover information has been provided;
  • responsibility for the system has transferred to the operating organisation.

The phase is complete when there is sufficient evidence to demonstrate that the security solution is technically compliant, operationally effective and ready to be managed throughout its operational life.

Typical evidence of completion

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

  • approved Factory Acceptance Test procedures and results;
  • approved Site Acceptance Test procedures and results;
  • commissioning and configuration records;
  • operational validation scenarios and results;
  • completed requirements and acceptance traceability records;
  • defect, deviation and corrective-action records;
  • user training and competency records;
  • formal user acceptance or conditional acceptance;
  • complete as-installed and handover documentation;
  • confirmation that the solution is ready to enter Lifecycle Management.

The form of that evidence may vary. What matters is that acceptance is based on documented verification and operational validation rather than the assumption that a completed installation will automatically satisfy the original requirements.

Assurance Alignment with the RIBA Plan of Work & Security Overlay

The activities within the Assure phase typically align with the later part of RIBA Stage 5 – Manufacturing and Construction and with RIBA Stage 6 – Handover, where the completed solution is commissioned, tested, demonstrated and transferred into operational use.

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

  • installed systems are verified against the approved design;
  • technical and functional testing is completed;
  • operational performance is validated against the Security Requirements;
  • users are trained and operational procedures are confirmed;
  • as-installed information and handover records are completed;
  • the completed security solution is formally accepted.

This phase aligns with the verification, commissioning, handover and post-completion activities described within the RIBA Security Overlay. It provides assurance that the security measures developed through the Security Strategy and detailed design have been implemented correctly and achieve the required operational outcomes.

Once the completed solution has been accepted, responsibility transfers into Lifecycle Management, aligning with RIBA Stage 7 – Use. Performance should then be reviewed throughout the life of the system so that changes in threats, operations, technology and organisational requirements can be identified and managed.