Guidance

Supplementary code for Disclosure and Barring Service digital identity checks (1.0)

Updated 9 June 2026

0. Version and certification validity notes

0.a. This 1.0 publication of the supplementary code for Disclosure and Barring Service digital identity checks (‘the DBS supplementary code’) will come into force under section 29 of the Data (Use and Access) Act 2025 on the date the first conformity assessment body (‘CAB’) is accredited to certify against it, which will be no earlier than 1 September 2026.

0.b. It is published 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 this supplementary code.

0.c. To be certified against the DBS supplementary code, services will need to also be certified against a current publication of the UK digital verification services trust framework (formerly known as the ‘UK digital identity and attributes trust framework’). 

0.d. The non-statutory gamma (0.4) version of the DBS supplementary code, published on 26 June 2025 and the statutory gamma (0.4) published on 1 December 2025 will remain valid for a limited period of time for the purposes of: 

• certification, such that certificates issued against those versions will remain valid and any audit and surveillance in respect of those certificates are conducted against those versions as relevant, subject to 0.e below; and  

• Part 2 of the Act (where relevant and where there exist certificates which are valid against them) such that references to supplementary code are to be read as references to the non-statutory gamma (0.4) and the statutory gamma (0.4) versions. 

0.e. The statutory gamma (0.4) version of the DBS supplementary code is only to remain valid for new certifications following the coming into force date of this 1.0 DBS supplementary code in the circumstances below:  

• The DVS applied for certification against the statutory gamma (0.4) DBS supplementary code before the day on which this 1.0 DBS supplementary code comes into force but the certification process had not been completed by that date, such that a certificate was issued by an accredited CAB after that date; or 

• The DVS applying for certification, at the point at which they apply for new certification, holds a certificate confirming they comply with the requirements under the non-statutory gamma (0.4) or the statutory gamma (0.4) versions of the DBS supplementary code and the application is made by that DVS before the certificate expires and within 15 months of the day on which this 1.0 DBS supplementary code comes into force.  

0.f. The non-statutory gamma (0.4) and the statutory gamma (0.4) versions of the DBS supplementary code referred to in 0.c will no longer apply for the purposes of certification and Part 2 of the Act, and certificates issued against them will expire and should be ignored for those purposes if any of the following apply:  

• 27 months have elapsed since the day on which this 1.0 DBS supplementary code comes into force (including that day);  

• a service uplifts to the 1.0 publication and has a certificate issued to confirm that; 

• the service’s non-statutory gamma (0.4) or statutory gamma (0.4) certification against the DBS supplementary code expires; or 

• the service’s non-statutory gamma (0.4) or statutory gamma (0.4) certification against the UK digital verification services trust framework expires.

Part 1 - Background and context

1. Introduction

1.a. This is the 1.0 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 1.0 publication of the UK digital verification services trust framework (the ‘trust framework’). DVS can only certify against this DBS supplementary code if they are certified against the 1.0 publication of 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 which case you must follow the rules in 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. An expired UK biometric residence permit must only be used to create the identity if it would be accepted for a manual check according to the DBS ID checking guidance.

3.2.c. If any other evidence is used to create the identity and it has an expiry date, it must not have expired.

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	Note
Given name(s)
Family name(s)
Date of birth
Identity verified	The response must be ‘Y’ if the identity was verified and ‘N’ if it was not verified.
Current address	Whether verified or user asserted (see 4.b).
Address verified	The response must be ‘Y’ if the address was verified and ‘N’ if it was not verified.
Date of address verification	Only if you have verified the address.
Evidence checked by	This must be the name of your service, as it appears on your certificate
GPG 45 profile	The identity profile according to which the identity was created
GPG 44 authenticator quality	Only required if you are a holder service conducting the DBS identity check in accordance with section 5.

4.b. You must provide the RB or RO relying on your service with the current address of the user. You must attempt to verify the user’s address. If you do not successfully verify the user’s address, you can share an address asserted by the user. You could refer to the ‘How to create, bind and share attributes’ guidance to help you assess the quality of the address attribute you share .

4.c. You must agree with RBs or ROs relying on your service whether you will provide them with the user’s passport details. These details must be verified if they are provided.

4.d. You must agree with RBs or ROs relying on your service whether you will provide them with the user’s driving licence details. These details must be verified if they are provided.

4.e. RBs and ROs may want a unique identifier to link a user to their application, for example a subject ID or application reference. You could work with an RB or RO to provide a unique identifier for this purpose.

4.f. 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’ RBs, 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 DBS e-Bulk Business Message Specification to help you provide data to e-bulk enabled RBs to help you provide data to them in a suitable format.

4.g. You must provide the RB or RO with a record that your service was certified against a valid version the trust framework and the DBS supplementary code at the time the check was conducted, specifying which version of each, so they can retain that record for compliance purposes.

4.h. 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.