The monthly fee tells you what church software costs on a normal day. The security ownership model tells you what it could cost when an update is missed, an account is misused, or suspicious activity appears.
In 2017, attackers entered Equifax systems through a known vulnerability in Apache Struts. A patch was available, yet the vulnerable system remained exposed. The breach affected roughly 147 million people.
The central question soon became larger than whether a patch existed. Who was responsible for confirming that the patch reached every affected system?
The lesson inside the Equifax breach
Equifax had a process for distributing security alerts. According to the U.S. House Committee on Oversight and Government Reform’s report on the breach, the company sent an internal notification instructing staff to patch the Apache Struts vulnerability.
The process failed at the point that mattered most. The vulnerable system was not patched, and a scan intended to identify exposed systems did not find it.
Responsibility was spread across people, processes, and technical systems. Each component appeared to perform part of the job. Nobody successfully closed the loop by verifying that the vulnerable application had been updated.
Former Equifax CEO Richard Smith later testified before Congress about the breach. By then, the cost included investigations, remediation, leadership changes, and years of damaged trust.
A church will rarely hold data on Equifax’s scale. The mechanism still applies. Sending an update notice does not secure a system. Assigning one person to apply updates does not prove they were applied. Security needs a named owner, a verification step, and a response plan for the day something goes wrong.
What a transparent price should reveal
A church software quote may show a monthly subscription, setup fee, member limit, and SMS allowance. That information helps a finance committee compare plans. It says little about who maintains the system after launch.
Before choosing a lower-priced option, ask the provider to identify who handles:
- Security updates for the application, database, server, and third-party components.
- Access when a staff member changes roles or leaves the church.
- Administrator permissions across branches, ministries, and volunteer teams.
- Backups, including how often restoration is tested.
- Suspicious logins, exposed credentials, and possible data breaches.
- Communication with church leadership if an incident occurs.
The answers should name responsibilities, not offer reassurance. “We take security seriously” gives a committee nothing it can verify. “Our team applies critical updates and records completion” is useful. “Your church administrator must maintain the server” is also useful, provided the church understands the work and has someone qualified to own it.
Transparent pricing should make operational boundaries visible. A low subscription can still be a sensible choice. Trouble begins when the price assumes unpaid security work that nobody knows they accepted.
This is the same budgeting problem discussed in What Happens When Essential Church Software Costs Sit Outside the Quote?. Hidden costs often arrive as responsibilities rather than invoices.
Access control needs a real owner
Church systems can hold names, phone numbers, attendance records, group memberships, giving-related records, transport assignments, and pastoral information. Different people need different levels of access.
An usher checking in conference guests does not need the same permissions as a church administrator. A transport coordinator needs bus registrations, but may have no reason to view pastoral notes. A former volunteer should not retain access because nobody removed an old account.
ChurchFlow uses role-based permissions for members, branch administrators, transport coordinators, conference administrators, and super administrators. That structure supports a practical principle: give people access to the information required for their role, then review that access when the role changes.
Software can enforce the permissions configured inside it. Church leadership still needs to decide who approves elevated access, who reviews accounts, and who removes access promptly. The provider and the church each own part of the control.
Ask for this division in writing. One page is enough if it clearly identifies the responsible party for updates, access reviews, backups, incident investigation, and member communication.
Add security ownership to the buying decision
A useful pricing comparison should include a short security responsibility table beside the feature and cost columns. For every candidate, write the provider’s name or the church owner’s name against each recurring task.
Do not accept “shared responsibility” without defining the split. Shared work needs sharper boundaries because each side can reasonably assume the other side handled it.
Request evidence for the claims that matter. That might include the date of the last update, a description of role-based access, the backup restoration process, or the steps used to report a suspected incident. Never place real passwords or recovery codes in the procurement document.
Then assign one person inside the church to maintain the record. A named owner can follow up when staff leave, permissions change, or the provider announces an important update.
The Equifax failure did not begin with a lack of warnings. The warning existed, and the patch existed. The missing piece was verified completion. Put that lesson into the pricing review before the cheapest plan quietly assigns your church a security job nobody is prepared to do.
Comments
No comments yet.