Complete your architecture mapping workbook

Guidance on how to complete architecture scoping and mapping for the CAF for local government.

Once you have set your scope, your council will have prioritised a critical system.

Use the architecture mapping workbook to capture:

a breakdown of components
dependencies
boundaries

This helps you identify the information your council should include in your architecture maps.

You will need to create system architecture diagrams for the critical systems you are self-assessing.

If you have previously completed an architecture mapping exercise, review it and make sure it is still accurate before starting your critical systems self-assessment.

The workbook will help you get your scope right and decide what is practical and achievable for your council to assess. If your scope is too broad, it may be hard for you to accurately complete the assessment. Work with your team to make architecture scoping decisions.

1. Gather existing documentation

A good starting point is to gather existing documentation your council has on your chosen critical system and its supporting infrastructure.

Try to gather any documentation that identifies the critical system and how it is deployed within your council from a network, data or application perspective. This could include:

existing architecture diagrams
high level designs
data flow diagrams
technical documents from suppliers or service providers, including cloud or SaaS providers
network architecture diagrams
low level designs

The more information you can gather, the easier architecture mapping may be. Make sure you only use relevant and updated diagrams and information. Filter out any out-of-date information.

2. Breakdown the components of your critical system

This is where you document all components that are vital to the operation of your critical systems.

Any components listed here should be independent and dedicated to the critical system – not shared with other systems.

Example: NE Council has a shared database server. They only list the database instance in the breakdown of components. The database server will be listed as a dependency.

3. Document the dependencies for each critical system

Dependencies are systems within your council that support the critical system and other functions. These systems are not dedicated to the critical systems.

They could be:

on-premise systems that are critical to the council – for example, firewalls, VMware, active directory, print servers, other council applications that need to integrate with the critical system
third-party systems – for example Microsoft Entra ID (formerly Azure Active Directory), commercial (third-party) hosted servers/services/integrations, cloud-hosted proxy or next-generation firewall, and cloud-hosted backups

4. Set the boundaries for each critical system

A boundary is the break-off point for data flow and end-user access to your critical system. These boundaries determine what is in scope for your self-assessment.

Boundaries can be defined as where:

critical system data flows into and out of the organisation
critical system data rests outside of the organisation
external users access the critical system
council users access external systems

Boundaries for external partners and entities could be where data is:

accessed by other organisations – for example, by VPN or portal access
sent to other parties – for example, external bodies that use customer details to process documents or letters
stored by an external backup provider
transferred to commercial (third-parties) for presentation or processing, for example sFTP data to external systems

Boundaries for internal systems could include:

integration with other financial, CRM or HR systems for processing data
UAT or test environments – for example, live data that is used in UAT or test platforms
web or UI platforms – for example, web or portal servers that access the data of the critical system for presentation to end users
telephony systems
isolated internal environments or ‘walled gardens’

Summarise your rationale

You should provide a short explanation about the boundaries you have set, especially boundaries that you have decided to exclude from your self-assessment.

It’s important to consider the risks of excluding systems and infrastructure from your self-assessment.

If you decide something is out of scope, you need to declare:

what is out of scope
your justification for excluding it

If you exclude something from a system’s scope, it’s important to consider what effect this could have on the assessment of any other critical systems in scope – for example, shared functions that underpin several systems.

Example:
NE Council has decided that:

Backup is in scope – all data from the critical system is backed up to our XYZ backup solution in the data centre and is managed by NE council
Corporate finance system is not in scope – the critical system integrates with our corporate finance system, but it is not a component of the critical system

5. Create or update an architecture map of your critical system

Use the information gathered in your architecture mapping workbook to create or update an existing diagram that accurately represents your council’s critical system architecture.

Your diagram needs to show the infrastructure and systems necessary for the chosen critical system to function, including:

any sites your council has, including physical and cloud
site connections, including firewalls
zones, networks or network segmentations
systems that support your critical system
breakdown, dependencies and boundaries

Follow our step by step guide to create your architecture map.

Infrastructure components to include

You should highlight the following infrastructure components in your architectural diagrams where relevant:

authentication solutions
entry and exit points for users and data
administrative access and connections
web access, proxy, protection
mail protection solution and data loss prevention (DLP)
endpoints – managed and unmanaged
user connectivity options – internal and external
protection mechanisms – for example, firewalls
data backup locations and segregation
network segregation, including micro-segmentation
commercial (third-party) supplier network connectivity and integrations
commercial (third-party) supplier managed infrastructure and devices
operational technology (OT) and infrastructure
legacy or out-of-support systems
SOC, SIEM and other monitoring activities
sensitive data stores

6. Review your architecture workbook and diagrams for quality and accuracy

Review your architecture workbook and map(s) to make sure they include all the information you want your independent assurer to review.

Remove any sensitive information before sharing, including IP addresses and host names.

You should also make sure:

your architecture workbook accurately reflects your council
your diagrams accurately reflect your council
your architectural scope for CAF is appropriate and the reasons and risk of any descoping are understood
your diagrams include the elements in the architecture mapping criteria list, where relevant
any feedback has been addressed

7. Share your architecture mapping work with your independent assurer

Once your architecture workbook and diagrams have been reviewed and signed off, make sure they are securely stored and that your independent assurer can access them.

Once you have had feedback from the independent assurer, share the workbook with your CAF quality assurer and approver to discuss, so they understand the technical scope of your critical systems self-assessment, limitations and risks.

Making architecture scoping decisions

Contact the CAF for local government team

Email us to ask a question or share feedback.