A church directory usually starts small and reasonable: names, households, phone numbers, maybe a photo. Then someone adds a column because it was convenient at the time — a note about a surgery, a flag for a custody situation, a running total of what a family gives. None of it was meant to leave the office. Then the directory gets printed for a welcome team, or exported for a mail merge, and the column comes along for the ride.
Nobody decided to expose a member's medical history to forty greeters. It just wasn't decided not to. That is the pattern behind almost every privacy mistake in a small church: not malice, just a field that should never have been on a shared page in the first place. Here is what to keep off the directory, off the printout, and off the group text — and where it belongs instead.
Medical information does not belong in a shared record
A diagnosis, a surgery date, a mental health struggle, an addiction in recovery — these are among the most sensitive things a person will ever tell a church, usually in confidence, to a pastor or a care team member they trust. The moment that detail sits in the same table a volunteer opens to check a phone number, it stops being confidential. It is now one export away from a printed sheet on a table in the fellowship hall.
Medical detail belongs in a narrow, separate space that only the people actively carrying a case can open — a pastoral care record, not a directory field. The person's name can still appear on the general roster. The reason someone is praying for them should not.
Family and household conflict is not directory material
Custody arrangements, a pending divorce, an estranged adult child, a restraining order — a church often learns these things before almost anyone else does, because people trust their congregation with what they will not tell a coworker. That trust is the whole relationship. It survives only if the information stays where it was given, not where it is easiest to store.
This gets harder once you decide how to structure families in the first place, since a household record can quietly imply things about who lives with whom. The trade-offs are worth thinking through deliberately, covered in households versus individuals. Whichever structure you pick, a sensitive family situation should live as a private note attached to a case, visible to the two or three people handling it, not as a field anyone browsing the directory can see.
Giving amounts are more sensitive than most churches treat them
A person's giving history feels like it should be neutral financial data, but in practice it reads as a verdict — on generosity, on faith, on how much someone values the church relative to their neighbor in the next pew. A shared spreadsheet that shows who gave what, even shared with good intentions among the finance team, is one forwarded email away from being shared with people who were never supposed to see it.
Keep giving detail down to the smallest group of people whose job actually requires it — usually a treasurer and whoever prepares statements — and keep it out of any document built for another audience. A small group leader's roster does not need a giving column. Neither does a volunteer sign-up sheet. More on handling this well is in tracking giving that respects the giver.
Contact details for people who asked not to be listed
Some members, for real reasons — a safety concern, a private person who does not want their number circulating, someone leaving a difficult marriage — will ask not to appear in a printed or shared directory at all. This is easy to lose track of because it is an exception, not a field, and exceptions get forgotten the next time someone exports the whole list for a mailing.
If a member has asked to be left off a shared document, that request needs to survive every future export, not just the one it was made about. The safest habit is to treat every export as starting from scratch: decide again, each time, who actually needs to see it, rather than assuming last year's list was already filtered correctly.
It helps to write the exception down somewhere durable rather than relying on the person who took the original request to remember it forever. A short note attached to that person's record — do not include in shared directories — travels with them even after the staff member who heard the original request has moved on. Without that, the request lives in one memory, and memories are exactly what a busy office loses first.
Background-check status is not a badge to hand out
Serving teams carry their own quiet privacy problem. A background check result, a flag that someone's screening expired, a note that a check came back with something the team lead needs to discuss — all of it needs to reach the person responsible for scheduling that ministry, and almost nobody else. It is easy to justify wider visibility as a safety measure, but broadcasting the existence of a flag is not the same thing as keeping children or vulnerable adults safe. The safety comes from someone acting on the flag, not from everyone knowing it exists.
Keep that status visible to whoever schedules the team it applies to, plus whoever owns your screening policy, and treat it the same way you would treat a medical note: relevant to a specific decision, not general knowledge. A volunteer roster printed for a Sunday morning does not need a screening column any more than it needs a giving column.
What a directory export should actually contain
A directory built to be shared — with a welcome team, a small group leader, a new member class — should carry the smallest set of fields that lets people do their job: name, household, maybe a phone number and an address. It should never be the same file as the one that holds pastoral notes or giving totals, even if both live in the same piece of software. The discipline is not in the software preventing the mistake; it is in building the habit of exporting only what the specific job in front of you requires, every time, rather than reaching for whatever export is fastest.
SundayBridge keeps pastoral care in its own space — cases with comments and history, separate from the general directory — so a giving total or a care note is never sitting in the same table a volunteer opens to check an address. The directory's CSV export pulls contact and household fields, not care history or individual giving records, which keeps a routine export from accidentally becoming a leak.
The printout is where most leaks actually happen
Screens have some natural friction: a login, a permission, a second thought. Paper has none. A printed roster left on a table, photographed by mistake, or handed to the wrong volunteer travels further and lasts longer than almost any digital mistake, because nobody logs who picked it up or where it went. If your church still relies on printed rosters for weekly ministry — and most do, for at least a welcome team or a Sunday school class — treat every one of them as a document that will eventually be lost, and print accordingly. Names and numbers, not notes and totals.
The same caution applies to how records are kept current in the first place. A record that gets cleaned up on a predictable rhythm — covered in cleaning up a messy church database — is also a record where it is easier to notice a field that never should have been added, before it ends up on a hundred printed pages.
Deciding this once, on purpose, beats deciding it every export
The churches that avoid this problem are not the ones with the strictest software. They are the ones who sat down once and wrote a short, plain answer to a simple question: which fields never leave the office, no matter who is asking or how convenient it would be. Medical notes, family conflict, giving amounts, and any explicit opt-out request go on that list. Everything else can be shared with the judgment a small church has always used — carefully, and with the people who actually need it.
Write the list down. Tell the people who build the exports and print the rosters what is on it. A rule that lives only in one person's head disappears the week that person is out sick, and that is exactly the week the wrong file gets printed.