ÌìÃÀÓ°Ôº

0. Version and certification validity notes

0.a. This (0.4) publication of the supplementary code for Disclosure and Barring Service digital identity checks (‘the DBS supplementary code’) comes into force on 1 July 2025.

0.b. It is the first publication of the DBS supplementary code by the Office for Digital Identities and Attributes (OfDIA), part of the Department for Science, Innovation and Technology (DSIT). It sets out rules for digital verification services (DVS) supporting Registered Bodies and Responsible Organisations to conduct identity verification as part of DBS checks. OfDIA is responsible for maintenance of the supplementary code.

0.c. DVS have been able to undergo certification for this purpose since 6 April 2022 as part of the UK digital identity and attributes trust framework certification scheme, by being certified against rules previously set out in DBS guidance on digital identity verification. The most recent version of the DBS digital identity verification guidance was published on 5 May 2022 and .

0.d. This publication is designed to support continuity, and the auditable requirements on DVS are designed to be unchanged. This DBS code either precisely replicates DVS facing rules from the previous DBS guidance on digital identity verification, omits them where they repeat the trust framework or constitute un-auditable recommendations, or reflects them in clearer, more auditable language. It also adds some new ‘could’ rules that providers do not need to follow but might support OfDIA and DBS policy aims.

0.e. Certifications against the rules that were set out in DBS guidance will remain valid until one of the following conditions occurs:

• a digital verification service uplifts its certification to this publication (including through an annual surveillance audit), thereby replacing the earlier certification; or

• the digital verification service’s certification against the beta (0.3) publication of the UK digital identity and attributes trust framework expires; or

• the digital verification service’s certification against the rules in DBS guidance expires.

0.f. To be certified against the DBS supplementary code, services will need to also be certified against a current publication of the UK digital identity and attributes trust framework, from the gamma (0.4) publication onwards.

Part 1 - Background and context

1. Introduction

1.a. This is the (0.4) publication of the supplementary code for Disclosure and Barring Service (DBS) digital identity checks. It sets out rules DVS must follow, and the recommendations they can follow, in order to be certified against the DBS supplementary code.

1.b. DBS requires that Registered Bodies (RBs) and Responsible Organisations (ROs) use services certified against the DBS supplementary code if they are conducting digital identity verification as part of DBS checks. DBS considers use of a service certified against the DBS supplementary code as equivalent to meeting the manual verification guidelines.

1.c. RBs and ROs will also need to comply with requirements set out in DBS guidance on what data they must obtain and retain from a DVS. These requirements also apply when a DVS provider is acting as the RB and/or RO.

1.d. This DBS supplementary code builds on the rules set out in the 0.4 version of the UK digital identity and attributes trust framework (the ‘trust framework’). DVS can only certify against this DBS supplementary code if they are certified against the trust framework.

1.e. Terms in this document are defined as set out in the trust framework’s definitions and glossary. In this document, ‘you’ and ‘your service’ are used to direct a provider to the specific rules their organisation and service(s) must follow, and the recommendations they can follow, to be certified.

1.f. The DBS supplementary code does not set any new requirements for RBs and ROs. The requirements for RBs and ROs are set by DBS, not OfDIA or DSIT. The requirements for RBs are set out in the DBS code of practice, and the requirements for ROs are set out in the basic check guidance and polices.  

Part 2 - Rules of the DBS supplementary code

2. Applicable roles

2.a. You must perform the role of identity service provider and/or holder service provider as described in the trust framework to be certified against the DBS supplementary code.

3. Identity verification

3.a. You must follow the rules for identity service providers set out in the trust framework unless you are providing a holder service in line with section 5.

3.1. Acceptable GPG 45 Profiles

3.1.a. For the purposes of digital identity verification for DBS basic checks, the identity check must meet a GPG 45 medium or higher level of confidence.

3.1.b. For the purposes of digital identity verification for DBS standard, enhanced, or enhanced with barred lists checks, the identity check must meet a GPG 45 high or very high level of confidence.

3.2. Acceptable documents

3.2.a. If an expired British or Irish passport is used to create the identity, it must have expired no more than six months before the date of the check.

3.2.b. RBs and ROs may place further restrictions on the documents they will accept. You could consult DBS guidance for RBs and ROs to better understand any restrictions on the documents RBs and ROs accept.

4. Data to share with RBs and ROs

4.a. If the check is successful, you must provide the RBs or ROs relying on your service with the following information about the user in a clear, legible format which cannot be altered:

Data fieldÂ	±·´Ç³Ù±ðÌý
¹ó´Ç°ù±ð²Ô²¹³¾±ðÌý	ÌýÌý
Middle NamesÂ	Only required if applicableÂ
Present SurnameÂ	ÌýÌý
Date of BirthÂ	ÌýÌý
Identity Verified (Y/N)Â	ÌýÌý
Current Address Verified (Y/N)Â	ÌýÌý
Current AddressÂ	Only if you have verified itÂ
Date of Address CheckÂ	Only if you have verified the addressÂ
Evidence Checked ByÂ	This must be the name of your service, as it appears on your certificateÂ
Passport DetailsÂ	Only if provided to you by the userÂ
Driving Licence DetailsÂ	Only if provided to you by the userÂ
GPG45 ProfileÂ	The identity profile according to which the identity was createdÂ
GPG44 Authenticator QualityÂ	Only required if you are a holder service conducting the DBS identity check in accordance with section 5.Â
Subject IDÂ	ÌýÌý

4.b. You could agree with RBs or ROs relying on your service that you will verify and provide other data required as part of DBS check applications. Some RBs, referred to as ‘e-Bulk enabled’, are registered to submit DBS check applications electronically in bulk. As part of this they label data in a standardised way. You could refer to the to provide data to e-bulk enabled RBs to help you provide data to them in a suitable format.

4.c. You could provide the RB or RO with a record that your service was certified at the time the check was conducted, so they can retain that record for compliance purposes.

4.d. You could retain your own record that you conducted the check. Retention of information listed in 4.a is the RB or RO’s responsibility, as set out in DBS guidance. Your service does not need to retain this information.

5. Using a holder service to conduct a DBS check

5.a. If you want to use an identity stored in a holder service to conduct a DBS identity check, you must follow the rules for holder service providers set out in the trust framework and the holder service must have medium protection using medium quality authenticators as a minimum according to GPG 44.

5.b. To be used as described in 5.a, the identity must have been created in line with 3.1 and 3.2, and the data in 4.a must be shared with the RB or RO.