Request a Standard or Enhanced DBS Check alpha assessment
Service Standard assessment report Request a Standard or Enhanced DBS Check 27/04/2022
Service Standard assessment report
Request a Standard or Enhanced DBS Check
| From: | Central Digital & Data Office (CDDO) |
| Assessment date: | 27/04/2022 |
| Stage: | Alpha |
| Result: | Not Met |
| Service provider: | Disclosure and Barring Service |
Service description
Request a Standard or Enhanced DBS check allows Registered Bodies* (registered organisations legally entitled to request the required level of disclosure check – *RBs) to request a criminal record disclosure check. The service allows RBs to fill out basic details and trigger a request to the applicant to complete the required answers. The service then enables the applicant to complete the information, and send it back to the RB, where they can carry out the necessary out of service ID checks, before finally submitting the completed application to DBS via the service.
Service users
- Register Bodies (RBs): Registered organisations, audited by DBS who are required to comply with applicable legislation and adhere to DBS guidance
- Citizens (Applicants): Individuals who are required to have a criminal record check to Standard or Enhanced level by their employer, due to the nature of the role they are being recruited into or already carry out
1. Understand users and their needs
The service did not meet point 1 of the Standard.
What the team has done well
The panel was impressed that:
- the team identified 4 user groups, with the team focusing their primary research on the Registered Bodies and Applicants groups
- some research had been undertaken on the user experiences of an existing Basic DBS Check service to explore where needs may overlap, even though they serve different user groups
- the research built upon work undertaken in discovery which highlighted challenges faced by Registered Bodies that currently use paper applications. The team explained that 81% of Registered Bodies continue to use paper applications, with them experiencing challenges such as slower processing times and errors on paper forms
- a research roadmap is in place for beta, with a reasonably clear sense on the areas the team wants to focus on. The team explained that they will also be looking to replicate the valuable feedback mechanisms they have in place for the basic DBS check service on this service as well
What the team needs to explore
Before their next assessment, the team needs to:
- focus on exploring the needs of the other identified user groups such as employers and third-parties. In effect, each user group acts as a type of “serial user” with one dependent on the other in a series. Research questions can then take a slightly different stance: for example, in what ways do earlier users in the series impact the experiences of later users?
- aim to recruit applicants who are not already in a role that requires standard or enhanced DBS checks. This is to widen the research scope to include those applicants who are very new to requiring these types of checks, to understand if their needs differ in any way
- consider the use of diary studies with Registered Bodies to get a richer understanding of day-to-day use once the service goes live in private beta
2. Solve a whole problem for users
The service did not meet point 2 of the Standard.
What the team has done well
The panel was impressed that:
- the team has an awareness of the mental models of users and has taken them into consideration when designing the new service
- the team recognises there will be a change to related legislation in the near future. Their policy team is working with the Home Office to find out more
What the team needs to explore
Before their next assessment, the team needs to:
- explore the full end-to-end journey in more detail, such as the hand-off points between caseworkers, employers, registered bodies and ID checkers
- attempt to find out more about the effect of expected legislative changes on the service and any constraints they may bring
- explore how the service could make use of existing data, including data already provided to the DBS Basic Check service
- explore the risks around related projects, for example the planned project to update the e-Bulk system
3. Provide a joined-up experience across all channels
The service met point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the team has considered the data capture requirements of the existing e-Bulk system when designing the new service
- the team has plans to encourage transition from the paper service to the digital service
- the team has involved caseworkers in their design thinking and prototype iterations
What the team needs to explore
Before their next assessment, the team needs to:
- continue to make note of where existing e-Bulk requirements do not align with identified user needs, challenging them and encouraging change where relevant
- ensure that employers and citizens understand the wider journey and how this service fits into it
- test that letters, ‘one-time passcodes’ and offline elements of the service work as expected in the wider user journey
4. Make the service simple to use
The service did not meet point 4 of the Standard.
What the team has done well
The panel was impressed that:
- the team had iterated their designs based on user research findings, such as updates to the country drop-down field
- the team is aware that their choice of language can have a profound effect on the experience of some individuals
- the team has considered the existing user experience of the Basic DBS Check service
What the team needs to explore
Before their next assessment, the team needs to:
- define how unhappy paths will work across the service, such as if the ‘one-time pass’ fails
- make sure users know why they’re being asked to provide specific pieces of information, such as why they’re asking for their email address
- explore how data can be validated and verified within the service, while ensuring no fraud or security risks are introduced
- explore how the registered body journey and screens will work for bodies that are dealing with thousands of applications at a time, across a team of multiple individuals
5. Make sure everyone can use the service
The service did not meet point 5 of the Standard.
What the team has done well
The panel was impressed that:
- the team has used the prototyping kit and follows the GOV.UK Design System in most instances
- the team has plans in place to test the service’s accessibility in private beta
- some research had been undertaken from an accessibility perspective
What the team needs to explore
Before their next assessment, the team needs to:
- give further consideration to the assisted digital journey and to undertake some further research with users who have access needs. The team frequently used the terms “accessibility” and “assisted digital” interchangeably but they are two different things. An individual may have high digital proficiency and access needs (and vice versa). If they are struggling to recruit users for accessibility research, the team is encouraged to loosen the recruitment criteria to, for example, jobseekers who have access needs
- undertake further testing on mobile and smart devices, in particular, the applicant facing part of the service
- aim to recruit applicants for research who are not already in a role that requires standard or enhanced DBS checks, to ascertain whether their needs differ from those needs already identified (as in Point 1)
6. Have a multidisciplinary team
The service met point 6 of the Standard.
What the team has done well
The panel was impressed that:
- there is a multidisciplinary team with most digital roles dedicated full time to developing this service
- they have plans underway to recruit additional team members for Private Beta including a Performance Analyst, testers and more developers
What the team needs to explore
Before their next assessment, the team needs to:
- review roles within the team to ensure there is the right division of responsibilities. The team currently has an individual acting as both front-end developer and interaction designer which they found challenging. This should be split into two roles to allow each to focus on that aspect of the service
7. Use agile ways of working
The service met point 7 of the Standard.
What the team has done well
The panel was impressed that:
- the team has adopted an agile approach to delivery based on a combination of Scrum and Kanban practices. This currently includes 2-week sprints with internal sprint reviews, open show & tells, retrospectives and planning
- the team has reviewed and adapted this at regular points throughout the delivery process
- there is a clear approach to governance that is proportionate to the Alpha Phase. They have a plan for developing this in the Beta Phase to provide clearer oversight, escalation routes and stakeholder management
What the team needs to explore
Before their next assessment, the team needs to:
- partner with a more experienced agile team to seek advice on other options for improving their ways of working. The team gave some examples where they changed their approach when there may have been better options, such as issues when some backlog items were taking too long to complete
- further develop their plan for Private Beta, in particular how they will gather feedback to assess if the service is ready for Public Beta
8. Iterate and improve frequently
The service met point 8 of the Standard.
What the team has done well
The panel was impressed that:
- the team has iteratively developed their prototype with 6 iterations so far based on user research findings
- the team has been adapting and improving their ways of working based on feedback in the retrospectives
- when they identified that legislation would be a barrier, the team pivoted to identify an alternative approach
- there are mechanisms to adapt to changing user needs identified in user research and analysis
What the team needs to explore
Before their next assessment, the team needs to:
- review and iterate service content to ensure user needs are met
- review their approach to prioritisation to make sure they are researching the full user journey and iterating the design frequently
9. Create a secure service which protects users’ privacy
The service did not meet point 9 of the Standard.
What the team has done well
The panel was impressed that:
- considerable effort has been made to include security considerations during the early stages of the project
- core security fundamentals are catered for in the design, such as the use of encryption of data in transit and at rest
- the system will take advantage of the security features provided by the AWS platform such as role based security and tight restrictions on internal network traffic through security groups
What the team needs to explore
Before their next assessment, the team needs to:
- the existing plan to create a detailed security case and have it approved by the DBS security accreditor should be completed before the end of Alpha phase. It is important that the security aspects of the project are internally discussed and approved before development work starts to avoid this being a problem during the next phase
- there needs to be a clearer distinction between the security risks associated with the different groups of users and different solutions to cater for them. For example, a one time password sent via email may be sufficient for an applicant to submit their own details, but not for a registered body user with long term access to large volumes of other people’s personal data
- the planned use of the GOV.UK Sign In service is a high risk for the project and credible plans for an alternative solution should be in place
- the team should take advantage of the alpha phase to investigate alternative security technologies, such as two factor authentication systems
- the capability to audit user actions and to produce a legally robust evidence trail should be explored. Both from the user needs point of view and from the technology design point of view
10. Define what success looks like and publish performance data
The service met point 10 of the Standard.
What the team has done well
The panel was impressed that:
- the team has identified a clear initial set of performance indicators and understood how they will be measured. This will need to develop further as the team progresses but they have embedded performance into their approach
- they have recruited a performance Analyst to join the team shortly after this service assessment
- the team intends to adopt Disclosure & Barring Service’s (DBS) standard approach and tooling for performance analytics, using tools such as Google Analytics and Hotjar
- there is an established relationship with operations and ‘performance and insight’ teams to collect and share performance data. This is essential to improving end-to-end service performance
What the team needs to explore
Before their next assessment, the team needs to:
- expand their performance framework to include more strategic performance indicators to ensure the service fully meets its purpose and vision. This means ensuring there are indicators and measures linked to the purpose. For example measuring whether the DBS checks are achieving the intended outcomes
- review their performance targets to ensure they are sufficiently ambitious to meet user and government needs. This will include reviewing and expanding baseline data
11. Choose the right tools and technology
The service met point 11 of the Standard.
What the team has done well
The panel was impressed that:
- the project will build on technology choices made by existing projects allowing existing expertise to be shared and further enhanced
- there is sufficient planning of the tooling choices in place to enable the recruitment of a development team with the right skill set
12. Make new source code open
The service did not meet point 12 of the Standard.
What the team needs to explore
Before their next assessment, the team needs to:
- ensure the organisation has a policy in place that enables open sourcing and sets clear guidelines to the ownership of intellectual property
- develop plans to work in the open and to publish source code on public repositories and to have these in place before the main development starts in the beta phase
13. Use and contribute to open standards, common components and patterns
The service met point 13 of the Standard.
What the team has done well
The panel was impressed that:
- the team has consistently chosen to use open standard based components whenever there has been a choice to be made. For example the use of PostgreSQL and Jenkins
- the planned use of Nodejs and Java languages for the development builds on previous experience on other projects and is well used and supported in government
- the user interface design uses the GOV.UK Design System and there are plans to use other common government components such as the GOV.UK Notify and Sign In services
- the team plans to reuse existing in-house components
What the team needs to explore
Before their next assessment, the team needs to:
-
revisit their designs to ensure they’re compliant with the GOV.UK Design System and associated standards. For example, making sure they’re following the GOV.UK A to Z style guide on the use of abbreviations and acronyms
- ensure any in-house components that are reused on this project share a common codebase between the projects that use them and that there is a commitment and the resources to support them
- plan to publish and share the in-house components across government
14. Operate a reliable service
The service met point 14 of the Standard.
What the team has done well
The panel was impressed that:
- the service will be hosted on the cloud and is designed to make use of the providers capabilities, such as multiple availability zones and auto scaling
- the system operation will be supported by a service team and the project will be able to build and rely on existing expertise to ensure reliability
- there are detailed plans for system logging, monitoring and alert generation, which gives confidence that the system development will support this area
What the team needs to explore
Before their next assessment, the team needs to:
- plan for testing the recovery procedures during the beta phase to ensure that the documentation and deployment processes are reliable
Updates to this page
Published 25 January 2024