A new small-group leader gets her login on a Wednesday. She’s a volunteer, she’s delightful, and she needs to see who’s in her group and email them about Thursday.
She signs in, clicks around to find her group, and lands on a member profile. And there it is: a home address, a spouse’s phone number, the names and ages of two children, a note from three years ago about a hospital visit, and a giving history going back to 2019 with every amount.
She didn’t go looking. It was simply on the screen, because when the church set the system up in a hurry, the fastest way to make sure nobody got stuck was to give everybody the top level of access.
That’s how it happens in nearly every church. Not carelessness — expedience, under time pressure, years ago, by someone who has since moved on.
This is not about trust. It’s about blast radius
Say this out loud at your next staff meeting, because it disarms the whole conversation before it becomes awkward:
We are not doing this because we don’t trust anyone. We’re doing it so that one stolen password doesn’t expose everything.
Blast radius is a plain idea wearing a dramatic name. It means: when one account is compromised, how much does the attacker get? If every account is a full administrator, the answer is all of it — every address, every giving record, every note — no matter which of the twenty accounts they happened to catch.
And accounts do get caught. Phishing — the fake email that leads to a convincing but counterfeit login page — was the most-reported crime type in the FBI’s 2025 figures, with 191,561 complaints. It doesn’t select for the senior pastor. It catches whoever clicks, and in a church that is statistically going to be a volunteer with an old password and no second step at login.
The goal isn’t to make anyone prove they deserve access. It’s to make sure that the volunteer who runs the coffee rota, if phished on a Tuesday, costs you the coffee rota.
The data that shouldn’t all travel together
Your church management system holds the most sensitive information your organization has anywhere. Not the bank account — this. Four categories deserve to be separated from general access:
Giving amounts. Who gave what, and when. In many congregations this is the single most closely-held fact about a person, and knowing it changes how people are treated. Very few staff need it, and the ones who do are usually the treasurer, the bookkeeper, and the senior pastor — and some churches deliberately exclude the pastor. Whatever your practice, it should be a decision, not an accident of software setup.
Children’s records. Names, ages, guardians, pickup authorizations, allergies, sometimes photographs. This should be visible to children’s ministry leadership and to no one else. There are also legal dimensions here — background check records, retention obligations, and what you may keep about a minor — and those requirements vary by state. Ask a lawyer about your own; don’t take a blog’s word for it, including this one.
Pastoral notes. Counselling records, hospital visits, crisis notes, prayer requests that were shared in confidence. If your system lets staff write private notes on a person’s profile, find out right now who can read them. In a great many churches the answer is “anyone with a login,” and the people writing those notes have no idea.
Contact details and addresses. Lower-sensitivity, but not zero — for someone in a domestic violence situation, an address in a widely-accessible directory is a genuine safety issue. Some systems support a confidential or restricted flag on individual records. Find out whether yours does.
Systems differ in how finely they slice this, but the principle doesn’t: these four should be four separate decisions, not one.
The question to ask about each person
Not do we trust them? Everyone will say yes and the meeting will end.
Not might they ever need this? That question always answers yes, and it’s how you got here.
The question is: what does this person need to do their job this month?
The month framing does the work. It converts a hypothetical into a concrete recollection. The office administrator needs to add new households and update phone numbers — this month. The children’s director needs check-in and guardian records — this month. The small-group leader needs the roster and email for her group — this month. The treasurer needs contribution records — this month.
Nobody needs all four categories to do anything this month. When somebody does need something extra — pulling year-end statements, running a report for the board — grant it, do the task, and take it back. Temporary access is normal in every other part of church life. You give someone a key to the building for a season and then you ask for it back, and nobody takes offence.
The twenty-minute routine
Do this once now, then twice a year. Set a timer; the constraint is what makes it repeatable.
Export the user list. Most platforms will let you export or print the list of people who have logins and what level each one holds; if yours won’t, a screenshot or a typed-up copy does the job. Get it onto one page where you can see all of it at once. This step alone is usually the shock — churches routinely find far more active accounts than anyone in the room expected.
Group people by what they actually do. Not by their title. Sort the list into rough buckets: office and administration, finance, children and youth, pastoral, group leaders, and a bucket for anyone you can’t place. Four or five roles covers almost every church.
Find the accounts nobody recognizes. There will be some. The consultant who did your setup. An email address at a domain the church no longer uses. A name three people vaguely remember. A generic login called “office” or “admin” whose password is known to an unknown number of people. Deal with these first — they’re the highest-risk items on the page and the easiest to close, because nobody will miss them.
Downgrade before you delete. This is the step that keeps the whole exercise from going wrong. Deleting a user in a church database can orphan the records they created, break reports, or remove notes someone else relies on. So drop people to the lowest level that matches their bucket, and leave the account in place. Watch for a month. If someone genuinely can’t do their job, you’ll hear about it in a day and you can restore it in thirty seconds. Then delete what’s still unused. Downgrading is reversible and quiet; deleting is neither.
Write down the roles and set the next review. One paragraph in a shared document: here are our five roles, here’s what each can see, here’s who decides. Then put a recurring appointment in the calendar — twice a year is plenty, and pairing it with something you already do, like the annual meeting or the start of the program year, means it actually happens.
The doors nobody audits
Two categories sit outside the user list entirely, which is exactly why they get missed.
Integrations and API keys. An API key is a long string of characters that lets one piece of software log into another without a human being present. Your giving platform talks to your church database. Your website’s event form pushes registrations in. A texting service reads your contact list. A volunteer’s clever spreadsheet syncs attendance. Every one of those connections holds standing access, often at a high level, and it does not appear in the staff list you just reviewed.
Find the integrations or connected-apps section of your system and read it with the same question: do we still use this, and does it still need that much? Pay particular attention to anything created by someone who has left, and to keys generated by a volunteer for a project that finished. Those keys don’t expire because a person moved away. Revoke and regenerate anything you can’t account for.
Volunteers on personal phones. Most of your group leaders and children’s workers access the system on a phone that is also used by their spouse, their teenager, and occasionally the family iPad. That phone may have no lock code. It stays signed in indefinitely. If it’s lost at a football game, a member of your congregation’s home address is in a stranger’s hand.
You cannot manage those devices, and you shouldn’t try. What you can do is ask three things of anyone with a login: use a lock screen, turn on the extra step at sign-in if your platform offers it, and tell the office immediately if the phone is lost so the account can be signed out. Then find out now — not on the day it matters — whether your system can sign a user out of every device at once or force a password reset, and where that control lives.
The same shape, whatever platform you’re on
Churches run on Planning Center, Breeze, Tithely, Church Community Builder (now branded Pushpay ChMS), Realm, and a dozen others. Each names things differently, and the names change; the underlying concepts don’t, which is why this article describes them rather than giving you a menu path that would be wrong by next spring.
Look for: a list of users and their permission level; named roles or permission groups you can define once and reuse; separate toggles for financial and giving data; separate handling for children’s and check-in records; a restriction on who can read private or pastoral notes; a way to mark an individual record confidential; and a connected-apps or API section. Not every platform has all of these. If yours is missing one — particularly the ability to hide giving amounts from general users — that’s a legitimate question to put to their support team, and a legitimate factor when you next review the contract.
What to do this week
Export the user list. Just that, first — it takes five minutes and it will tell you more about your actual risk than an hour of reading.
Then spend fifteen minutes on the two highest-value items: close the accounts nobody recognizes, and check who can see giving amounts. If the answer to that second one is “everybody,” fix it today. It’s usually a single setting, and it’s the one your congregation would most want fixed.
Permissions are one of the fastest wins available to most churches. MissionDefend’s free assessment asks straightforward questions about how your organization handles member data, donations, email and accounts — no jargon, no product pitch — and returns a baseline score with a ranked list of what to address first.
No spam and no sales calls — just one email when it’s live.
Related reading
- every other account a departing volunteer still holds
- the broader guide to guarding member and giving records
- what happens when that database is breached elsewhere
MissionDefend provides cybersecurity readiness assessments and educational guidance for churches and nonprofits. It is not a penetration test, a security audit, legal advice, or an incident response service.
Sources: FBI Internet Crime Complaint Center, 2025 Internet Crime Report.