DBS Update Service checks
For the helpdesk teamDBS Update Service checks
Section titled “DBS Update Service checks”The DBS Update Service lets an employer confirm that a person’s existing enhanced DBS certificate is still current, instead of applying for a fresh one each time. Keystone records what you do on the gov.uk service against the person’s DBS check in the Single Central Record — it does not contact gov.uk for you.
Why there’s no automatic sync
Section titled “Why there’s no automatic sync”There is no bulk DBS Update Service API. A status check is a per-individual, consent-gated online lookup, and the gov.uk form forbids prefill. So Keystone can’t fetch statuses in the background — a human has to do each check on gov.uk, with the individual’s prior consent, and record the outcome. Recording it here gives the SCR a true, audited record of who checked what and when, rather than a fabricated “we assume it’s fine”.
Recording subscription and consent
Section titled “Recording subscription and consent”Before you can rely on the Update Service for someone, two things must be true: they have to be subscribed to the service, and they have to have given you consent to check their status. On the person’s SCR record you record:
- Subscribed / Not subscribed — whether the individual holds a current Update Service subscription. Recording either state stamps the date and your user ID against the check.
- Marking someone as subscribed is the positive consent gate that enables future status checks. Marking someone as not subscribed routes them into the “needs a fresh DBS” bucket in the daily worklist.
If they’re not subscribed, the Update Service can’t be used and you’ll need a fresh enhanced DBS instead.
Recording a status check
Section titled “Recording a status check”Once consent is in place, open the gov.uk Update Service employer status-check page, perform the check by hand, then record the outcome against the SCR check. The outcomes are:
- Current — no new information — the certificate is still valid and nothing has changed. This is the “all good” result.
- Current — new information — the status flags that something has changed since the certificate was issued. Obtain a fresh enhanced DBS.
- Not subscribed — the person isn’t (or is no longer) subscribed. Obtain a fresh enhanced DBS.
- Not found — gov.uk couldn’t match the details. Re-check the certificate number and personal details.
- Details mismatch — the details didn’t match the record. Re-check before relying on it.
Recording an outcome stamps the check date and your user ID. Every check and consent action is written to the tamper-evident access log.
Permissions
Section titled “Permissions”Recording Update Service checks and consent is gated on scr::sensitive::dbs_check — typically the Designated Safeguarding Lead. A trust admin passes the gate automatically. It’s deliberately tighter than general SCR access because the action asserts a real safeguarding check took place.
The daily worklist
Section titled “The daily worklist”A scheduled digest (scr:dbs-worklist) emails whoever holds the scr::admin (or platform admin) role — typically the DSL — the manual work outstanding for enhanced-DBS staff, sorted into three buckets:
- Needs a fresh DBS — not subscribed, not found, details mismatch, or the last check returned new information.
- Due a status check — subscribed but never status-checked, or last checked longer ago than the cadence (365 days by default).
- Unknown — subscription and consent not yet established; confirm with the individual.
The digest never changes a record — it only surfaces the checks a human needs to action. A companion read-only command (scr:dbs-update-service-poll) reports how many enhanced checks would need a manual status check without writing anything.