How to Define Measurable Security Performance Criteria

What should the Define phase address?

Performance Requirements

The required level of security performance should be defined for each operational requirement identified during the previous phases.

Performance requirements describe the operational outcomes the security solution must achieve rather than the technology used to achieve them. They establish measurable criteria that can later be verified during testing, commissioning and operational acceptance.

Before progressing, the project should define:

• the required operational outcomes;
• the level of performance expected;
• where that performance is required;
• when the requirement applies;
• any operational conditions affecting performance.

Performance requirements should remain independent of manufacturers, products and technical implementations.

Functional Requirements

Functional requirements define the capabilities the completed security solution must provide in order to support the required operational outcomes.

These requirements describe what the system must do, regardless of how those functions are ultimately implemented. They provide the basis for selecting appropriate technologies during the Design phase.

Before progressing, the project should define:

• the functions the system must provide;
• how users will interact with the system;
• any required integrations with other systems;
• reporting, recording and information management requirements;
• operational workflows the system must support.

Functional requirements should describe operational capability rather than specifying products or technical solutions.

Non-functional Requirements

Non-functional requirements define the qualities and constraints that the completed security solution must satisfy throughout its operational lifecycle.

Whilst functional requirements describe what the system must do, non-functional requirements describe how well it must perform, how resilient it must be and the conditions under which it must continue to operate.

Before progressing, the project should define:

• availability and resilience requirements;
• cyber security and information security requirements;
• reliability, maintainability and scalability requirements;
• environmental, regulatory and compliance constraints;
• lifecycle, support and operational maintenance expectations.

These requirements ensure the completed solution remains suitable, secure and supportable throughout its operational life.

Acceptance Criteria

Acceptance criteria define the objective evidence that will demonstrate whether the completed security solution satisfies the defined requirements.

Acceptance planning should begin before the system is designed, ensuring that every requirement can ultimately be verified through inspection, testing, demonstration or documented evidence.

Before progressing, the project should define:

• how compliance will be verified;
• what evidence will be required;
• who will determine compliance;
• any witness testing or formal acceptance procedures;
• the criteria for successful completion.

Acceptance criteria should demonstrate operational performance rather than simply confirming that equipment has been installed.

Success Measures

Success measures define how the organisation will determine whether the completed security solution has achieved its intended operational outcomes.

These measures provide a means of evaluating the effectiveness of the solution after implementation, ensuring that the project delivers meaningful operational benefit rather than simply meeting technical specifications.

Before progressing, the project should define:

• the operational outcomes that indicate success;
• how those outcomes will be measured;
• who will evaluate project success;
• when success will be assessed;
• any ongoing performance indicators or review measures.

Clearly defined success measures provide the foundation for validation during the Assure phase and ongoing performance review throughout the system lifecycle.

Typical evidence of completion

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

• documented Performance Requirements;
• documented Functional Requirements;
• documented Non-functional Requirements;
• defined Acceptance Criteria;
• agreed Success Measures;
• applicable standards, regulatory and compliance requirements;
• confirmation that the project is ready to proceed to the Design phase.

The form of that evidence may vary according to the project and the methodology being followed. What matters is that the requirements are explicit, measurable, technology-neutral and capable of supporting defensible system design.

Alignment with the RIBA Plan of Work & Security Overlay

The outputs of the Define phase typically align with the latter part of RIBA Stage 1 – Preparation and Briefing, where the Project Brief is developed, coordinated and approved before concept design begins.

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

• identified risks have been translated into measurable security requirements;
• performance, functional and non-functional requirements have been established;
• acceptance criteria and success measures have been agreed;
• applicable standards, regulatory obligations and operational constraints have been incorporated;
• the design team has been provided with sufficient direction to develop an appropriate security architecture.

This phase aligns closely with the Security Requirements described by the Security Overlay. These project-specific requirements are derived from the Security Risk Assessment and incorporated into the Project Brief or issued as a supporting standalone document. The Overlay also recommends that operational considerations associated with the future Security Plan are identified during this stage.

The technical response to these requirements is developed during the subsequent Design phase, aligning primarily with RIBA Stage 2 – Concept Design and the production of the Security Strategy.