Abena’s church faced a phishing scare. Members could lose their passwords.

Church leaders should evaluate how software is maintained, what member data it stores, how accounts are protected, and what happens after an incident. A polished interface can make adoption easier, but it cannot protect a congregation when a convincing phishing message reaches their phones.

At 8:12 on a Monday morning, Abena was standing beside the church office printer in Accra, holding a screenshot a choir member had forwarded to her. The message used the church’s name, asked members to “confirm” their account, and linked to a page that looked close enough to the new member app to cause trouble.

Abena had spent weeks comparing event screens, group directories, and giving menus. The chosen platform looked modern. Members could find conference details without hunting through WhatsApp chats. Then three people called before breakfast, unsure whether they had already entered their passwords.

The immediate fear was clear: a member could hand login details to a fake page, and the church might have no quick way to warn everyone, reset access, or explain what information was exposed. The app had made communication easier. Now its familiar look had made imitation easier too.

That concern is not theoretical. Recent reporting described a Vatican-promoted app as a “phishing goldmine,” followed by a scramble to patch it. The lesson for churches is broader than any one app: software decisions carry an ongoing responsibility after launch day.

Maintenance is part of the product

Every app depends on code, cloud services, integrations, and people who keep them current. Vulnerabilities emerge after a platform is purchased. Phone operating systems change. A third-party service changes its rules. A fraud tactic that was rare six months ago becomes common enough to require a response.

Ask a vendor how they handle security updates. Who monitors vulnerabilities in the services they use? How quickly can they release a fix? Is there a documented process for reporting a suspected flaw? A vague promise that the product is “secure” gives a church very little to work with on a difficult Monday.

Maintenance also includes the ordinary work that prevents confusion from turning into risk: removing former volunteers’ access, reviewing administrator roles, and keeping integrations limited to what the church actually needs.

Abena’s team later realized their strongest question should have come before the demo: “When something goes wrong, who owns the response, and what will you do in the first day?”

Collect less, protect more

Church data can be deeply personal. Names, phone numbers, branch membership, volunteer roles, attendance records, pastoral notes, and giving information all deserve care. The right question is not simply whether a platform can store this information. It is why each field is necessary.

A conference registration may need a name, contact detail, and check-in record. A bus coordinator may need passenger lists and route assignments. Those are specific operational needs. Collecting extra personal details “in case they are useful later” creates more to protect and more to explain if an account is compromised.

Data minimization is practical leadership. It reduces the amount of sensitive information exposed when an error, phishing attempt, or unauthorized login occurs. It also makes permissions easier to manage. A transport coordinator should not automatically see every piece of member information. An usher checking a QR code should not need access to pastoral records.

For a church managing major events, the operational stakes are real. ChurchWork’s reconciliation of 8,752 registrations shows why connected records matter. The same discipline should apply to deciding which records belong in the system at all.

Authentication should match the risk

Passwords alone leave too much room for error, especially when members receive a convincing message while rushing between work, school runs, and church commitments. Leaders should ask what sign-in options are available, how accounts recover safely, and how the platform detects or limits suspicious access.

Phone-based one-time codes can reduce dependence on reused passwords. Strong administrator controls matter too: separate accounts for staff, roles limited to the work each person performs, and a clear way to remove access when someone changes responsibilities.

Authentication is also a communication problem. Members need to know what official messages look like and what the church will never ask them to do. A simple notice can help: the church will not ask for a password through a WhatsApp link; use the app directly or contact a known church office number when unsure.

When Abena addressed the choir that evening, she did not try to explain phishing in technical language. She showed the screenshot, told members where to report similar messages, and asked them to open the app from their phones rather than following links. The panic eased because people had one clear action.

An incident plan turns uncertainty into action

No church can promise that fraud attempts will never happen. It can decide how prepared it will be when they do.

Before signing, ask for the vendor’s incident-response process in plain language. Who contacts the church? How quickly will they share confirmed information? Can administrators force password resets, remove access, or send an urgent message to affected members? Where is data backed up, and who can access those backups?

Then write a small internal plan. Name the person who contacts the vendor. Decide who approves member communications. Keep official support channels visible. Rehearse the first message before a real incident forces someone to compose it under pressure.

A month after the scare, Abena kept a one-page response checklist in the same drawer as the conference signage. It included the vendor contact, the approved member notice, and the list of administrators who could act. The app still looked modern. More importantly, the church knew what to do if a familiar-looking message arrived again.