Skip to main content

This is a new service – your feedback will help us to improve it.

  1. Guidance
  2. GovAssure
  3. Stage 2
  4. Part B

Stage 2 - Part B: Prioritise systems and agree which systems to include in scope for GovAssure

Where to document the output of this step: GovAssure Scoping Document (Stage 2 – Part A: Identifying and defining the critical systems).

Organisations should prioritise and select a practical number of critical systems that are representative of the organisation and its business to take through the GovAssure process. This could include a mix of operational and support systems, such as corporate and estate systems, and analytic or transactional systems. The candidate list of essential services and the critical systems that underpin them should be agreed with system owners and wider business areas within the organisation. The final selection of in-scope systems will be agreed with GSG before progressing to the self-assessment stage of GovAssure as part of the overall agreement of the GovAssure Scoping Document. Where an organisation has Government CNI, this should be prioritised in Year 1 of GovAssure.

It is important to also consider what is practical and pragmatic for an organisation to complete based on the available resource within the organisation. Selecting a manageable number of systems will be important to being able to deliver a good quality self-assessment (Stage 3).

Documenting the results in the GovAssure Scoping Document

You should document the result in the GovAssure Scoping Document, Stage 2 - Part A: Identifying and Defining the critical systems using the in scope column.

Note: You will only need to progress on to the following steps for the systems deemed in scope.

Developing the view of the in-scope systems and understanding system boundaries and dependencies

Where to document the output of this step: GovAssure Scoping Document (Stage 2 – Part B: Identifying the in-scope critical systems for GovAssure).

After identification of the systems in-scope, it is important to the scoping exercise to fully understand each of the systems that you have selected as in-scope. You will need to identify what the system relies upon to run successfully – so you fully identify the components and the dependencies on which the system relies. This should include a clearly defined boundary for each in-scope system. You should consider the following to fully document the system:

For the critical systems prioritised as in-scope for GovAssure, it is important to include individuals with a detailed understanding of those systems in any wider touch points and scoping conversations. Their knowledge will be required to understand the architecture and onward connectivity of the systems, including boundaries and dependencies as well as the flow of data to and from the systems.

At this point it is also important to start to familiarise these individuals with the NCSC Cyber Assessment Framework (CAF) to understand the areas where their input is most likely to be required as part of Stage 3 (CAF self-assessment).

This process (including drawing the system boundary) will be documented as part of the GovAssure Scoping Document and will need to be signed off by the CISO or relevant senior risk owner.

System boundaries

To support the identification of a system’s boundary, it is necessary to understand where data is stored, where data flows, any systems the primary system relies on, as well as any critical dependencies to support the scope development and ensuring that assurance activities are targeted on the systems and third parties that delivery of the essential service relies upon. You may already have data flow diagrams that help to establish this view.

It is important to establish and document all applications and systems that store or process the system's data. A pragmatic approach should be taken to system boundaries to prevent trying to provide assurance of the entire infrastructure. In some cases, a large boundary can encompass the entire operating environment, including directory services, DNS, email, and other shared services.

It is important to consider that:

NIST SP800-37, Revision 2 (Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy) provides guidance on identifying systems and their boundaries.

Considerations in identifying system boundaries

The following considerations are central to correctly and accurately scoping systems:

Engagement with system owners

Identifying Dependencies

Drawing the line

What is Out of Scope?

Including diagrams for in-scope systems

To support the scoping exercise, we recommend utilising available systems’ architecture diagrams to help provide a diagrammatic representation of the in-scope systems. This will support subsequent discussions with GSG as to the appropriateness of the boundary around significant elements of the critical system.

Consideration should be given to the following: - The critical components and/or assets (grouped if needed) - The security boundary around the critical components and/or assets (system boundary) - Other non-critical, components and assets which are within the system boundary, and related interconnectivity (direct wired and wireless) - Entry and exit points within the system boundary

The diagram below provides an example of how organisations could present a system and its boundary (illustrated by the dotted red line):

Figure 1. Classifying the systems in scope vs out of scope

A diagram depicting the network architecture of a fictional organisation with a red dotted line to represent the boundary of the network that is in scope for GovAssure with the other services listed being out of scope. The diagram shows the internet at the centre of the image together with Microsoft, Okta and the cloud. Around the internet are individual boxes which contain Software as a service (SaaS) services, Legacy Data Centres, Department Sites, Home and Mobile locations, Other Government Sites, Any Locations, Microsoft Cloud Services, Amazon Web Services (AWS) and Private Data hosted Centre Services. There are further boxes which sit at the top of the diagram with Users, remote works, Arms Length Bodies, External Private, third party sector, and Public. At the very bottom of the diagram is a box with Systems support centre and another with System Cyber Security Stack. There is a dotted line drawn around the internet, AWS and one of the SaaS services called ConDeco.

Dotted red line shows systems which are inside the boundary and are in-scope

This process (including drawing the system boundary) will be documented as part of the GovAssure Scoping Document and will include the necessary approvals that need to be obtained.

It will not be practical to document every connected element to an environment. In which case, the following information should be listed instead:

Organisation's IT environment and IT supplier relationships

System boundaries and system dependencies will also relate to functions outside of the IT department. To gather this information, it is important to outline relationships with main IT suppliers and where engagement is likely to be needed from IT suppliers.

Early engagement in the process will be required to explain that they may need to assist in providing supporting evidence for the CAF self-assessment. Other stakeholders that could support you with this are System Owners, Commercial, and Information Assurance teams who should have documentation detailing the services being provided to your organisation by third parties, and the information assurance arrangements underpinning them.

Contracting conditions under assured services may limit the detail available to be shared by IT providers, so it is recommended you engage Commercial colleagues on what is possible.

Documenting the results in the GovAssure Scoping Document

You should document the result in the GovAssure Scoping Document, Stage 2 - Part B: Identifying the in-scope critical systems for GovAssure

Back to Stage 2