MissionDefend Blog

Home Articles Get your free assessmentComing soon

Tag: church management software

  • Everyone Is an Admin: A Twenty-Minute Permissions Audit

    Everyone Is an Admin: A Twenty-Minute Permissions Audit

    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.

    Join the launch list →

    No spam and no sales calls — just one email when it’s live.

    Related reading

    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.

  • When the Breach Isn’t Yours

    When the Breach Isn’t Yours

    The email arrives on a Thursday morning, and the subject line is careful in a way that tells you something before you open it: An important update regarding your account.

    Your church management system — the one holding your directory, your attendance records, your kids’ check-in data, and every pledge for the last six years — has had what the letter calls a security incident. A third party accessed portions of its environment. The company is working with outside experts and law enforcement. It takes the security of your data very seriously.

    You read it twice. You didn’t click anything. Nobody on staff did anything wrong. Your passwords were fine.

    And you still have to do something about it, today, because eleven thousand names in that database belong to people who trusted your church with them.

    What the words mean, and whether the notice is real

    A breach means someone got into a system and reached information they weren’t supposed to reach. That’s all. It doesn’t necessarily mean a movie-style intrusion or a ransom note. Very often it’s a stolen password used on an ordinary login screen.

    The important part is whose system. When the breach is at a company you buy software from rather than in your own building, security people call it third-party risk — sometimes supply-chain risk. Both terms describe the same simple, uncomfortable fact: the data you’re responsible for lives on computers you don’t control, run by people you’ll never meet.

    You accepted that trade the day you stopped keeping the directory in a filing cabinet, and it was almost certainly the right trade. A cloud giving platform is more secure than a spreadsheet on the office computer, by a wide margin. But it moves the risk rather than removing it, and once every three or four years the bill for that comes due in your inbox.

    This is not hypothetical for churches. In 2020 the fundraising and donor-management company Blackbaud — which the FTC described as serving more than 45,000 organizations including nonprofits, foundations, schools, and healthcare providers — was breached by an attacker who used stolen credentials and stayed inside for three months. Tens of thousands of customer organizations were affected, and millions of individual people. Not one of them did anything to cause it.

    Which brings us to the step everybody skips. Before you act on the notice at all, confirm it’s real.

    Breach notification emails are one of the most effective phishing pretexts in existence. They arrive when you’re rattled. They carry a plausible reason to log in immediately. And they can be sent by anyone — including, routinely, by attackers who read the same news story you did and mailed a counterfeit version to every customer of the breached company they could find.

    So do not click the link in the email — not the one saying Secure your account, not the one offering credit monitoring.

    Instead, open a browser and go to the vendor the way you normally do, from your bookmark or by typing the address you already know, and log in. A real vendor in the middle of a breach response will have a notice on the dashboard, a status page, and a support article. If there’s nothing there, call the support number from your contract or a past invoice, not from the email.

    The FTC gives the same advice about any message claiming your information has been exposed: don’t use a link or a phone number from the message itself.

    What usually gets taken, and what “no financial data” actually means

    Not all exposed data is equal, and vendor notices are often written to blur that. Three broad categories:

    Contact and profile data. Names, addresses, email addresses, phone numbers, birthdays, family relationships, giving history, notes fields. This is what almost always goes, and vendors tend to describe it in the mildest available language. It is not harmless. Your member directory is a targeting list — see below.

    Passwords. The notice may say passwords were hashed. Hashing turns a password into a scrambled string that can’t be reversed directly, which is genuinely better than storing the plain text. But hashes can be attacked by guessing at industrial speed, and a short or common password will fall. Treat “hashed passwords were exposed” as “passwords were exposed, and you have some time.”

    Payment and identity data. Card numbers, bank account and routing numbers, Social Security numbers. Reputable giving platforms generally don’t hold full card numbers — they hand that to a payment processor and keep a token instead. That’s real protection, and it’s why “no card data was involved” is often true.

    Now the caution, and it comes with a documented example.

    “No financial data was affected” is not the same as “nothing was affected.” It is a statement about one category, made early, on incomplete information — and sometimes it is simply wrong.

    Blackbaud told customers in July 2020 that the attacker “did not access credit card information, bank account information, or social security numbers.” According to the FTC, the attacker had in fact taken bank account numbers and Social Security numbers. The SEC, in a separate action, found the company’s own staff learned this within days and that senior management responsible for public disclosures wasn’t told. Customers weren’t corrected until October — three months in which affected people didn’t know they had reason to watch their credit.

    The lesson isn’t that vendors lie. It’s that early breach statements are provisional. Respond to what a breach could plausibly have exposed, not to the most reassuring sentence in the notice, and read the follow-up letters instead of filing them.

    The first forty-eight hours

    Once you’ve confirmed the notice is genuine, this is the whole list.

    Change the password on that service, and stop reusing it. If the same password protects your email, your bank, or your giving platform, change it everywhere it was used. Reuse is what turns one company’s breach into your problem: attackers take the leaked list and try those pairs against every major service. That technique has a name — credential stuffing — and it only works on reused passwords.

    Turn on multi-factor authentication. This is the second step after your password: a code, a tap on your phone, a security key. Microsoft’s own research finds it blocks more than 99.2% of account compromise attacks. Turn it on for the breached service and, while you’re thinking about it, for staff email — that’s the account that unlocks everything else.

    Check for things that shouldn’t be there. In the affected system and in your email: mail rules or forwarding you didn’t create, connected or authorized apps you don’t recognize, user accounts belonging to people who left, and any API keys or integrations. Attackers who get in leave doors open behind them, and this is the step most organizations skip after resetting a password.

    Look at who still has access. A breach is a good excuse to do the review you’ve been meaning to do. Remove the volunteer from 2019. Downgrade the three people with full administrator rights who don’t need them.

    Write down what you did and when. A dated page in a notebook. If this becomes a conversation with your insurer, your board, or a lawyer, “we don’t remember exactly” is a bad answer and the notebook is a good one.

    The second wave is aimed at your people

    Here’s what gets underestimated. The most damaging consequence of a member-data breach usually isn’t the breach. It’s the phishing that comes six weeks later, built out of the details.

    Someone now knows that Helen Ortiz gives $150 on the fifteenth of the month by automatic transfer, attends the Tuesday women’s study, and has a granddaughter named Kayla. An email that uses those specifics doesn’t read like a scam. It reads like church.

    So tell your congregation something concrete, and do it before the calls start:

    Our church management provider had a security incident. Some of your contact and giving information may have been included. Because of that, expect more convincing-looking messages over the next few months. Our church will never email or text you asking for gift cards, a wire transfer, or your login details, and we will never change our giving instructions by email. If anything claiming to be from us asks for money in a new way, call the office at the number you’ve always used.

    That paragraph, in the newsletter and said out loud on a Sunday, prevents more harm than anything else on this page.

    What to ask the vendor, in writing

    Email support and keep the thread. You’re entitled to answers, and the written record matters later.

    • What specific categories of data about our organization and our members were involved?
    • Were passwords included, and were they hashed?
    • When did this happen, when was it discovered, and when were we told?
    • What has been fixed, and how do you know the attacker no longer has access?
    • Are you notifying affected individuals directly, or is that our responsibility?
    • Will you provide written notice we can share with our board and our insurer?

    That last one is not a formality. Your board will ask, and so may your insurance carrier.

    And two more for the next vendor, asked before you sign:

    “Do you support multi-factor authentication, and can we require it for every user?” Supporting it isn’t enough — you want to enforce it, including for volunteers.

    “If you have a security incident, what will you tell us, and how fast?” You’re listening for a specific commitment rather than reassurance. A vendor who has thought about this has an answer ready.

    Your own duty to notify

    This part needs care, and it needs a professional.

    Every state, plus the District of Columbia, Guam, Puerto Rico, and the Virgin Islands, has a law requiring notification when personal information is exposed. Those laws differ substantially — in what counts as covered information, in deadlines, in whether a state agency or attorney general must be told, and in what the notice has to say. Some reach nonprofits squarely; some don’t. And because your members may live in several states, more than one law can apply to a single incident.

    The general shape is this: a breach at your vendor may still create a notification obligation for you, because in most of these laws the duty follows whoever owns the relationship with the individual. The vendor may handle it. It may not. “They said they’d take care of it” is not a legal analysis.

    So do two things. Get the vendor’s position in writing, and ask a lawyer licensed in your state — one hour of somebody’s time, early. Your denomination, your insurance carrier, or your board may already have someone. This is not a place to guess, and it’s not something this article can decide for you.

    What to do this week

    Pick your two most sensitive systems — almost certainly your church management software and your giving platform. Log in to each, turn on multi-factor authentication, and look at the user list. Remove anyone who no longer serves, and reduce anyone with administrator rights who doesn’t need them.

    Then write down, on the same page as your other vendors, who to call at each company if something goes wrong.

    Twenty minutes per system, and you’ll have done more than most organizations do after an actual breach.

    MissionDefend’s free assessment covers exactly this ground — who has access to what, which accounts have a second factor, and how member data is handled — in plain English, and returns a baseline score with a ranked list of what to fix first.

    Join the launch list →

    No spam and no sales calls — just one email when it’s live.

    Related reading

    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: Federal Trade Commission, FTC says Blackbaud’s lax security allowed hacker to steal sensitive data; U.S. Securities and Exchange Commission, SEC Charges Software Company Blackbaud Inc. for Misleading Disclosures About Ransomware Attack; Federal Trade Commission, Data Breach Response: A Guide for Business; Federal Trade Commission, Did you get an email saying your personal info is for sale on the dark web?; Microsoft, mandatory multifactor authentication guidance.