Who should see what: pastoral confidentiality in church software

In most church management systems, the administrator role can see everything. The member record, the giving history, the attendance pattern, and the counselling notes.

That design was not chosen maliciously. It was inherited from business software, where an administrator reasonably sees all company data. Applied to a church it produces a specific and under-discussed failure: the volunteer bookkeeper can read the pastoral file of the person sitting two rows in front of them.

Why churches are a special case

In a company, the finance team and the subject of a sensitive HR record are usually strangers, and professional distance does real work. A church has none of that insulation.

• The treasurer is usually a member of the congregation, not an employee.
• The administrator is frequently a volunteer, often long-serving and widely connected.
• The people in the records are neighbours, relatives and friends of the people with access.
• The information includes marriage difficulty, addiction, bereavement, health and financial hardship — disclosed in confidence to a pastor, not to an organisation.

A member disclosing a marriage crisis to their pastor has not consented to the church's accounting volunteer reading about it. In most church software, that is exactly what they have done.

Why policy is not a control

The usual answer is a policy: administrators are instructed not to look. That fails for three reasons.

1. It is unenforceable. Without access logging nobody knows whether it was followed, and most church platforms do not surface read access at all.
2. It is unfair to the administrator. It asks a volunteer to not-know something they can see in one click, about people they will greet on Sunday.
3. It fails the POPIA test. The security safeguards condition requires appropriate and reasonable measures against unauthorised access. Inside a small organisation the realistic risk is internal, and a policy instruction is a weak measure where a technical one is available.

What a real separation looks like

The control has to live in the data model, not the interface. Hiding a menu item is cosmetic; the question is whether the query can return the row at all.

The second row surprises people. Separating giving from pastoral care protects the pastor as much as the member: a pastor who does not know what someone gives cannot be accused of treating them differently because of it.

How ChERP implements it

ChERP enforces the separation at the database layer, under the same row-level security that isolates one church's data from another's. Accountants see finances; pastoral and counselling data is not visible to them — not hidden in the interface, not returned by the query.

This is the single feature most worth testing in a trial, because it is the one that is easiest to claim and hardest to retrofit.

How to test any vendor

1. Ask them to create a finance-only user in front of you.
2. Log in as that user and try to reach a counselling note. Not "is it in the menu" — try the direct record URL.
3. Ask whether read access is logged, and ask to see the log.
4. Ask what a full data export contains for that role.
5. Ask whether a church administrator can grant themselves pastoral access, and whether anyone is notified.

Step two is where most platforms fail, usually with a working page nobody expected to render.

The wider obligation

Health information and religious belief are special personal information under POPIA, with a higher bar than ordinary contact details. Role separation is not an optional refinement — it is the measure that most directly matches the actual risk. POPIA and your church database covers the full framework.