There is a binder on a shelf in the church office. The spine says Information Security Policy. Someone downloaded it in 2019, printed it, added tab dividers, and put it on the shelf, where it has remained.
It is forty-one pages long. It references a Chief Information Security Officer, a quarterly vulnerability management cadence, and a data classification scheme with four tiers. The church has two full-time staff and a volunteer treasurer.
Nobody has opened it. Not once. If you asked the office administrator what the policy says about wire transfers, she would tell you honestly that she has no idea.
That binder is not neutral. It is worse than having nothing, because it lets everyone believe the question has been handled.
The forty-page policy fails for a reason that has nothing to do with its contents
The contents are usually fine. Somebody competent wrote them. The problem is structural.
A policy is not a legal artifact. It is an instruction to human beings about what to do on a Tuesday afternoon when an email arrives asking for a payment change. If the instruction is on page 27 of a document nobody has read, it does not exist. The staff member acts on instinct instead, and instinct is exactly what the attacker is designing for.
Long policies also fail in the other direction. They contain commitments the organization cannot keep — quarterly access audits, annual penetration testing, a security awareness training program — and once a policy contains one thing you obviously aren’t doing, the whole document loses its authority. People stop treating any of it as real.
A single page that six people actually follow beats a binder that nobody opens. That is the whole argument, and it holds in organizations far larger than yours.
So here is the page.
The page
Copy this. Change the bracketed parts. Do not add to it — the length is the feature.
“`
[CHURCH NAME] — INFORMATION SECURITY POLICY
Adopted by the Board on [DATE]. Next review: [DATE + 1 YEAR].
Policy owner: [NAME, ROLE].
- RESPONSIBILITY The Board is responsible for this policy. [NAME] is responsible for carrying it out and reports to the Board once a year on whether we are doing what this page says.
- MULTI-FACTOR AUTHENTICATION Multi-factor authentication is required on: church email, online banking, the giving/donation platform, the church management system, the payroll system, the website host, the domain registrar, and all social media accounts. No exceptions without written Board approval.
- VERIFYING MONEY Any request to send money, change bank details, change payroll direct deposit, or pay a new or altered invoice is verified by voice, on a phone number we already had on file — never a number supplied in the request — before the payment goes out. This applies however the request arrives, including from someone inside the organization.
- INDIVIDUAL LOGINS Every person has their own login. Logins and passwords are not shared, not with staff, not with volunteers, not with family members. Passwords are stored in the approved password manager, not on paper, in a spreadsheet, or in email.
- WHEN SOMEONE LEAVES When any staff member or volunteer stops serving in a role, their access to every account and building is removed within 14 days. [NAME] runs this from the account inventory and confirms it in writing. This applies to everyone, including clergy and Board members.
- BACKUPS Church data — financial records, member records, and documents — is backed up automatically, with at least one copy the church controls and that cannot be altered from a staff computer. Once a year we restore a real file from backup to prove the backup works, and note the date it was tested.
- IF SOMETHING LOOKS WRONG If you think you clicked a bad link, entered a password on the wrong page, sent money to the wrong place, or noticed anything unusual in an account: stop, and tell [NAME] and [BACKUP NAME] immediately, by phone. Do not wait to be sure. If money has moved, we call the bank first and report to the FBI at ic3.gov the same day.
- NO PENALTY FOR REPORTING No one will be disciplined, dismissed, or embarrassed for reporting a mistake or a suspicion, including their own mistake, and including after money has been lost. Reporting quickly is the behavior this church wants. Hiding a mistake is the only thing that gets anyone in trouble.
- REVIEW The Board reviews this policy once a year, on or before [DATE]. “`
That is the entire policy. It fits on one sheet, single-sided.
What each clause is doing, so you can defend it
Your board will ask about some of these. Here is the one-sentence answer for each.
Responsibility. A policy with no name attached is a wish; naming one person and one annual report is what turns it into something that actually happens.
Multi-factor authentication. Multi-factor authentication — MFA — is the extra step after your password: a code, a tap on your phone, a key. Microsoft’s own research finds it blocks more than 99.2% of account compromise attacks, and naming the specific systems matters because churches routinely turn it on for email and forget the giving platform, which is the one holding donor card details.
Verifying money. This is the single clause most likely to save you real money, because the fraud that actually hits churches is a convincing email asking for a payment change; a thirty-second phone call to a number you already had defeats every version of it.
Individual logins. Shared logins make it impossible to know who did what, impossible to remove one person’s access without disrupting everyone, and impossible to use MFA properly.
When someone leaves. Old accounts are the quietest risk you have — nobody is watching them, and their passwords are often years old and reused elsewhere; a defined window turns “we should get around to that” into a date. CISA’s guidance for small organizations puts it plainly: develop procedures addressing changes in user status, and eliminate shared and unused accounts.
Backups. A backup you have never restored is a theory, and the annual restore test is what converts it into a fact — this is also the clause that determines whether a ransomware incident is a bad week or an extinction event.
If something looks wrong. Most losses become large because somebody waited; naming two people and requiring a phone call removes the ambiguity about who to tell and how.
No penalty for reporting. Speed is the only thing that reliably recovers money, and speed depends entirely on whether a frightened person feels safe telling you within the hour rather than on Monday.
Review. A date on the page is what stops this becoming the 2019 binder.
Getting it adopted on a Tuesday
The mistake is presenting this as a debate. It is not a debate; it is a housekeeping item that happens to be important.
Put it on the consent agenda. Consent items are approved as a block without discussion unless a member pulls one. Circulate the page with the board packet a week ahead, with a two-sentence cover note: This replaces our existing information security policy. It is one page so that staff and volunteers will actually follow it. Most boards will pass it without comment, which is the correct outcome.
Name the owner before the meeting, not during it. An unassigned policy will sit for a year. Ask the person first, privately, so the name in the document is already agreed.
Set the review date as a real date. Not “annually.” A date, in the calendar, on the same board meeting each year.
Record it in the minutes. This is the part people skip, and it is the part that matters most beyond the security question.
Boards of nonprofit organizations carry a duty of care — the general obligation to act with the attention a reasonably prudent person would apply to the organization’s affairs. The specifics vary by state and by your governing documents, and this is not legal advice; ask your attorney what applies to you. But the general shape is consistent: what a board can demonstrate matters. A minute that reads the Board adopted the Information Security Policy, assigned responsibility to the Business Administrator, and set the annual review for the March meeting is evidence that the board considered the risk and acted. A verbal agreement that somebody should look into cybersecurity is not.
Give a copy to every person it applies to. Staff, yes — but also the volunteer who runs the website, the volunteer counting team, the person with the Facebook password. One page can be handed to someone in a hallway. Forty-one pages cannot.
Policy without practice is theatre
Here is the honest limitation. Adopting this page does not mean your church is prepared. It means your church has written down what it intends to do.
The gap between those two things is real, and it shows up under pressure. The staff member who has read clause 3 in a board packet is not the same as the staff member who has actually made the verification call once and knows it takes thirty seconds and is not awkward. The person named in clause 7 is not ready until they have said the words out loud in a room, with a scenario in front of them.
The way to close that gap is a tabletop exercise — a short, low-stakes practice run where you talk through a realistic incident around a table and find out who would actually do what. It takes under an hour and it is the subject of its own post in this series. If you adopt the policy and never practice it, you have documentation. If you adopt it and practice it once a year, you have a response.
Do the page first anyway. Documentation you follow beats intention you never wrote down.
What to do this week
Copy the page above into a document, fill in the five bracketed fields — church name, policy owner, backup contact, adoption date, review date — and email it to whoever assembles the board packet with a request to add it to the consent agenda.
Then, separately, check one thing before the meeting: whether MFA is actually turned on for the giving platform and the church management system, not just email. If it isn’t, you will want to know that before you sign a document saying it is required.
Thirty minutes, no budget, and your board has a defensible record by the end of the month.
If you would like something concrete to bring to the same board meeting, MissionDefend’s free assessment asks plain-English questions about how your organization handles email, donations, member data, and accounts, then returns a baseline score and a ranked list of what to fix first — useful as the evidence behind the annual report clause 1 asks for.
No spam and no sales calls — just one email when it’s live.
Related reading
- the twelve practices the policy is asking for
- closing accounts when a volunteer quietly drifts away
- what the reporting clause looks like in practice
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; Microsoft, mandatory multifactor authentication guidance; FBI Internet Crime Complaint Center, 2025 Internet Crime Report.
