Assess and manage your council’s cyber resilience alpha reassessment
MHCLG's Assess and manage your council’s cyber resilience alpha reassessment report
Service Standard assessment report
Assess and manage your council’s cyber resilience
| Assessment date | 15/07/2026 | |
| Assessment stage | Alpha | |
| Assessment type | Reassessment | |
| Service provider | MHCLG | |
| Result | Amber |
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.
Reassessment
•The panel was impressed by the significant progress the team has made since the previous assessment.
•The team has undertaken substantial work to improve the service and demonstrated a strong commitment to making the service simpler and more effective for users.
| •Evidence from the presentation, discussion and Mural artefacts showed a coherent framework for measuring success, performance and costs through Beta. The team established clear outcomes, KPIs and reporting arrangements, satisfactorily addressing all six previously identified concerns. |
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 green for point 4 of the Standard.
Optional advice to help the service team continually improve the service:
● continue to test assisted digital journeys, including support for local authorities who may require additional help using the service
● review content width and character length guidance and consider whether content in your service needs to be full width
● review the use of GOVUK Start buttons and ensure they are only used on GOVUK start pages, in line with design system guidance
● if future testing indicates it would be helpful, consider increasing heading sizes on longer or more complex pages to strengthen page hierarchy and aid navigation
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 green for point 10 of the Standard.
Optional advice to help the service team continually improve the service:
Benchmarking and measuring success
● As the service moves into Beta, I would encourage the team to work with performance leads to identify suitable comparators and gather evidence of improvements in usability, completion times and submission quality. This could include benchmarking against similar services and using comparative data to help validate assumptions, baselines and target measures.
Operationalise the performance framework
● As the service progresses towards Beta, focus on operationalising the performance framework by completing outstanding baseline calculations, assigning ownership for measures, agreeing targets and success thresholds, and confirming how performance data will be governed, reported and published.
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