MissionDefend Blog

Home Articles Get your free assessmentComing soon

Tag: children’s ministry

  • Photos of Children on Your Website: Consent That Actually Works

    Photos of Children on Your Website: Consent That Actually Works

    Vacation Bible School wraps up on a Friday. A volunteer with a good eye has taken about two hundred photos over the week, and by Sunday afternoon forty of them are on the church Facebook page and a dozen more are on the homepage. They’re lovely pictures. Kids painting, kids laughing, the closing-night crowd shot.

    On Monday morning a mother calls the office. Her son is in the third photo in the album. She had asked, at registration, that he not be photographed. She did ask — it’s written on the form, in the box provided, and the form is in the binder where it belongs.

    Nobody did anything wrong on purpose. The form was filled out correctly and filed correctly. The volunteer holding the camera simply had no way to know.

    That’s the whole problem in one sentence, and it’s almost never a paperwork problem.

    Consent that lives in a filing cabinet is not consent that the person holding the camera can see. A signed release is necessary. It is not remotely sufficient. The failure is in the distance between the form and the moment.

    Why the form is the easy part

    Most churches have a photo release. It’s usually bundled into the registration packet, alongside the medical authorization and the emergency contacts, and most parents sign it without much thought. That’s fine — it’s the legal foundation, and you need it.

    But look at what happens after the signature. The form goes in a binder or gets scanned into a folder. The child comes to programs for the next four years. In that time, the volunteer roster turns over twice, a new children’s director arrives, VBS is run by a team of eleven people who have never seen the binder, and the church switches from Facebook to Instagram and adds a livestream.

    The consent has not moved. The organization has moved a long way.

    There’s a second issue, quieter but just as real: circumstances change. A family’s situation in September is not necessarily their situation in March. A custody arrangement changes. A parent leaves an abusive relationship. A foster placement begins. A blanket consent signed once, four years ago, does not reflect where that family is now — and no one has asked.

    What a workable system looks like

    Four pieces. None of them require software you don’t already have.

    Record the consent per child, in the check-in system. Not per family, per child — siblings can have different situations, particularly in blended and foster families. If your church management software has a custom field or a flag, use it. The point is that the answer travels with the child automatically, every time they’re checked in, without anyone consulting a binder.

    Make it visible at the moment it matters. This is the piece nearly everyone skips, and it’s the one that would have prevented the phone call on Monday morning. The volunteer with the camera needs to know without asking anyone. The common approaches: print the flag directly on the check-in label (“NO PHOTOS” in bold), or use a different colored wristband or lanyard for children who aren’t to be photographed. Whichever you choose, brief every volunteer on what it means in the first two minutes of their orientation, every time.

    A note on dignity: don’t make the flag conspicuous to the other children in a way that singles anyone out. A label detail or a wristband color that only volunteers understand does the job. A child should never have to explain why they’re wearing the different color.

    Refresh it annually. Once a year, at registration or the start of the program year, ask again. One line: has anything changed about photo permission for your child? This catches the situations that have shifted and costs nothing.

    Name one person who reviews before anything is published. Not a committee. One person — usually the children’s director or the communications volunteer — who looks at every photo before it goes on the website, the social account, the newsletter, or the annual report. They’re checking two things: is every child in this frame cleared, and does this image follow the publishing rules below. A single named reviewer is the difference between a policy and an intention.

    Publishing rules worth writing down

    These apply to every child, including ones with full consent on file.

    No full name next to a face. First names only in captions, and preferably not even that for identifiable close-ups. A photograph plus a full name is a substantially different piece of information than a photograph.

    Nothing that identifies where a child will be, and when. No school names or logos, no jersey numbers with a team name, no captions like “the Wednesday 5:30 group.” The concern isn’t the single photo — it’s the combination. A face, a first name, a school, and a weekly schedule is a complete picture for someone with bad intent.

    Be careful with anything that reveals a routine. A recurring photo of the same child in the same place at the same time each week is a pattern. The single crowd shot from the picnic is not.

    Prefer wide shots and activity shots. A room full of children painting communicates the ministry just as well as a close-up portrait, and carries far less risk.

    Handle foster, adoptive, and custody situations separately and seriously. For some children, a published photograph is not a privacy preference — it is a safety issue. A child in foster care may have a biological parent who is not permitted contact. A family may have relocated to get away from someone. A protective order may be in place. In these cases the answer is simply no photos, no exceptions, and the flag in the check-in system should say so without explaining why. The reason is nobody’s business but the family’s, and the fewer volunteers who know the circumstances, the better.

    Make it easy for a parent to say no without a conversation. Some families cannot explain their situation to a church volunteer at a check-in desk. A checkbox they can tick in private is a kindness.

    The data hidden inside the picture file

    Here is the technical piece, and it’s simpler than it sounds.

    EXIF — short for exchangeable image file format — is a block of information the camera writes inside the image file itself. It records the date and time, the camera model, the settings, and, if location services were on, the GPS coordinates of where the picture was taken. The National Security Agency’s guidance on location exposure states it plainly: pictures posted on social media may have location data stored in hidden metadata.

    For a photo taken in the church building, the coordinates are your own address, which is already public. The risk shows up elsewhere: the youth retreat at a cabin, the small group meeting at a family’s house, the photo a volunteer took at a child’s home during a pastoral visit. Those coordinates are a home address, embedded in a file you published.

    Three things to do about it, in order of how much effort they take:

    Turn location off in the camera app on the phones used for ministry photography. On both iPhone and Android this is a per-app permission for the camera. Thirty seconds, and it solves the problem at the source.

    Don’t assume the platform handles it for you. Some social networks process images on upload in ways that discard the metadata; others don’t, and their behavior changes without announcement. Your own website is the bigger concern regardless — on WordPress and most similar platforms, the original file you upload is stored on the server and is often the one served, metadata and all.

    Check one file to see where you stand. Right-click an image on a Windows PC and choose Properties, then Details; on a Mac, open it in Preview and choose Tools, then Show Inspector, and look for a GPS tab. If you see coordinates, your images carry them. Many website platforms have a free plugin that strips metadata on upload; ask whoever manages your site to add one.

    When someone asks you to take a photo down

    Treat this as a normal, expected request, not a complaint. Say yes, do it quickly, and don’t ask for a reason. Someone asking may be in a situation they cannot describe.

    Remove the original first. Take it off the page, the album, the gallery, the newsletter archive, and the livestream recording if the child appears in it. Removing it from the website while it stays on Facebook accomplishes nothing.

    Then deal with the copies. This is the part people don’t anticipate. A published image can persist in a search engine’s cache and in the image results for a while after the original is gone. If the page is yours, Google’s Search Console has a removals tool that lets a verified site owner request temporary suppression and speeds up the refresh. If the image is on a page you don’t control — a partner ministry’s site, a community news roundup — Google publishes a Refresh Outdated Content tool specifically for people who don’t own the page, which works once the content has actually been removed at the source. Both are free.

    Be honest about the limits. Anything that was public may have been downloaded or reshared, and you cannot recall that. Say so plainly and kindly. What you can promise is that it’s gone from everywhere you control, promptly, and that the child’s record is updated so it doesn’t happen again.

    Update the flag. A removal request is a consent change. Record it in the check-in system the same day, or you will have this conversation twice.

    Get it in front of your insurer and your lawyer

    Consent requirements for photographs of minors are not uniform. They vary by state, and your denomination or insurer may impose additional standards that are stricter than state law. Some liability policies and child-protection programs have specific requirements about media releases and how they’re documented.

    Write your policy first — it’s a one-page document — then send it to two people: your attorney, and whoever handles your liability insurance. Ask them plainly whether your release form and your process meet what they expect. This article describes the general shape of the problem and is not legal advice; the specifics belong to someone licensed to give them.

    While you’re at it, ask about your background check and volunteer screening records too. They live in the same binder and raise the same retention questions.

    What to do this week

    Open your check-in system and find out whether it can hold a per-child photo permission flag that prints on the label. Most can. If yours can, turn it on and spend twenty minutes entering what you already have on file. If it can’t, buy a pack of colored wristbands and write the rule on an index card taped to the check-in desk.

    Then name your reviewer — one person, by name, who sees every photo before it’s published — and tell them.

    That’s under an hour, and it closes the gap between the form and the camera.

    Photos are one category among several worth a second look. MissionDefend’s free assessment walks through how your organization handles member data, children’s information, email, and donations in plain English, and hands back 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: National Security Agency, Limiting Location Data Exposure; Google, Refresh Outdated Content tool; Google, Removals and SafeSearch reports tool.

  • Summer Volunteers, Permanent Access

    Summer Volunteers, Permanent Access

    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.

    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, Protecting Personal Information: A Guide for Business; Microsoft, mandatory multifactor authentication guidance.