How to choose church safeguarding software

Quick answer

Choose safeguarding software only after the church or charity has agreed its reporting route, roles, record-retention approach and escalation process. The key question is whether a tightly controlled system supports the people who must record, refer, review and hand over information under the existing policy. Software can organise administration. It cannot assess risk, decide whether a referral is needed, replace a safeguarding lead or make a church compliant. This is procurement information, not safeguarding, legal or data-protection advice. For an immediate concern, follow the church’s current procedure and contact the appropriate emergency or safeguarding authority rather than waiting for a software decision.

This is a high-risk category. Involve the designated safeguarding lead, trustees or senior leaders with responsibility, and the relevant diocesan, denominational or professional advisers before moving real records. The Charity Commission says trustees retain responsibility even where work is delegated, and expects charities to handle and record concerns securely and responsibly.¹

Start with the safeguarding workflow

Write a short, agreed description of what happens from the first concern to the point at which the matter is referred, reviewed, retained or closed. Include out-of-hours arrangements and the route for allegations, complaints and whistleblowing. A supplier can demonstrate a form, task list or alert, but only the church and its advisers can decide whether that workflow matches local policy and the procedures of the relevant safeguarding partnership.

Ask four people to review the map: the designated safeguarding lead, someone who will enter information, a trustee or senior leader, and the person responsible for technology or records. Their job is to expose assumptions such as “every volunteer can see this” or “the system will notify someone”. Be explicit about what happens when the safeguarding lead changes, an account is unavailable, a volunteer leaves, or a concern is received by telephone rather than through the product.

The Charity Commission’s trustee guidance calls for suitable policies and practices, appropriate checks, and a clear system for referral or reporting. That is the standard against which a tool should be tested; a dashboard is not the standard.²

Define the information boundary and access model

Safeguarding records may contain information that is particularly sensitive. The ICO explains that special-category data has additional rules and that organisations should consider data minimisation and security alongside their lawful basis and condition for processing.³ Do not treat a supplier’s general GDPR statement as the answer for your church’s actual use.

Before a trial, decide which information belongs in the proposed service and which must remain in an established case-management, HR, DBS or statutory process. Set a minimum role list: who may create a record, view it, amend it, run a report, export it, administer users, and approve deletion. Ask whether access can be limited by role and whether changes, exports and permissions leave an auditable record. Do not load historic case material simply to make a demonstration realistic.

For Church of England bodies, the current Records and Information Management page points to a record-retention schedule updated in May 2026 and a record-keeping review guide; it says the safeguarding schedule is included in that wider schedule.⁴ Other churches should use the retention and archival requirements that apply to them. A supplier’s default retention setting is not a retention policy.

Use a decision checklist before narrowing the shortlist

Use this checklist in a documented meeting. A “no” is not automatically disqualifying, but it should create a specific mitigation or supplier question.

• Our safeguarding lead and trustees have approved the operating boundary and referral routes.
• We know who may see, add, amend, export and administer each type of record.
• We can test a non-sensitive workflow for a concern, a referral, a review and a handover.
• We have documented what evidence is needed for permissions, activity history and exports.
• We have a retention, review, archival and deletion approach approved by the appropriate advisers.
• We have asked where data is processed, how backups work, who sub-processors are, and how accounts are disabled.
• We have an exit plan that preserves only the records we are entitled and required to retain.

The purpose is not to obtain a perfect score. It is to prevent a decision being made by the most polished demonstration or the fastest available trial.

Compare evidence, controls and handover rather than claims

Create a comparison table from written answers and a live, non-sensitive trial. Do not infer a control from a marketing term such as “secure”, “compliant” or “case management”.

Ask the supplier for current terms, data-processing information, security material, support route, export sample and a clear explanation of any product limits. Ask the church’s advisers to interpret whether those answers are adequate for its policy; this directory does not certify a supplier’s legal or safeguarding suitability.

Run a controlled trial and decision review

Use invented names and fictional scenarios. Run at least three journeys: a concern received by the lead, a routine review task, and a change of role. Test keyboard access, permissions, records correction, search, report export and account removal. Include the people who would actually use the system, but do not make them paste real notes into a trial account.

At the end, make a short written decision record:

1. State the problem the product will solve and the processes it will not replace.
2. Record evidence seen, unresolved questions and the advice received.
3. Agree account owners, training, review dates and the escalation route if the system fails.
4. Agree a data-migration boundary; migrate only material approved under the church’s records approach.
5. Set a post-launch review date before signing the contract.

This is particularly important when a product combines volunteer checks, children’s registration, pastoral notes or communications with safeguarding administration. Convenience can widen access and duplicate sensitive information. Keep the boundary visible in training and in the user-permission review.

Software listings to explore

The following directory profiles are starting points for a documented evaluation, not endorsements or a ranked shortlist. Their supplier-published detail and evidence links should be rechecked before procurement.

• iKnow Safeguarding is a dedicated safeguarding profile to investigate where controlled case administration is the stated need.
• Parish Safeguarding Dashboard is relevant to Church of England contexts; confirm current diocesan fit and local procedures.
• MyConcern is a broader safeguarding-recording product; establish whether its workflows fit a church’s operating boundary.
• ChurchSuite may be relevant where the church already uses its wider database, but a connected system is not evidence that every safeguarding requirement is met.

Compare each profile against the same written checklist. Where public information is incomplete, ask the supplier rather than marking a capability absent or assuming it exists.

Sources and research limits

This guide was researched and checked on 28 July 2026. It relies on public sources and does not assess implementation quality, contracts, local safeguarding policy, or a supplier’s real-world security controls.

Read the current safeguarding software category alongside this guide. If a concern is live, use the church’s reporting procedures and appropriate professional or statutory routes; do not use this guide as an incident-response manual.