Guidance

Supplementary code for Disclosure and Barring Service digital identity checks (1. 0) pre-release

Published 3 March 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’) made using powers under the Data (Use and Access) Act 2025 comes into force on [date of final publication].

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. Certifications against the rules that were set out in the non-statutory and statutory 0.4 publications of the supplementary code will remain valid until [date to be confirmed] or 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 0.4 publications of the UK digital identity and attributes trust framework expires; or
• the digital verification service’s certification against the 0.4 publications of the DBS supplementary code expires.

0.d. 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’), from the 1.0 publication onwards.

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.