POPIA and your church database: what compliance actually requires

A church database is one of the most sensitive collections of personal information a small organisation will ever hold. It records religious belief, family relationships, children, financial contributions, and — if the church does pastoral care properly — things disclosed in confidence that were never meant to travel further than one conversation.

The Protection of Personal Information Act treats most of that as special personal information, with a higher bar than ordinary contact details. This is a plain-language guide to what that means for a church running member software. It is not legal advice, and a church with a complex structure should take its own.

Why GDPR compliance is not the same answer

Most international church platforms will tell you they are GDPR compliant. That is a genuine and useful statement — the two laws share a great deal of structure — but it is not a POPIA answer, for three reasons.

• Different roles. POPIA speaks of the *responsible party* and the *operator*. These overlap with controller and processor but are not identical, and your contract with a vendor should use POPIA's language if South African law governs it.
• Different transfer rules. Section 72 sets conditions for sending personal information outside South Africa. A platform hosting your congregation's data in Virginia is a cross-border transfer and needs to be justified, not merely disclosed.
• A different regulator. The Information Regulator has its own expectations around registration of information officers and breach notification. A GDPR-shaped breach process does not automatically satisfy them.

Religious belief is special personal information

Section 26 prohibits processing special personal information — which expressly includes religious or philosophical beliefs — unless an exclusion applies. Section 28 provides the one churches rely on: a religious organisation may process its members' belief data where it is necessary to achieve the organisation's aims and principles.

That exclusion is narrower than it first appears. It covers members and people in regular contact with the organisation. It does not cover a bought-in mailing list, and it does not stretch to sharing belief data with third parties for unrelated purposes.

Health and pastoral information

Health information is also special personal information, and it reaches church systems constantly without anyone filing it that way: a prayer request mentioning a diagnosis, a counselling note, a hospital visit record, an allergy on a child's check-in card.

The practical question is not whether you hold it. You do. It is who inside your church can see it.

In most church software an administrator role can read everything. That design decision, imported unexamined, is how a volunteer bookkeeper ends up able to read the counselling notes of someone sitting two rows in front of them on Sunday.

POPIA's security safeguards condition requires appropriate and reasonable measures against unauthorised access — and inside a small organisation, the realistic unauthorised-access risk is internal, not a hacker. Role separation is the control that actually matches the risk.

ChERP enforces this at the data layer rather than by policy: accountants see financial records only, and pastoral and counselling data is not visible to them at all. Who should see what describes the model in more detail.

Children's information

Section 34 prohibits processing the personal information of children unless a listed ground applies, and consent must come from a competent person — ordinarily the parent or guardian. Any children's ministry check-in system is processing children's data, usually including a photograph and sometimes medical information.

Two things churches routinely miss: the consent needs to be recorded in a way you can produce later, and it needs to be specific about what you will do with the data, including whether photographs may be used in church communications.

The eight conditions, applied to a church

Questions to put to any vendor

1. Where is our data physically hosted, and if it leaves South Africa, on what section 72 basis?
2. Does your contract use POPIA's responsible party and operator language, or only GDPR terms?
3. Can roles be restricted so that finance staff cannot read pastoral records? Ask for a demonstration, not an assurance.
4. What happens to our data if we leave, and in what format do we get it back?
5. Which subprocessors touch our data, and are they listed publicly?
6. What is your breach notification timeline to us, and to the Information Regulator?

Ask the fourth question early. Export terms are the single most common unpleasant surprise in this category, and they are much easier to negotiate before you sign than after.

Practical steps for this quarter

• Name an information officer and register them with the Information Regulator.
• Write a privacy notice in plain language and link it from your website and your membership form.
• Audit who has administrator access. In most churches the honest answer is 'more people than should'.
• Record consent for children's data and for photography, separately.
• Check where your current platform hosts data, and write down the justification.