Assess and manage your council's cyber resilience alpha assessment report
MHCLG's Assess and manage your council's cyber resilience alpha service assessment report
Assess and manage your council’s cyber resilience
| Assessment date: | 14/05/2026 |
| Stage: | Alpha |
| Type: | Assessment |
| Result: | Red |
| Service provider: | MHCLG |
Service description
This service aims to solve the problem of councils and MHCLG lacking a reliable, scalable way to build an accurate and comprehensive picture of cyber resilience from repeated CAF for Local Government assessments, due to limitations in usability, coordination and data quality. It provides a single, secure and intuitive digital platform for councils and independent assurers to manage, complete, submit and update multiple assessments—improving continuity, reducing burden, and enabling better assurance and insight over time.
Service users
This service is for local authority staff, independent cyber security professionals, and MHCLG colleagues who need a simple, secure and reliable way to assess, manage and use data on cyber resilience. From a user’s perspective, it provides a single place to complete, review and update multiple Cyber Assessment Framework (CAF) assessments, while enabling MHCLG to collect consistent, high-quality data and generate meaningful insights at scale. It is designed to reduce the burden of managing assessments, improve co-ordination between contributors, and support better decision-making, assurance and oversight of cyber resilience across the sector.
| Things the service team has done well: ● Lead Assessor - The team demonstrated a sustainable approach to delivery, with an actively engaged service owner and established roles, including embedded engagement functions, reducing reliance on external dependencies and supporting long-term service ownership
● Design assessor - The team have made a good start to tackling a complex service problem, with a broad set of users and a large timescale. They have clearly demonstrated a lot of work and have made good progress in using user-friendly language in the service.
● UR assessor - The team demonstrated a good understanding of the distinct user subgroups that need to be tested and recognises the value of capturing a range of user experience levels. They have also planned proactively for Beta by including users with accessibility needs.
● Tech assessor – The technical approach of using an existing service as a jumping-off point was really good to see, even if there are some caveats to this approach. The plan for deployment in cloud infrastructure looks sound and to follow secure-by-design practice, and the team has expressed the intent to undergo a formal security testing round once the application has been deployed in this target environment. | | — |
1. Understand users and their needs
Decision
The service was rated green for point 1 of the Standard.
Optional advice to help the service team continually improve the service:
• Despite the absence of testing with users with accessibility needs to date, the team has been transparent and has set out plans to address this in future work. The panel were satisfied with the approach outlined in your follow-up documentation. It is clear that you have thoroughly considered how to address these gaps and have explored a wide range of options to engage users with diverse accessibility needs.
We are confident that, if delivered as planned, your approach will enable you to meet this requirement in Beta.
However, this remains an area of high priority, and we would expect to see strong evidence of delivery and learning in this space at the next assessment.In addition, we would expect to see factual evidence of how many users with universal barriers or situational accessibility needs were included, for example through analysis of survey data.
• It is important to consider accessibility in a broad and inclusive way. Universal barriers are not limited to visual impairments alone, but can include a wide range of access needs, such as visual impairments (for example loss of vision or colour blindness), hearing impairments (including deafness or hearing loss), neurodiversity (such as ADHD or autism), and learning difficulties (for example dyslexia, dyspraxia, or dyscalculia). Recognising this breadth helps ensure research and design decisions do not unintentionally exclude users with different needs.
• We’d also like you to consider non-digital routes for people who cannot access the service online. Looking ahead to Beta, what offline routes will be available, for example support through a contact centre or service desk?
2. Solve a whole problem for users
Decision
The service was rated green for point 2 of the Standard.
Optional advice to help the service team continually improve the service
● the service should be developed working with the central / DSIT CAF service team so that research findings and approaches can be aligned, where relevant
● there is perhaps still time to consider whether there are other possible approaches to solving the user problems, such as hosting documents on SharePoint as an example
● work in the open so that people inside and outside the organisation know what the service team is doing - increasing the potential for collaboration and reducing duplication of effort — potential to reach out and talk to other teams on cross-gov, to find out how other teams solved similar problems
● think about creating cross-service journey maps, to help the team think about hand-off points and potential gaps in the service
● It’s important to clearly show how the service is helping users solve their problems, using direct evidence such as slides with clear user insights
3. Provide a joined-up experience across all channels
Decision
The service was rated amber for point 3 of the Standard.
During the assessment, we didn’t see evidence of:
● comprehensive plans to think about user journeys beyond the digital service, such as related experiences outside of the service, support and onboarding
● making changes to existing spreadsheet solution based on user research findings so that, if users had to fall back to the spreadsheets some familiarity would be present
Optional advice to help the service team continually improve the service
● the team should consider what happens when users cannot access the service, what support is available, how can they get access to the service
● if the service is down, what alternatives are there to the service, beyond falling back to the spreadsheet option, or how does the spreadsheet fallback join back up with the main service, using consistent language and having greater consistency with the digital service experience
4. Make the service simple to use
Decision
The service was rated red for point 4 of the Standard.
During the assessment, we didn’t see evidence of:
● starting the prototype for the first round of user research with core GDS components to support a simple, familiar service and to test whether core components can meet user needs
● testing a simpler version of the service without introductory text and guidance to understand whether users need additional information, it is my view that overloading pages with guidance about how to use the service can add to cognitive load and make the service UI harder to understand, correspondingly, core GOV.UK components are well researched and we should have a high confidence that people can use them without help, given the right headings and labels
● removing duplicated content on pages, such as repeated guidance in paragraphs and labels (such as on link)
● a clear and consistent site architecture, with navigation that supports users to understand where they are in the service, for example Annual assessment appears in the service navigation after the user has completed the onboarding setup, it might be better to keep the service navigation predictable and use the section page for the section that cannot be started before another is completed, to give users guidance on this, otherwise there is a greater risk that users may miss service navigation changes. This also relates tohttps://www.w3.org/WAI/WCAG21/Understanding/consistent-navigation
Optional advice to help the service team continually improve the service
● consider stripping back page content to its bare minimum (several pages had content telling the user how to use the page and, in some places, there was duplicated content and links, multiple captions at different sizes (such as here link) which add to cognitive load and make the service harder to understand)
● test the service with less content to begin with, using research to find gaps in content and functionality
● use core components until there is evidence that they cannot work for users, in the prototype there are examples of GDS start buttons, blue MOJ alert panels (alongside inset panels), cards and side panels, all of which add to the complexity of the UI
● try to stick to using 1 thing per page, some pages were overly complex, such as link and pages with multiple form elements can make a page validation challenging for users
5. Make sure everyone can use the service
Decision
The service was rated amber for point 5 of the Standard.
During the assessment, we didn’t see evidence of:
● testing the prototype with users of assistive technology or users with access needs
● correctly implementing core patterns in line with accessibility requirements, including appropriate placement of error summaries and use of clear, descriptive form labels
● sufficiently detailed understanding of accessibility requirements
Optional advice to help the service team continually improve the service
● test the service prototype (and service) with users with access needs, even if they are proxy users so that accessibility issues can be identified
● organise an accessibility audit for the service, and consider the WCAG standards and what this means for the use of components in the service
● designing a service that is accessible will help the team design a service that is simple to use
● putting content between label and form elements such as inputs may mean that the guidance cannot be seen by assistive technologies and screen readers, such as on link
● using nested conditionally revealed questions can cause serious issues for users of assistive technology, such as on this page link
6. Have a multidisciplinary team
Decision
The service was rated green for point 6 of the Standard.
Optional advice to help the service team continually improve the service
The team described strong links with the community engagement team, including shared insight and representation in the agile team. For Beta, to improve on what you already have, look to strengthen the narrative on these areas:
• Clarifying how engagement and support roles are embedded in sprint-level delivery, not operating as adjacent functions
• Ensuring that support insight (email queries, WARPs, events) is triaged and prioritised alongside user research and that there is well articulated clear ownership within the core team for acting on that insight
• Reducing reliance on external teams as intermediaries, rather than part of the core service team
7. Use agile ways of working
Decision
The service was rated green for point 7 of the Standard.
Optional advice to help the service team continually improve the service
Applying a true agile way of working of inspect → learn → adapt . For Beta, you need to evidence a full loop:
● What you tested
● What you learned
● What decision was made
● What changed in the service
From your Alpha artefacts, you already have examples (e.g. navigation redesign based on user failure) but:
● Make this systematic and repeatable, not example-based
● Show this happening continuously across Beta
8. Iterate and improve frequently
Decision
The service was rated amber for point 8 of the Standard.
During the assessment, we didn’t see evidence of:
● A systematic and continuous iteration cycle operating across the service, rather than discrete examples of iteration from Alpha
● How iteration is consistently prioritised against the highest risks and remaining unknowns, with a clear rationale for what is being addressed next
● A clearly defined end-to-end iteration loop (insight → prioritisation → delivery → re-test) embedded in day-to-day delivery
● How insight from multiple sources (user research, engagement activity, support queries) is triaged and brought together into a single prioritised backlog
● Evidence that iteration is, or will be, driven by real service usage data, rather than primarily moderated research and external engagement
● A clear link between changes made and measurable improvement in user outcomes or service performance over time
● How the team ensures they are iterating the core service, rather than focusing on surrounding elements such as guidance or communications
● Evidence that the team has the capacity and technical flexibility to iterate frequently as the service moves into Beta
● Components such as dashboards need to be considered, tested, and iterated to better meet user needs, including testing across different devices.
9. Create a secure service which protects users’ privacy
Decision
The service was rated amber for point 9 of the Standard.
During the assessment, we didn’t see evidence of:
● Prioritisation given to using the Django authentication layer at the database access level to ensure any user can only ever access data that is relevant to their own organisation. This was identified by the team as a shortfall of the inherited CAF web application when applied to the use-case of dealing with multiple local councils, but we would like to see logic determining the organisation in a session context pushed down into the authentication/ ORM layer with priority.
10. Define what success looks like and publish performance data
Decision
The service was rated red for point 10 of the Standard.
During the assessment, we didn’t see evidence of:
● Clear, documented definition of what success looks like for the service, aligned to measurable service outcomes
● What the plan is for the stated aim of reducing the overall cost of delivering the service, which was verbally articulated but not formally defined within the artefacts
● Any quantified baseline for current BAU costs, against which improvement can be measured
● Defined cost-related or service KPIs (e.g. cost per transaction) outside of the 4 mandatory Digital KPI’s.
● An initial outline plan for Beta for a coherent performance framework linking user outcomes (e.g. completion, usability) with efficiency and cost
● An initial outline plan for Beta for tracking and publishing performance data, including cost and service performance measures
11. Choose the right tools and technology
Decision
The service was rated green for point 11 of the Standard.
12. Make new source code open
Decision
The service was rated green for point 12 of the Standard.
13. Use and contribute to open standards, common components and patterns
Decision
The service was rated green for point 13 of the Standard.
Optional advice to help the service team continually improve the service
● the service team should continue to aim to use core components wherever possible and work with other services to understand what patterns are helpful, including understanding research findings for any patterns
14. Operate a reliable service
Decision
The service was rated green for point 14 of the Standard.
Optional advice to help the service team continually improve the service
● the service could think about what the user sees if the service goes down and provide ways for the user to recover or get support in such an event
Next Steps
[Red]
In order for the service to continue to the next phase of development, it must meet the Standard and get CDDO spend approvals. The service must be reassessed against the points of the Standard that are rated red at this assessment.