Defining your context

Understanding the context of what you are delivering makes sure the capability’s security requirements align with the wider mission.

Context informs the risk appetite, which helps make sure you have the right amount of control.

For example, the same technology deployed in two different contexts could attract different levels and types of risk.

To start with, you should:
  • check the business case
  • understand the concept behind your operation
  • check user requirement documents for the capability you’re working on
All these should already include any considerations for security.

NIST Risk Management Framework prepare step

The prepare step outlines tasks to help define your context. These tasks involve understanding critical information about the capability so proportionate security can be delivered on a through-life basis.

More information on the prepare step and supporting tasks is available in the NIST Risk Management Framework. You should determine which tasks are applicable and offer value to your programme. The complexity and maturity of the capability should guide you on this.

Tasks P8-P18 are advised for all capabilities (between pages 36-45 of the NIST RMF).

Also, tasks P1-P7 are recommended for capabilities of larger size and complexity (between pages 28-35 of the NIST RMF)

Benefits

The benefits of defining your context are:
  • implement the right level of security based on your context
  • avoids retrofitting security later, at cost
  • understand and accept risk with greater clarity
  • better evaluate the consequences of potential risks
  • effectively plan and budget with a right-sized security approach

Outcomes

The outcomes of defining your context:
  • key information to understand your capability, which helps Secure by Design activities, like defining your risk appetite and risk assessments
  • early understanding of security controls that you could use

Responsibility

Everyone involved with the capability contributes to defining the context.

However, the following roles are responsible:
  • capability sponsors
  • Senior Responsible Owner (SRO) or suitable equivalent
All these should already include considerations for security.

When to define your context

Initially, at pre-concept or concept stage, prior to any procurement and reviewed over the capability lifecycle. You should begin defining your context as soon as possible to avoid delays.

Context should be defined before a capability requests funding, budget authorisation, or approval through a formal review board, such as, but not limited to:
Read more about on embedding security within investment approvals