DBS compliance software

If your organisation runs DBS checks across many roles, the hard part is often keeping the decisions around those checks understandable. Why was a particular level requested? Which role did it cover? Who saw the certificate? Was the hiring decision recorded? Has the role since changed? Those questions can be difficult to answer when information is spread across hiring inboxes, spreadsheets and local files.

DBS compliance software should help an employer organise that administrative trail. It should not make a legal eligibility decision, order the wrong level for the sake of convenience or convert a document upload into proof of suitability. The recruiting organisation still decides which check may be requested and whether a person is suitable for the work. The DBS employer guidance places responsibility for the appropriate check level with the recruiting organisation.

Complys is not a DBS registered body, umbrella body or check provider. It does not apply for, submit, process or issue DBS certificates. It does not search barred lists or perform an Update Service status check. Use an authorised DBS application route for the check itself. Use a worker record only for the part of the employer process that the record is designed and approved to hold.

The record that an employer needs to explain

A useful record begins with the work, not the certificate. The manager describes the actual duties and setting. An authorised reviewer identifies the legal basis for the proposed check level and records the source used. The applicant follows the proper identity and application process. The employer reviews the resulting certificate through an appropriate route, makes a fair decision and keeps a limited audit trail. The employer workflow guide explains those steps in depth; this page focuses on the software and record design that can support them.

For each role, an employer may need to know the worker identity, the role assessed, the check level, relevant workforce and barred-list scope, the decision maker, the date of review, the certificate issue date where it has a justified reason to record it, and the resulting decision. The exact fields and retention period depend on the organisation's purpose, data protection position and sector requirements. A generic list of fields is not permission to collect every item in every case.

The DBS model policy on handling certificate information distinguishes between limited details about a check and the certificate or its contents. It calls for secure storage, controlled access, use for the purpose requested and retention no longer than necessary. Some organisations may have a justified safeguarding-audit reason to retain a certificate; that requires a documented, lawful policy. Do not describe either blanket retention or blanket deletion as a universal rule.

What the current Complys implementation shows

The current Complys repository has a person-check record with a DBS type. That record has fields for status, date performed, next due date and a note. A worker-document category also includes DBS. These are direct implementation observations from the person-check form, worker-document route and data model. They support a limited statement: Complys has general worker check and document recording paths that can be labelled for DBS.

They do not prove that the product determines check eligibility, securely stores a particular certificate number, imports a DBS result, validates a certificate, produces a regulator-ready export, carries out a bulk submission, connects to an umbrella body or sends a particular reminder. Those capabilities are not claimed here. The release team should confirm what a customer can actually see and do in the deployed product before replacing this narrow description with a stronger promise.

The presence of a document category deserves care. A DBS certificate can contain sensitive criminal-offence information. A file-upload field does not make routine certificate-image retention necessary or lawful. An employer should decide what it needs to retain, who can access it and when it will be removed before using any upload path. If the approved policy keeps only check metadata and a decision record, use that approach instead of adding a full certificate simply because the interface permits it.

Track reviews without inventing a DBS expiry date

A DBS certificate has no official expiry date. It records information as at its issue date. An employer may choose a policy review point, be subject to a sector recheck requirement or need a fresh assessment when duties change. Software can record a next-due date, but that date should be labelled as an employer or sector review trigger. It should never be presented as a universal DBS certificate expiry.

Reviewing a record is also different from performing another check. A manager might confirm that the role and workforce have not changed. A safeguarding lead might decide a new application is needed under a sector rule. For a qualifying Standard or Enhanced certificate, the DBS Update Service employer guide sets conditions for a status check, including the individual's permission and the correct level, workforce and barred-list match. Recording a reminder in Complys does not perform that official status check.

Build the review calendar around actual triggers: a change in duties, a new assignment, a contractual requirement, a policy interval, a relevant safeguarding concern or a sector rule. Record which trigger applies and who will assess it. Avoid automatically replacing every worker's check on a fixed date merely because a spreadsheet once used a three-year column.

Keep the role and the person connected

One person may hold different roles over time. A certificate obtained for an earlier role is not a universal passport to all later work. If a worker moves from a general office role to a job with children, the employer needs a new role-based eligibility assessment. The existence of an old certificate does not grant access to an Enhanced check with a barred list and does not make the old information suitable for a different legal purpose.

Design the record so the reviewer can distinguish a person, an assignment, a specific check and a decision. A single green status attached to a person may hide the fact that a check related to a different role or workforce. If software cannot represent the distinction, the employer must keep a separate controlled decision record. It should not use a general product status as a legal clearance.

This is especially important for agencies and multi-site operators. A client organisation needs to describe the assignment accurately. An agency can coordinate administrative steps, but the legal basis for the level still comes from the actual work. A school, care provider and office may also have different sector rules. A central record should show which rule was used, not silently transfer one site's policy across the whole group.

Give each person only the access they need

The record may contain information far more sensitive than a standard workforce profile. A line manager may need to know whether a person can be scheduled for a particular task, while a trained HR or safeguarding reviewer may need access to the underlying decision. The employer should decide the access model before adding DBS material. It should also set a correction route for wrong information and a deletion or review point.

The DBS handling guidance is a useful starting point for access and retention policy, but the employer's actual data protection duties still need to be applied to its circumstances. Product demonstrations should show how permissions, exports and deletion work in the live tenant. The existence of a data field in source code is not proof of the final access controls in a customer account.

If someone asks to inspect a worker record, a good question is: what decision does this person need to make? If the answer is scheduling, they may need the outcome and relevant restriction rather than certificate contents. If the answer is a fair recruitment decision, a limited reviewer may need more detail. Record who made the decision and why rather than circulating a certificate to every manager.

How this spoke fits the wider product

The worker compliance software page owns the broad question of workforce records across documents, checks and other requirements. This page owns only the DBS administrative use case. The DBS record-keeping guide owns the legal and policy discussion about what to record and retain. The check-level selector helps readers locate official eligibility sources; it does not grant legal permission to request a level. These pages should link to each other in a clear hub-and-spoke arrangement when the site team completes integration.

For buyers, the practical evaluation is straightforward. Bring one real vacancy and one role change to a product demonstration. Ask the team to show where the role decision would live, which DBS-related fields are genuinely available, how access to sensitive information is restricted, and how a review date is represented without labelling the certificate expired. Ask how a worker-document upload is handled and how the employer can follow its retention policy. Ask for live evidence of any feature beyond the person-check and document categories described here.

Complys may be useful as the surrounding workforce record system, but the employer retains the responsibility to request only an eligible DBS level, use a registered or umbrella-body route where needed, assess the result fairly and secure the information. To explore the broader record workflow, view worker compliance software. To understand the decision path before buying, start with DBS checks for employers.