The church needs to change a line on the website. It’s a small thing — the office hours are wrong.
Nobody knows how. The website was built and maintained by Dave, who was wonderful, who did it for eleven years, and who moved to Arizona in 2023. He never resigned. There was no last day. He came less and less, and then he was gone, and at some point somebody said “we should really get the website stuff from Dave” and nothing followed.
So this Tuesday morning there are two facts sitting side by side, and both are problems. The first is that nobody at the church can edit the website. The second is that Dave can.
And not only the website. Dave has the login for the domain registrar, an old church email account that still forwards somewhere, administrator rights on the Facebook page, and — because he set up the security cameras that one time — the code to the side door.
None of this is Dave’s fault. He has done nothing wrong and never will. That is exactly what makes it so hard to fix.
Churches are uniquely bad at this, and it isn’t carelessness
Businesses have a structure that does this work automatically. An employee resigns, HR gets a form, a last day exists on a calendar, and a checklist fires. Even a badly run company gets some of it right, because the process is attached to a date. Churches have no such date.
Volunteers do not resign. They drift. Attendance thins. A season gets busy. Someone has a baby, takes a job with different hours, has a parent who gets sick, or quietly falls out with someone and stops coming. There is no letter, no exit interview, no trigger. Six months later nobody is sure whether they’ve left or are just going through something.
And even when it is clear, nobody wants to be the one to act. Sending a message that amounts to your access has been removed to a person who gave you a decade of Saturdays feels like an accusation. It reads as we no longer trust you, in an organization whose entire currency is trust. So the message doesn’t get sent, and the account stays open, forever.
This is not a discipline failure. It is a design failure — the process assumes a trigger the organization doesn’t have. The fix isn’t more diligence from tired people; it’s a different trigger and a different framing, both of which are cheap.
And the actual risk isn’t the one people imagine. The danger is almost never that Dave turns malicious. It’s that Dave’s password was reused on a site that later got breached, or his laptop has a problem, or he passed the login to a friend who was helping, or he has genuinely forgotten he has it — so nobody is watching that account at all. Dormant accounts are the quietest doors in your building: nobody checks them, nobody notices logins, and nobody would know for weeks.
The list is longer than anyone expects
When churches finally do this, the near-universal reaction is that they had no idea how many places one person could reach. Work through this list for anyone stepping back.
Email. The account itself — but before you close it, look inside. Check for forwarding rules and filters sending copies of mail somewhere else. A forward set up years ago for a good reason keeps working long after the account is “closed,” and forwarding rules are exactly what attackers plant when they compromise a mailbox, so this check does double duty.
The church management system. Member records, contact details, pastoral notes, attendance, and often giving history. This is your most sensitive data and it’s frequently the account with the loosest access.
The giving platform. Online donations, recurring gifts, and in some configurations the ability to see or change payout accounts. Treat this like online banking, because it is.
Social media. Not just the page password — the roles. Facebook and Instagram pages are administered through individuals’ personal accounts, so removing someone means removing their personal profile from the page’s admin list. Check for admins nobody recognizes; churches routinely find some.
The website and its hosting account. Two separate things, often with two separate logins.
The domain registrar. The account that controls your church’s web address. This is the highest-consequence, lowest-visibility item on the entire list, and it’s frequently in one volunteer’s name, on their personal email, with a card that expired two years ago.
Cloud storage. Google Drive, OneDrive, Dropbox — and specifically, folders shared to a personal address. Those keep working after the church account is deleted, because the sharing was granted to the outside address, not the internal one.
The newsletter or bulk email tool. Your entire congregation’s email list lives here, plus the ability to send a message that appears to come from the church.
Online banking and cards. Viewing, transaction, and approval rights, debit cards, and any authorized-user status. Also the accountant’s portal, the payroll system, and any expense app.
Shared password vaults. If you use a password manager, remove them from the shared vault — and remember that they may have exported or memorized what was in it.
Anything the vendor controls. Your accounting software, your background check provider, your childcare check-in system, your streaming or AV platform, your Wi-Fi admin panel.
And the physical layer, which people forget because it isn’t a login: keys, fobs, alarm codes, door codes, and the safe combination. If your alarm code is the same one everybody has used since 2014, changing it after each departure is unrealistic — which is an argument for individual codes, exactly like individual logins.
Nobody remembers all of this in the moment. That’s the point of writing it down once.
The shared login problem is the real reason this never happens
Here is the honest obstacle, and it stops most churches cold.
If four people use one login for the giving platform, removing one person means changing the password for all four. That means telling three other people the new password, one of whom will be on vacation, one of whom will lock themselves out, and one of whom will write it on a sticky note.
So it doesn’t get done. Not out of laziness — out of an entirely rational assessment that the disruption exceeds the benefit. The shared password quietly converts every departure into a project, and projects that inconvenience four volunteers get postponed indefinitely.
Shared logins cause three other problems while they’re at it. You can’t tell who did what, so there’s no record when something goes wrong. You usually can’t use multi-factor authentication properly, because the second step goes to one person’s phone. And the password tends to be simple and old, because complicated passwords don’t survive being shared.
Individual logins are not a nicety. They are the thing that makes removal possible at all. Many church systems support multiple named users at no additional cost, and where they do, adding four named users and retiring the shared one is an afternoon’s work that permanently removes the biggest obstacle to everything else in this post.
CISA’s guidance for small organizations names the same targets directly: identify and deactivate unused accounts, eliminate shared accounts, and remove unnecessary privileges.
What good looks like
Five components. None require budget.
A written inventory of every account. One sheet: the system, what it’s for, who has access, who the named owner is, individual or shared. Building it takes an afternoon and it is the most valuable security document a small church can own — not only for offboarding, but for the day you need to know what an attacker could have reached.
One named person who runs offboarding. Not a committee — a person, named in your policy, who works the inventory when someone steps back and confirms in writing when it’s done.
A defined window. Fourteen days is realistic for a church. Thirty is defensible. “When we get to it” is not a window. Put the number in the policy so it’s a deadline rather than a preference.
Individual logins wherever the system allows them. As above. This is the enabling condition for everything else.
A twice-yearly review that catches the drifters. This is the piece that solves the actual problem, because it doesn’t depend on anyone declaring they’ve left. Twice a year, go down the inventory name by name asking one question: is this person still doing this job? Everyone who quietly drifted away surfaces here, with nobody having to make a judgment call in the moment. Put it on the calendar beside something you already do — the annual meeting, the budget cycle, the start of the program year.
Two additions. Do this for role changes, not just departures — the volunteer who moved from counting to hospitality doesn’t need the giving platform. And where an account can have only one owner, make sure it’s a church email address the church controls, not a personal Gmail, so a departure doesn’t take the account with it.
The graceful way to say it
The awkwardness is real and entirely solvable with framing. Make it about the process rather than the person, and say it before it applies to anyone.
Announce the practice, not the case. At a volunteer meeting or in the newsletter, once: We’ve adopted a simple practice for church accounts. Everyone who serves in a role has their own login, and when someone steps back from a role, we close out their access within two weeks. It applies to all of us, including the pastor and the board, and it’s how we take care of the information people trust us with.
Say the part about the pastor out loud, and mean it. A rule that applies to everyone is administrative; a rule that applies to some people is a judgment. When the senior pastor’s access is reviewed on the same list as the nursery volunteer’s, nobody can read the process as suspicion. Model it — review the pastor’s access first, and mention that it happened.
Front-load it. When someone takes on a role that needs an account, say it as you hand over the login: This is yours, not shared, and when you hand the role on we’ll close it out — that’s just how we run it. Said in month one, it is unremarkable. Said in month sixty, it stings.
Lead with gratitude and be concrete. The actual message, when the time comes, is short: Thank you for everything you’ve done with the website these last eleven years — it’s been a real gift to this church. As part of how we handle accounts, I’m going to close out the logins over the next couple of weeks. Could you and I get on a call for fifteen minutes so you can walk me through where everything is?
That last sentence reframes the conversation from taking something away to asking for help, which is closer to the truth. Dave doesn’t want to be the single point of failure for your website. He’d probably be relieved.
Never make it an accusation. Don’t explain the security rationale at length, don’t reference anything they did, don’t over-apologize. Brevity and warmth do the whole job.
What to do this week
Open a blank spreadsheet and give it five columns: system, what it’s for, who has access, who owns it, individual or shared. Fill in every system you can think of in twenty minutes — email, church management, giving, banking, website, domain, social media, newsletter, cloud storage, Wi-Fi, alarm.
Then take one pass down the list and mark the rows where someone has access who no longer serves in that role. Don’t fix them yet. Just mark them, and count.
That count is your honest starting position, and for most churches it’s the most surprising number they’ve seen all year. Bring it to the next board meeting with a proposed date for the first review.
Under an hour, and the problem stops being invisible.
MissionDefend’s free assessment walks through exactly this territory in plain English — who has access to what, how accounts are closed out, and how email, donations, and member data are handled — then hands back a baseline score and a ranked list of what to fix first.
No spam and no sales calls — just one email when it’s live.
Related reading
- setting an end date before the summer helper starts
- a twenty-minute pass through your member database users
- the one login five people have been using
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: Cybersecurity and Infrastructure Security Agency, Cyber Essentials Starter Kit; Cybersecurity and Infrastructure Security Agency, Cyber Essentials.