Most UK churches track DBS checks on a spreadsheet. The spreadsheet lives on one person's laptop. When that person is unwell, on holiday, or simply busy, the safeguarding system at that church is the inbox of whoever last got copied in. The week of the kids' residential, someone realises that John's check expired three weeks ago, and there's a panicked round of phone calls before Saturday morning.

This is the legacy state of safeguarding admin at small and mid-sized UK churches. It's not anyone's fault. DBS coordinators are usually volunteers themselves, juggling this work with the rest of their lives, and a spreadsheet is what they had. But it's brittle, it isolates the data and it doesn't survive an audit. We can do better.

What 'better' looks like, concretely

Better is one shared record. The DBS check on John's file is the same record his church's safeguarding lead sees, the same record his youth-pastor team leader sees the state of, the same record John himself sees a summary of when he opens his member profile. Three different views of the same underlying fact. When the renewal happens, all three views update simultaneously.

The shared record makes four things possible that a private spreadsheet doesn't.

1. Reminders that fire on time and stop when they should

Each morning UK time, the system walks the DBS table and emails the named coordinator at 30, 14 and 7 days before each check expires, then once on or after the expiry date itself. Each threshold fires at most once per renewal cycle, tracked on the person's record, so a re-run can't double-send. When the coordinator saves a new issue date the ledger resets and the next cycle starts.

The piece churches keep telling us they wanted is the 'renewal in flight' marker. Most DBS umbrella bodies take three to six weeks to process. During that window, the legitimate reminder cron will keep nagging unless told to pause. So it can be told to pause: tick 'renewal in flight' on the record when the paperwork is in, and reminders stop until the new issue date is saved. No phantom 'YOUR DBS IS EXPIRING' emails to a volunteer who's been waiting six weeks for the umbrella body to send the certificate back.

2. Per-team visibility for the people closest to each volunteer

The coordinator isn't the only person who can act on DBS. The youth pastor who works with John every Sunday is often the one best placed to have a quiet word: 'John, mate, I noticed your DBS expires in three weeks. Can you get the form in by Friday?'. That intervention works because it's relational, in person, not another email in a full inbox.

But in the spreadsheet model, the youth pastor doesn't have the data. So the intervention doesn't happen. The week-of-the-residential panic does instead.

The new leader view at /member/groups/[id]/leader gives small-group and ministry leaders a DBS chip on each volunteer's row in their group. Green for current. Amber for expiring in the next 30 days. Red for already expired. Blue for currently renewing. No certificate numbers, no raw expiry dates. Leaders see the situation, not the file. It's enough for the relational nudge to happen at the right moment. A roll-up banner at the top of the leader's group view counts how many people on their team need attention, so they know to scroll.

Every leader view of DBS data is audit-logged, separately from contact-detail views, so the safeguarding paper trail distinguishes 'who knew the situation' from 'who saw whose phone number'. The chip is visibility, not a record dump.

3. The member sees their own check

Every member can open their profile and see the church's record of their DBS. They see the status (current, expired or renewing) and the expiry date if there is one. They don't see the certificate number; that's coordinator-only. They do see enough to know where they stand, and to act if something's wrong.

Next to that panel sits the agency contact card. The church records its umbrella body or DBS agency's name, email, phone and website once, centrally, in Settings → Safeguarding. That card then surfaces on every member's profile next to their DBS panel.

Why this matters: DBS renewal phishing is real and getting better. A scam email from a domain that looks like a DBS umbrella body, asking the recipient to log in and update their details, hits at exactly the moment the legitimate reminder hits. The recipient is primed to act, has just been thinking about DBS, and clicks. When the church has confirmed which umbrella body it actually uses, and that confirmation sits in the member's view of their own profile, the phishing email reads as obviously wrong. The sender doesn't match. The volunteer doesn't click. It's a small UI surface doing a meaningful piece of defence.

4. An audit trail that's actually defensible

Every DBS edit is logged with who, when and the previous value. That covers status changes, expiry updates, renewal markers and certificate number entries. The reminder ledger is timestamped, so you can show that the system did warn the coordinator at 30, 14 and 7 days before any specific expiry. Every leader view of DBS data is logged too, in a separate event class from contact-detail views.

When the Charity Commission, your insurance company or the diocesan safeguarding officer asks for evidence (was everyone serving with under-18s on the residential on 14 March DBS-checked?), the answer is a query, not a day of detective work. The records cross-reference cleanly with the Charity Commission members register and the 'as at date' snapshot reports, so an AGM or audit pack pulls together in minutes.

On the legal point, plainly

Safeguarding is the area where churches face their highest legal and reputational risk. The data we hold to evidence safeguarding compliance is exactly the data most often kept in the least-defensible form: an unstructured spreadsheet, last updated nobody quite remembers when, with no record of who saw what. The legal expectation for charities is moving towards 'demonstrable controls' rather than 'someone says they're doing it'. A shared system with logged reminders, role-scoped views, and an audit trail is demonstrably better than a spreadsheet, by quite a lot.

The transparency benefit lands here too. A safeguarding lead resigns or moves church. With the spreadsheet, their successor inherits a file (if they can find it) and no history of what's been done. With the shared record, the successor inherits the full state and an audit log of every action that got it there.

Setting it up, briefly

Four steps. Set the DBS agency contact card in Settings → Safeguarding. Tick the DBS coordinator permission flag on the relevant person's row in Settings → Users (Pastor and Admin roles get it automatically). Run the bulk DBS importer to backfill your existing spreadsheet. One CSV upload, dry-run preview, the system skips conflicts rather than overwriting silently. Then let the cron do the rest. Leaders see the chip without needing extra permission; visibility comes with the leader role for groups they lead.

Everything in this article is live on every plan, including Seed. No add-on, no per-record fee.

Why we built this the way we did

We could have built a coordinator-only inbox and called it done. Most church management tools do. The reason we didn't is that the coordinator-only model is the spreadsheet model with a nicer UI. Same information bottleneck, same single point of failure, same inability to surface a situation to the people who can actually act on it relationally.

Safeguarding works when more people are aware, at the right level of detail, with the right privacy boundaries. Coordinators see the full file. Leaders see the state of their own team. Members see their own check and the church's anti-phishing reference. Trustees and auditors see the history when they need to. Every view is logged.

It's the same principle that makes a church's safeguarding policy work in the first place: more eyes, clear roles, and a written record. We just gave it a software shape.

If you want the longer how-it-works reference, see the Safeguarding & DBS help article. If you're moving from a spreadsheet and want to know what the import looks like, the Importing data guide covers the bulk DBS importer alongside the People CSV importer. And if you want to talk through your church's specific situation (most do), drop us a note at hello@churchlinker.com. We read every reply.

Stop tracking DBS on a spreadsheet: one shared record from coordinator to volunteer