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:

• Description of the system: What does the system do and why do you consider it in-scope for GovAssure
• Breakdown of components: What are the significant components that the system is comprised of?
• Dependencies: What are the dependencies that enable delivery of the system and service?
• System boundary: What is the perimeter of the system’s scope and what are the interdependencies on other systems/suppliers/other government organisations?

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:

• A boundary that is too large: Could inherit risk from systems that are outside the administrative and technical control of an information system owner-the individual or organisation with overall responsibility for the system. This can also result in a disproportionate level of effort and resources when it comes to Stage 3: CAF self-assessment and may effect the organisation’s ability to deliver their assessment.
• A boundary that is too narrow: Could exclude system resources from the level of protection required by the system owner. Boundaries can sometimes be too narrowly scoped and exclude critical dependencies – systems that could have a direct effect on the confidentiality, integrity and availability of the essential system being reviewed.

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

• Individual service and system owners should be part of this process.
• You will need their input when identifying and agreeing the system boundary,
• They will need to contribute to documenting the approach that you have taken to identifying the system boundary.

Identifying Dependencies

• It is important that you set out the full details of the network and information system, including the dependencies that are fundamental to the system, on system bearers and service providers.
• You may carve out elements and decide to carry out assurance on those elements during a later round of GovAssure.

Drawing the line

• You will need to take a realistic approach to identifying the boundary for a system that will be included in-scope for GovAssure.
• It may not be possible to assure a connected network and information system in its entirety and it is important that you draw the line somewhere.
• Being clear on what you are declaring out of scope will help with this.

What is Out of Scope?

• If you are declaring something out of scope, you need to declare exactly what is out of scope and what the justification is for excluding it from scope.
• If you are removing something from a system’s scope, you must consider what effect this might have on the assessment of any other critical system in scope for GovAssure. For example, shared functions that underpin several systems

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):

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:

• Management of security threats from the element outside the boundary
• Parties responsible for risk beyond the boundary
• Production, pre-production, test and development environments which may present opportunities to malicious actors

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