Supplementary code for Disclosure and Barring Service digital identity checks (0.4)
Source: gov.uk (2025-12-01)

This publication sets out rules for digital verification services supporting Registered Bodies and Responsible Organisations to conduct identity verification as part of Disclosure and Barring Service checks.

0. Version and certification validity notes

0.a. This version of the 0.4 publication of the supplementary code for Disclosure and Barring Service digital identity checks (‘the DBS supplementary code’) comes into force on 1 December 2025 and is the first statutory DBS supplementary code under section 29 of the Data (Use and Access) Act 2025 (‘the Act’).

0.b. The certifiable rules previously set out in DBS guidance on digital identity verification, most recently published on 5 May 2022, and the non-statutory 0.4 version of the DBS supplementary code published on 26 June 2025 will remain valid for a limited period of time (see 0.c.) for the purposes of:

certification, such that certificates issued against those versions are valid and any audit and surveillance in respect of those certificates are conducted against those versions as relevant; 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 certifiable rules set out in DBS guidance on digital identity verification, and to the non-statutory 0.4 version of the DBS supplementary code where those versions apply.

0.c These non-statutory versions will no longer apply for the purposes of certification and the Act, and certificates issued against them will expire and should be ignored for those purposes from and including the following dates respectively:

certificates against the certifiable rules previously set out in set out in DBS guidance on digital identity verification, most recently published on 5 May 2022, will expire on 31 March 2026; and

certificates against the non-statutory 0.4 version of the DBS supplementary code will expire on the date set out in the next version of the statutory DBS supplementary code as to when certifications against the 0.4 version of the DBS supplementary code expire.

0.d For clarity, the content in this statutory version of the 0.4 DBS supplementary code is entirely unchanged from the 0.4 non-statutory version save for the replacement of an earlier validity statement by 0.a-0.d in this section 0. The non-statutory publication can be found on the UK Government Web Archive (https://webarchive.nationalarchives.gov.uk/ukgwa/timeline1/https://www.gov.uk/guidance/supplementary-code-for-disclosure-and-barring-service-digital-identity-checks-04). Certificates against both versions accordingly confirm compliance with the same rules.

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

0.f. 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 can be accessed on the UK Government Web Archive (https://webarchive.nationalarchives.gov.uk/ukgwa/timeline/https:/www.gov.uk/government/publications/dbs-identity-checking-guidelines).

0.g. 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.h. 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.i. 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 (https://www.gov.uk/government/publications/dbs-code-of-practice) (RBs) and Responsible Organisations (https://www.gov.uk/guidance/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 (https://www.gov.uk/government/publications/dbs-identity-checking-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 (https://www.gov.uk/government/collections/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 (https://www.gov.uk/government/publications/dbs-code-of-practice), and the requirements for ROs are set out in the basic check guidance and polices (https://www.gov.uk/government/publications/basic-check-guidance-and-policies).

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 (https://www.gov.uk/government/publications/dbs-identity-checking-guidelines/dbs-digital-identity-verification-guidance) 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:

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 DBS e-Bulk Business Message Specification (https://www.gov.uk/government/publications/dbs-e-bulk-technical-documents#full-publication-update-history) 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.