Practical guide
GDPR questions for church software suppliers
A practical, evidence-focused question set for UK churches assessing software contracts, personal-data handling, security and data exit.
Published · Updated
Quick answer
Ask a supplier for evidence about the exact service and account your church would buy, then assess it against the data you genuinely need to process. A statement that a product is “GDPR compliant” is not enough. For most UK churches the useful questions are: who is responsible for each processing activity; what the contract says; who can access which records; which suppliers receive data; how an incident is handled; and how the church retrieves or deletes data when it leaves.
This guide is for UK churches assessing hosted church-management, giving, rota or website software. It is a procurement aid, not legal advice or a declaration that a supplier complies with the UK General Data Protection Regulation (UK GDPR). It was researched on 25 July 2026; legislation and supplier terms can change.
Scope, method and the decision before the questions
This is a representative guide, not a market-wide compliance review. The product examples are drawn from the directory’s current evidence records. They were not hands-on tested, suppliers were not interviewed, and an unknown item is not a negative finding.
Start by mapping the activity, rather than asking a generic privacy question. A public newsletter sign-up, a regular-attender record, a children’s check-in list, a pastoral note and a Gift Aid claim do not carry the same risks. Church records may reveal religious belief and sometimes health, safeguarding or criminal-offence information. The ICO explains that special-category data needs additional conditions as well as a lawful basis; seek appropriately qualified advice where the processing, structure or risk requires it.
The church normally decides why and how it uses its member and donor information, but roles can vary by workflow. Do not assume labels in a supplier’s marketing material settle the question. Record the purpose, categories of people and data, access roles, retention position, other systems and the named church owner before a demonstration.
When a new system is not the first answer
Do not move scattered sensitive records into a new platform merely because it has more fields. First stop unnecessary collection, separate restricted pastoral or safeguarding processes from ordinary administration where appropriate, and document who may see what. A small, controlled existing process may be safer than an ambitious migration with no accountable owner.
Likewise, do not use a volunteer’s personal spreadsheet, email account or messaging group as the de facto database because a product trial feels inconvenient. The organisational problem is unclear responsibility: software cannot supply a retention policy, access review or a decision about what should not be recorded.
Questions for the supplier
Use the same questions with every shortlisted supplier and retain the answers, links and date checked in a simple decision record.
Contract, roles and sub-processors
- Which legal entity supplies the service and signs the contract for our account?
- For our stated workflows, what does the supplier say about controller, processor or any other role, and where is that recorded?
- Can we read the data-processing terms before committing, including the required processing details and instructions?
- Which sub-processors handle customer data, for what function, and how are material changes notified?
- What assistance is available for rights requests, security incidents and a data protection impact assessment (DPIA) where one is needed?
- At the end of the contract, will data be returned or deleted, in what timescale, and what happens to backups?
The ICO says controller–processor contracts need specific provisions, including security, sub-processors, assistance with obligations and end-of-contract arrangements. A generic privacy-policy link is not a substitute for checking the contract that applies to the church.
Access, security and day-to-day administration
- Which roles can view, change, export or delete each record type? Can the church create a least-privilege role for a group leader or finance volunteer?
- Is multi-factor authentication available for administrators, and is it optional or enforceable on the package we would buy?
- What audit information records exports, permission changes and important record changes, and can the church retrieve it?
- How are former staff and volunteers removed, and how will the church review access regularly?
- What is the incident-notification route and support contact? What responsibilities remain with the church for user accounts and devices?
The National Cyber Security Centre (NCSC) recommends confidence proportionate to the sensitivity of the information and the impact of loss or outage. It also distinguishes a supplier assertion from evidence. Ask for relevant current documentation; do not treat an ISO or SOC label alone as proof that the exact service and configuration meets your needs.
Location, transfers and continuity
- Where are production data and backups stored or processed for this account?
- Does any support, analytics, email, payment or other integrated service receive personal data?
- If data is transferred internationally, what documentation explains the arrangement and safeguards?
- What availability, backup, restoration and support commitments are contractual rather than marketing statements?
- What happens if the supplier changes a sub-processor, pricing plan or terms?
“UK hosting” can be helpful context but does not settle every contract, access, backup or transfer question. Conversely, data processed outside the UK is not automatically unlawful. Record the evidence and get advice where the church needs it.
A practical evidence record
Use this short worksheet for each candidate. It avoids a cosmetic compliance score while making unresolved decisions visible.
| Topic | Evidence received | Status | Owner and next action |
|---|---|---|---|
| Contract and processing terms | URL/version and date saved | Confirmed / supplier claim / not confirmed | Name the church reviewer and question |
| Roles and permissions | Trial result using fictional data | Confirmed / not confirmed | Test restricted leader and administrator roles |
| Sub-processors and locations | Current supplier list and explanation | Confirmed / supplier claim / not confirmed | Compare with church data map |
| Incident and support process | Contract or policy reference | Confirmed / not confirmed | Agree internal escalation contact |
| Export, deletion and cancellation | Trial export and written terms | Confirmed / not confirmed | Inspect file and record exit steps |
If planned processing is likely to be high risk, a DPIA is not a supplier form to tick. The ICO describes it as a way to identify and minimise risks before processing begins and says it is legally required for processing likely to create high risk. A church should decide whether it needs one using its own processing, then obtain advice if unsure.
Software listings to explore
These profiles publish or record supplier-provided privacy, hosting or processing information. They are not a ranking, endorsement or compliance assessment, and their data should be tested against the current contract.
- ChurchSuite is relevant for its published UK GDPR and Data Protection Act material and configurable access controls. Confirm the current hosting and sub-processor position for your account.
- ChurchLinker publishes GDPR, sub-processor and data-processing-agreement links and states that data is held in UK/EU data centres. Request the live documents.
- ChurchDesk publishes security, privacy and data-processing material and states hosting in Germany. Check the contractual terms, sub-processors and account settings.
- ChMeetings publishes security, terms and a data-processing addendum. Its profile records supplier-published US hosting information; verify applicable region and transfer safeguards.
Implement, review and leave responsibly
Name a day-to-day data owner before importing anything. Configure roles from the agreed data map, use fictional or minimised data in trials, and keep a record of contract versions, access decisions and supplier answers. Train the people who will administer access; a technically sound product can still be mishandled by an unowned process.
Before going live, test an export. Open it without the supplier’s application, check that essential fields and consent information are intelligible, and record who can request it. Review permissions after launch, after staffing changes and at least annually. The Charity Commission’s controls guidance is a useful reminder that trustees retain responsibility for suitable controls even where work is delegated.
Your next step is to complete the worksheet for two plausible suppliers and ask the same unresolved questions in writing. If the church cannot describe its data boundary and owner, pause the procurement before booking demonstrations.
Sources and research limits
Researched 25 July 2026 from the authoritative sources below and the directory’s recorded supplier sources. This is not legal advice, a complete market review or hands-on testing. Supplier claims, terms, locations and security features must be checked for the exact product and plan under consideration.
- ICO: special category data (accessed 25 July 2026)
- ICO: contracts and liabilities between controllers and processors (accessed 25 July 2026)
- ICO: data protection impact assessments (accessed 25 July 2026)
- NCSC: choosing a cloud provider (accessed 25 July 2026)
- Charity Commission: internal financial controls for charities (accessed 25 July 2026)