Practical guide

How to audit your church software stack

Audit your church’s systems, owners, users, data, connections, costs, renewals and exit routes before deciding what to keep or change.

Published · Updated

Quick answer

Audit a church software stack by making one honest list of every system, spreadsheet, shared inbox, cloud folder, device-dependent app and subscription that supports church work. Record its purpose, owner, users, information held, connections, annual cost or renewal date, access, backup and exit route. Then decide whether to keep, improve, combine, replace or stop it. Do not begin by asking what platform to buy. A useful audit often produces a clear owner, a retired duplicate list, a documented renewal or an exit plan for a service nobody can now administer.

The audit is an operational and governance exercise, not a technical beauty contest. Include the informal tools people use because the official process is awkward. If a ministry runs from a volunteer’s personal account or an unshared spreadsheet, it belongs in the inventory even if no invoice appears in the church accounts.

Set a sensible audit boundary and team

Start with a 60–90 minute discovery session and one named audit owner. Invite a church-office representative, finance contact, ministry or volunteer representative and the person who manages systems. For sensitive processes, involve the relevant safeguarding, pastoral or records lead without putting sensitive details in the inventory.

Set a boundary: software and services that process church information or support a recurring workflow. Include church-management systems, accounting, giving, email, messaging, websites, hall bookings, rotas, livestreaming, presentation, ticketing, storage, password management, domain and email administration. Include spreadsheets where they act as a database or operational system.

The goal is not a perfect asset register on day one. It is a living list that can be checked at renewal, role change, migration and incident. Charity Digital’s cyber-security guidance specifically asks charities to maintain asset lists for devices accessing data and for software/cloud services.1

Build the inventory before judging products

Use one row per system or meaningful spreadsheet. Keep descriptions factual; do not infer data location, security certification or integration quality from marketing pages.

Field Record Why it matters
System and purpose Name and real job it does Reveals duplicate or hidden systems
Owner and backup owner Named church-controlled people Prevents a service being stranded after departure
Users and access Roles, not passwords Supports least privilege and training
Information and source of truth Broad categories and authoritative record Exposes duplicate people, finance or rota data
Integration/transfer Automated, manual or none Identifies re-keying and failure points
Cost, contract and renewal Current evidence and notice period Makes procurement and cancellation visible
Resilience and exit Export, backup, fallback and closure route Reduces lock-in and operational risk

The ICO says records of processing should be reviewed and kept accurate, with responsibilities assigned; it also expects regular review for data minimisation.2 A stack audit is not automatically a complete record of processing activities, but it can provide a useful starting map. Obtain appropriate advice if the church needs formal data-protection documentation.

Trace the journeys and points of failure

Pick five ordinary journeys: a newcomer, a gift, a volunteer rota, a hall booking, and an event or communication. Draw where information begins, which system becomes authoritative, who changes it, what transfers elsewhere and how the journey ends. Include manual exports and emails—not only official integrations.

Ask practical questions: If the owner is away, can someone else send the rota? If a payment fails, who notices? If a person changes email address, where is it corrected? If a subscription ends, can the church retrieve the records? If a platform is unavailable on Sunday, what is the fallback? These questions turn a list of logos into a decision record.

Mark each connection as one of four states: documented and working; manual but owned; undocumented; or no longer needed. Do not make every manual transfer an automation project. A small, documented monthly export may be safer and easier to maintain than a complex connection owned by one former volunteer.

Score decisions by operational risk, not novelty

Use a simple review table after the inventory. The aim is to decide the next sensible action, not to produce an overall technology score.

Signal Keep/improve Consolidate or replace Stop/archive
Clear purpose and active owner Maintain and document Consider only if it duplicates another system
Duplicate data or repeated re-keying Improve the boundary or transfer Evaluate a simpler source of truth Retire duplicate copy after migration
Unclear account ownership or renewal Secure ownership and contract evidence Replace if the risk cannot be resolved Close after controlled export
Sensitive data beyond need Minimise and restrict access Move to an appropriate controlled process Delete/archive under applicable rules
No usable exit or fallback Test export and contingency Prioritise migration planning Do not simply abandon records

Prioritise one or two changes. A stack audit that creates 20 simultaneous projects usually stalls. Fix the service with the clearest risk or operational cost first, then review the inventory at the next renewal or governance meeting.

Conduct the audit and implementation review

Use this checklist for the first cycle.

  1. Gather invoices, renewal emails, shared-drive lists and names of system owners.
  2. Create the inventory without deleting or changing access during discovery.
  3. Check that owners can log in through church-controlled contact details, not personal accounts alone.
  4. Trace the five real journeys and record source-of-truth and transfer points.
  5. Identify the top three risks, duplicates or renewal decisions with evidence.
  6. Assign a bounded action, owner and review date for each.
  7. Test one export, one role handover and one operational fallback before declaring the audit complete.

Keep evidence beside the row: contract link, export date, contact route, policy reference or meeting decision. Do not store passwords in the audit sheet. Use the church’s agreed password-management approach and give only authorised people access.

Schedule the next audit date while the first is still fresh. A lightweight quarterly review of renewals, owners and major changes prevents the inventory becoming another forgotten spreadsheet.

Software listings to explore

The audit is not a purchase guide, but these profiles can help when a resulting action needs a focused review.

  • ChurchSuite, ChurchTools and iKnow Church are broad church-management profiles to evaluate where several journeys need a shared source of truth.
  • ExpensePlus is a finance-focused starting point where financial administration is the audit finding.
  • MIDAS Room Booking and Eventcube illustrate specialist workflow systems that need clear ownership and handovers.
  • ChurchBase and ChurchTools are general productivity profiles where shared files and account ownership are in scope.

Use the software directory and relevant category pages only after the audit identifies a real decision boundary.

Sources and research limits

This guide was researched and checked on 28 July 2026. It is not legal, data-protection, cyber-security, financial or procurement advice. It does not establish compliance or the security of any individual system. Obtain appropriate professional advice where the audit exposes sensitive-data, safeguarding, contractual or financial-control issues.

Footnotes

  1. Charity Digital: What trustees need to know about cyber security (accessed 28 July 2026).

  2. Information Commissioner’s Office: Records of processing and lawful basis (accessed 28 July 2026).

Keep moving

Continue your decision

These next guides follow the same decision journey. They are not a ranking or a complete set of related products.