It’s the second Monday in June and the hallway outside the fellowship hall has been turned into a check-in station. There’s a folding table, a laminated sign, a bin of name tags, and a tablet on a stand.
Behind the table is a seventeen-year-old who is wonderful with children and has never used the check-in system before. Someone shows her how it works in about ninety seconds. She taps in as VBS, because that’s the login on the sticky note attached to the tablet stand, and for the next five days she checks in a hundred and forty children — with their parents’ phone numbers, their allergies, their medications, and the notes about which adult is and isn’t allowed to collect them.
In August she leaves for college.
In September, nobody does anything. The VBS login still works. It will still work next June, and the June after that, and the sticky note is still on the stand.
This isn’t a story about a bad volunteer. She was excellent, and the church was lucky to have her. It’s a story about a pattern that almost every church repeats every summer without noticing: the people with the least training and the shortest tenure are handed access to the most sensitive information the organization holds, and nobody ever takes it back.
The summer problem, stated plainly
Vacation Bible School, day camp, sports camps, mission trips, summer interns, the youth trip. For six to ten weeks, a church’s headcount of people-with-access can double.
They need real access — this isn’t a case where you can hand out nothing. The check-in table needs the check-in system. The registration volunteer needs the registration data. The intern posting daily photos needs the social accounts. The trip coordinator sometimes needs a card to buy fuel and groceries in another state.
And three things are true of this group at the same time:
Highest turnover. Many of them serve for one week and are never in the building again in that capacity. Some are students who leave in a fixed month.
Lowest training. They are recruited late, briefed quickly, and often start on the first morning. Nobody schedules an orientation for a person doing one week of a volunteer job.
Most sensitive data. Children’s names, ages, photographs, allergies, medical notes, emergency contacts, home addresses, and — in some systems — custody restrictions. There is nothing else in a church’s records more sensitive than that.
Any two of those would be worth attention. All three, every summer, on a shared login, is the thing to fix — and it is genuinely fixable. This is not a technology problem; it’s a pattern that someone has to own.
Named accounts, with an end date decided first
Start here; everything else depends on it.
A shared login costs you the same four things it costs on a shared office computer: nobody can tell who did what, one leaked password exposes everything, the password never changes because changing it means telling forty people, and every volunteer who ever served still has it.
There’s a particular version of that for children’s ministry. If a parent raises a concern about how a check-out was handled, or a record was changed, or a photo was posted, a shared login means nobody can establish what happened. That protects nobody — least of all the volunteers, who all become equally unaccountable and therefore equally unclearable.
Give each summer volunteer their own account, under their own name. Most church management and check-in systems allow unlimited or generous numbers of users, and the ones that charge per user often have a volunteer or limited role at a lower cost or none. Ask your vendor before assuming every extra person is a paid seat.
If your system genuinely cannot do named volunteer accounts, write that down as a known limitation and raise it at renewal.
The second half of the pattern is almost embarrassingly simple:
Nobody gets access without a written end date, and the end date is written down before the access is granted.
Not “we’ll remove it when they’re done.” That sentence has never once resulted in access being removed. A date. On a list. In the calendar.
A one-page grid is all you need — a spreadsheet, a shared doc, a printed sheet in a binder. Five columns:
Name · What they can get into · Start date · End date · Removed (initials and date)
That’s the whole system. It converts a vague intention into a specific task with a name attached, and it gives you something to hand to an insurer or a board member who asks a fair question.
Add one calendar entry — mid-September, titled Remove summer access, assigned to a specific person — and this problem is structurally solved for as long as somebody keeps doing it.
The minimum permissions for the job
The FTC’s guidance for businesses puts it as the principle of least privilege: each person should have access only to what they need to do their particular job. In a church that translates into a few concrete decisions.
The check-in volunteer needs to check children in and out. She does not need to edit family records, view giving history, export the directory, or see the full membership database. Most check-in systems have a limited role for exactly this; find it and use it.
The registration volunteer needs this summer’s registrations. Not the historical file, not the donor records.
The intern posting photos needs to post. Most social platforms let you grant a person permission to publish without giving them the ability to change the password, remove other administrators, or delete the account. Use that level — and never hand over the account password itself.
Almost nobody needs a payment card. If a trip leader genuinely does, a dedicated card with a low limit that gets canceled at the end of the trip is far better than a card tied to the operating account. Ask your bank about a virtual or single-use card.
Two more, a minute each. Turn on multi-factor authentication — the extra code or tap after a password — for any volunteer account that can reach children’s data or money. Microsoft’s research finds it blocks more than 99.2% of account compromise attacks, and it is just as free for a volunteer as for the pastor. And remove the shared passwords from sticky notes on tablet stands; a printed card kept behind the table, changed after the season, is already an improvement.
Fifteen minutes of orientation, and only three things in it
You will not get a training session. You’ll get the first five minutes of the first morning, standing at a folding table. So decide in advance what the three things are.
One: this data is not yours to share. Names, allergies, custody notes, and phone numbers stay in the system and in this building. Not screenshotted, not texted to a co-leader, not typed into a personal spreadsheet, not posted anywhere. “If you find yourself about to photograph the screen, stop and ask me instead.”
Two: check-out is a security function, not a formality. The person collecting a child is matched to the record every time — when you know them, when there’s a line, when they’re annoyed about it. Custody restrictions are the reason the system exists. A volunteer told this once will hold the line; a volunteer who hasn’t will assume the tags are bureaucracy.
Three: if anything seems wrong, tell this person. Point at a specific human being. An email that looks odd, a parent who seems agitated, a stranger in the hallway, a screen that logged you into somebody else’s account. Nobody is ever in trouble for asking.
Then one line about photographs, because summer is when the photo problem happens: know which children have a photo restriction on file, and know that a group of happy kids is not a reason to skip checking. Photo consent deserves its own conversation with your leadership — who may photograph, what may be published where, and how a family opts out — and the summer programs are exactly when a vague policy gets tested.
The phone in their pocket
Here’s the modern wrinkle. Many check-in and ministry apps run on personal phones, and a volunteer installing the app on her own device is often the fastest way to get the table staffed.
That’s a reasonable trade, but be clear-eyed: church data is now on a phone the church doesn’t control, that gets handed to a younger sibling, that may have no screen lock, and that will be traded in eventually.
Three things make it acceptable:
Say plainly that the app must be signed out of and deleted when the season ends — and put that on the same one-page grid, with a tick box, so it’s a task rather than a hope.
Ask for a screen lock and current updates on any phone used for ministry data. That’s not intrusive; it’s the same thing the volunteer’s bank asks of them.
Prefer a church-owned tablet where you can. One inexpensive tablet in a stand that never leaves the building removes almost all of this, and it’s a strong candidate if you’re buying one device this year.
And when a volunteer’s access ends, remember that removing their account in the system is what actually matters — an app left on a phone with no working login is just an icon.
September, and how to say it without awkwardness
Put the calendar entry in now, whatever month you’re reading this in. Mid-September, one person, thirty minutes:
Work down the grid and remove every access whose end date has passed. Initial the last column.
Check each system’s user list separately — check-in, church management, email, the giving platform, the shared drive, the social accounts, the photo library. People collect access in places the grid doesn’t know about.
Look specifically at the social accounts. They’re the most often forgotten, and the most public when it goes wrong.
Change any password that was shared during the season, and any that was on a card at a table.
Then tell the volunteers you did it, in the thank-you note — which brings us to the one thing that actually stops churches from doing any of this.
It isn’t ignorance. It’s that removing someone’s access feels like an accusation, and in a community built on trust, accusing a faithful volunteer of anything is unthinkable.
So take the implication away by saying it before it can be inferred, at the start rather than the end:
“Your access runs through the last week of August. That’s how we do it for everyone, including the pastor’s family. It’s not about trust — it’s that we keep the children’s information locked down to whoever is actually serving right now.”
Nobody has ever been offended by that. What people are offended by is being singled out, and a policy applied to everybody singles out nobody.
A church that can say we give named accounts, limited to the role, for a fixed period, and we remove them in September is a church that can answer questions from parents, insurers, and its own board with something better than reassurance. A two-week volunteer with a two-week account is not distrust. It’s ordinary practice, and it protects the volunteer as much as the child.
What to do this week
Open the user list for whichever system holds your children’s check-in data and read it top to bottom. Look for names you don’t recognize, accounts called things like VBS or Camp or Front Desk, and people who left. That takes fifteen minutes, and it is usually a surprising fifteen minutes.
Then make the grid — name, access, start, end, removed — even if the only thing on it today is next summer. And put one entry in the church calendar for mid-September with somebody’s name on it.
Seasonal access is one strand of a larger question about who can reach what. MissionDefend’s free assessment asks plain-English questions about how your organization handles email, donations, member data, and accounts — including who has access to what, and who removes it — then returns a baseline score with a ranked list of what to fix first.
No spam and no sales calls — just one email when it’s live.
Related reading
- the full list of accounts to close afterward
- the photo rules those same volunteers need explained
- granting only the permissions this month’s job needs
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, Protecting Personal Information: A Guide for Business; Microsoft, mandatory multifactor authentication guidance.