Operational Requirements | How to define security project objectives

What should the Understand phase address?

Business Objectives

Business objectives describe the organisational outcomes that the project is intended to support. These may relate to the protection of people or assets, regulatory compliance, operational resilience, incident investigation, service improvement, loss reduction or another defined organisational need.

The objectives should provide a clear justification for the project and a basis against which its eventual success can be considered.

Before progressing, there should be a shared understanding of:

• the business need driving the project;
• the outcomes the organisation expects;
• the problems the project is intended to address;
• any priorities or dependencies affecting those outcomes.

A request for new or replacement technology is not, by itself, a business objective.

Stakeholder Engagement

Relevant stakeholders may include operational teams, security personnel, estates, facilities, information technology, health and safety, legal or compliance functions, senior management and other parties with an interest in the outcome.

Before progressing, the project should have:

• identified the relevant stakeholder groups;
• established who owns the project and its outcomes;
• captured the principal operational and organisational requirements;
• identified any significant differences in stakeholder expectations;
• established who has authority to approve key decisions.

Stakeholder engagement is complete when the project has appropriate organisational representation to proceed with confidence.

Operational Requirements

Operational requirements describe what the organisation needs to be able to achieve in practice. They should reflect how the security system will support people, processes and decision-making during normal operations, incidents and other relevant circumstances.

Before progressing, the project should have a sufficiently clear account of:

• the activities the security solution must support;
• the situations in which it will be used;
• the people or functions that will use, manage or depend on the solution;
• the decisions or responses it must enable;
• the consequences if the required outcome is not achieved.

At this stage, requirements should remain operational rather than technical. Statements such as camera quantity, resolution, storage duration or reader type belong to later design decisions unless they are imposed constraints.

Critical Assets

Assets should not be limited to physical items. An organisation may also depend upon critical processes, data, reputation, service availability, specialist knowledge or the continued operation of particular facilities.

Before progressing, the project should understand:

• which assets are relevant to the project;
• why those assets are important;
• where they are located or how they are accessed;
• who is responsible for them;
• what operational consequences could arise from their loss, damage, compromise or disruption.

This stage identifies what matters to the organisation. The threats and vulnerabilities affecting those assets are considered during the Assess phase.

Constraints and Assumptions

The project conditions that may limit or influence later decisions should be recognised and recorded.

Constraints may arise from budget, programme, existing infrastructure, building conditions, legislation, organisational policy, information technology requirements, contractual commitments or the need to maintain ongoing operations.

Assumptions are matters currently treated as true where complete information or formal confirmation is not yet available.

Before progressing:

• material constraints should be known;
• unresolved assumptions should be visible;
• the potential effect of incorrect assumptions should be understood;
• matters requiring later confirmation should be recorded;
• constraints should not be mistaken for operational requirements.

An undocumented assumption can become an unrecognised design risk later in the project.

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

The Understand phase can be considered complete when there is a sufficiently clear and agreed foundation for risk assessment.

The project should be able to demonstrate that:

• the business need and intended outcomes are understood;
• relevant stakeholders have been identified and appropriately represented;
• the principal operational requirements have been defined;
• critical assets and operational dependencies are understood;
• the project scope and boundaries are sufficiently clear;
• significant constraints and assumptions have been recorded;
• major information gaps have either been resolved or formally acknowledged;
• no premature technology decision is being used as a substitute for an operational requirement;
• the available information is sufficient to identify and evaluate relevant risks.

It is complete when the project team has enough reliable, agreed information to assess what could prevent the organisation from achieving the required operational outcomes.

Typical evidence of completion

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

• agreed business objectives;
• defined project scope;
• identified stakeholders and decision owners;
• documented operational requirements;
• identified critical assets and dependencies;
• recorded constraints;
• recorded assumptions and outstanding information;
• confirmation that the project is ready to proceed to risk assessment.

The form of that evidence may vary. What matters is that the conclusions are explicit, reviewable and capable of supporting later design decisions.

This Phase may be used in conjunction with Part 1 and Part 2 of NPSA Protective Security Risk Management Guidance

Alignment with the RIBA Plan of Work & Security Overlay

The outputs of the Understand phase typically align with RIBA Stage 0 – Strategic Definition and the early part of RIBA Stage 1 – Preparation and Briefing, where the client’s objectives, project context and initial requirements are established before the Project Brief is approved.

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

• the business need and intended operational outcomes have been established;
• the project scope and boundaries have been defined;
• critical assets and operational dependencies have been identified;
• relevant stakeholders, decision owners and security responsibilities have been recognised;
• significant constraints, assumptions and information gaps have been recorded.

The Security Overlay requires security to be considered from the outset and identifies the need for an initial, high-level Security Risk Assessment during RIBA Stage 0 where different sites, buildings or strategic options are being considered. The outputs of the Understand phase provide the organisational and operational context needed for that assessment.

A more detailed evaluation of threats, vulnerabilities and security risks is undertaken during the subsequent Assess phase, aligning primarily with the Security Risk Assessment activities undertaken during RIBA Stage 1