How to Assess Risk, Threat and Vulnerability

What should the Assess phase address?

Threat Assessment

The project should identify the credible threats relevant to the organisation, its assets and its operating environment.

Threats may arise from criminal activity, terrorism, insider actions, accidental events, environmental conditions or other circumstances capable of affecting the organisation’s operations.

Threat assessments should be proportionate to the nature, location and function of the organisation. They should focus on realistic and credible scenarios rather than highly improbable events, ensuring that subsequent security decisions are based on evidence rather than assumption.

Before progressing, there should be a clear understanding of:

• the threats relevant to the project;
• the likelihood of those threats occurring;
• the circumstances in which they may arise;
• any emerging or changing threat considerations.

The assessment should focus on credible threats rather than hypothetical or highly improbable scenarios.

Vulnerability Assessment

The project should understand how existing conditions, processes or security arrangements may allow identified threats to affect the organisation.

Vulnerabilities may exist within physical environments, operational procedures, technology, people or organisational processes. They may arise from weaknesses in design, inadequate procedures, insufficient resources or the absence of appropriate security controls.

Identifying vulnerabilities provides an understanding of where the organisation is exposed and why particular threats may present a credible risk.

Before progressing, the project should understand:

• where vulnerabilities exist;
• why those vulnerabilities are significant;
• how they may be exploited;
• any existing measures intended to reduce their likelihood or impact.

A vulnerability should always be considered in relation to a credible threat.

Risk Assessment

The identified threats and vulnerabilities should be assessed to determine the level of risk they present to the organisation.

Risk assessment considers the likelihood of a threat occurring, the vulnerabilities that may enable it, the effectiveness of existing security controls and the potential consequences should the threat be realised.

Consequences may include harm to people, disruption to operations, financial loss, regulatory action, reputational damage or the loss of critical services. The assessment should consider the impact on the organisation as a whole rather than focusing solely on individual assets.

Before progressing, the project should understand:

• the likelihood of identified threats occurring;
• the potential consequences should those threats be realised;
• the effectiveness of existing security controls;
• the resulting level of risk.

Risk assessment provides the justification for developing operational, functional and performance requirements during the Define phase.

Risk Prioritisation

The identified risks should be prioritised to determine where security intervention will provide the greatest operational benefit.

Not all risks require the same level of treatment. Some may present an unacceptable level of risk requiring immediate mitigation, whilst others may be considered tolerable or acceptable depending upon the organisation’s objectives, risk appetite and existing controls.

Risk prioritisation enables organisations to focus resources where they will have the greatest impact on reducing operational risk, rather than attempting to address every identified issue equally.

Before progressing, the project should establish:

• which risks are considered significant;
• which risks are unacceptable and require treatment;
• the relative priority of each identified risk;
• the rationale used to determine those priorities.

Risk prioritisation should reflect operational impact and organisational objectives rather than simply the number of identified risks.

Residual Risk

Not every risk can or should be eliminated. Following the assessment of threats, vulnerabilities and existing controls, there will often remain a level of residual risk that must be understood and, where appropriate, accepted by the organisation.

Residual risk represents the level of risk remaining after existing security measures, operational procedures and organisational controls have been taken into account. Understanding this remaining risk helps determine whether further security measures are justified or whether the residual risk is acceptable.

Before progressing, the project should understand:

• which risks remain after existing controls have been considered;
• whether those residual risks are acceptable to the organisation;
• where additional risk treatment is justified;
• which risks will require ongoing management throughout the system lifecycle.

Residual risk should be identified explicitly rather than assumed to have been eliminated. The Define phase can then focus on developing security requirements that are proportionate to the remaining level of operational risk.

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

The Assess phase can be considered complete when there is a sufficiently robust understanding of the risks affecting the organisation and the reasons why security intervention may be required.

The project should be able to demonstrate that:

• credible threats have been identified;
• vulnerabilities affecting critical assets are understood;
• identified risks have been assessed using a consistent methodology;
• risks have been prioritised according to their operational significance;
• residual risks have been identified and understood;
• the need for further risk treatment has been justified;
• the available information is sufficient to develop measurable security requirements during the Define phase.

The phase is complete when the project understands which risks require treatment and why, rather than how those risks will ultimately be addressed.

Typical evidence of completion

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

• documented threat assessment;
• documented vulnerability assessment;
• completed risk assessment;
• prioritised risks requiring treatment;
• identified residual risks;
• a documented security risk assessment; NPSA provides guidance;
• confirmation that the project is ready to proceed to the Define phase.

The form of that evidence may vary according to the project and the methodology being followed. What matters is that the conclusions are explicit, proportionate and capable of supporting defensible security requirements, performance criteria and subsequent design decisions.

Alignment with the RIBA Plan of Work & Security Overlay

The outputs of the Assess phase typically align with RIBA Stage 1 – Preparation and Briefing, where the project-specific risks must be sufficiently understood to inform the Project Brief and the client’s security requirements.

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

• credible threats relevant to the site, organisation and proposed use have been identified;
• vulnerabilities affecting critical assets and operations have been considered;
• the potential likelihood and consequences of identified threats have been evaluated;
• existing controls and residual weaknesses have been reviewed;
• risks requiring elimination, mitigation, management or acceptance have been identified and prioritised.

This phase aligns directly with the Security Risk Assessment described by the Security Overlay. The Overlay states that the Security Risk Assessment should be undertaken during RIBA Stages 0 and/or 1, should identify risk ownership and should provide the basis from which the Security Requirements are developed. It also remains a live document requiring review throughout the project lifecycle.

The resulting risk conclusions are translated into defined and measurable security requirements during the subsequent Define phase, aligning with the completion of the RIBA Stage 1 Project Brief.