Overview

Nonprofits sit in a paradoxical security position. The data you steward is exquisitely sensitive: home addresses of major donors, medical conditions disclosed during intake, immigration status of clients, custody arrangements of children in your programs, financial records of board members, and personally identifiable information of thousands of supporters. Yet your IT budget is often a single line item in the operations column, your security staffing is frequently zero, and your culture prizes openness, mutual trust, and rapid sharing of information across volunteers, contractors, and partner agencies. Adversaries know this. Phishing kits and ransomware-as-a-service marketplaces explicitly target the .org domain because the combination of valuable data, weak controls, low tolerance for downtime, and limited legal sophistication produces a high probability of successful extortion or data resale.

The losses from a breach are rarely covered by general liability insurance and almost never by a small reserve fund. A typical mid-sized nonprofit incident—roughly five thousand records exposed—will produce forensic investigation fees in the tens of thousands, mandatory credit monitoring obligations under most state breach notification statutes, regulator response time, board legal counsel, and an immediate, measurable drop in donor retention as supporters question whether their information remains safe. Foundations writing your next grant will request your incident report. Major donors will pause until they see your remediation plan. Your earned-media position erodes as journalists pick up the breach notification you are statutorily required to file.

The good news embedded in this gloomy picture is that ninety-five percent of attacks against nonprofit organizations exploit a small handful of well-known weaknesses: reused passwords, missing multi-factor authentication, unpatched software, untrained users clicking on phishing links, weak vendor controls, and absent backups. The defensive posture you need to neutralize those attacks is neither expensive nor exotic. It is a disciplined checklist, executed consistently, reviewed quarterly, and embedded into your hiring, offboarding, and vendor procurement processes. This lesson lays out that checklist in twelve concrete items, sequences them across a six-month implementation roadmap, identifies the specific moments where you should hire outside expertise, and answers the questions board members and auditors are most likely to ask. By the end, you should be able to walk into a board meeting, present the current state of each control, and identify the next investment that produces the most risk reduction per dollar.

The Reality of Nonprofit Cybersecurity

Most nonprofit boards begin cybersecurity conversations by imagining sophisticated attackers with custom malware and zero-day exploits. The reality is mundane and almost insulting. The overwhelming majority of incidents start with one of three predictable failures, each of which has been discussed in security literature for at least fifteen years and each of which can be neutralized with controls that cost less than a single fundraising event.

The first failure is credential reuse. A volunteer or staff member uses the same password across personal and organizational accounts. A consumer service the volunteer uses—a fitness app, a forum, a retailer—suffers a breach. Their email address and password hash appears in a credential-stuffing list traded among criminals. Automated tools then test that combination against the login pages of every common nonprofit platform: Google Workspace, Microsoft 365, Salesforce, QuickBooks, Mailchimp, your CRM. The attacker does not need to know who you are; they simply harvest whatever access the credentials open. Once inside, they pivot to your donor records, financial systems, or email, and either exfiltrate data, set up business email compromise, or deploy ransomware.

The second failure is phishing. A staff member receives an email that appears to come from the executive director, a board chair, or a known vendor. The email asks them to click a link, log in to a fake portal, or wire funds to a new account. The attacker may have been reading email for weeks before the request, learning the cadence of your finance cycle, the names of grant managers, and the tone of internal communication. When the message arrives, it sounds authentic. The recipient acts on it. The cost is anywhere from a single fraudulent wire to a complete domain takeover.

The third failure is ransomware. An employee opens an attachment from a phishing message or visits a compromised website. Malware installs silently, escalates privileges, scans the network, encrypts every file it can reach, deletes online backups, and presents a ransom note demanding payment in cryptocurrency. Without offline backups, you face an impossible choice: pay criminals (often funding sanctioned entities and risking legal consequences) or lose months of donor records, program data, financial files, and operational continuity.

These three failure modes share a common defensive answer: discipline applied to fundamentals. You do not need a security operations center. You need a checklist, executed every day, by every person, with periodic verification.

The Essential Checklist: 12 Things You Must Do

1. Require Strong Passwords (or Passphrases)

Password policies have evolved sharply since 2017, when the National Institute of Standards and Technology revised its guidance to deprecate forced rotations and arbitrary complexity rules. The modern best practice is length over complexity. A passphrase composed of four to six unrelated common words—"correct horse battery staple"—provides far more entropy than the typical eight-character password with substitutions, and humans actually remember it. Set a minimum of twelve characters across the organization, allow up to sixty-four, accept all printable ASCII including spaces, and stop forcing routine resets. Forced rotation produces predictable variants (Spring2026!, Summer2026!) and pushes users toward sticky notes.

The single most consequential decision is whether to deploy a password manager. Bitwarden, 1Password, and Dashlane all offer nonprofit pricing and free or discounted plans through TechSoup. A password manager removes the human limitation: each account gets a unique sixty-character random string, the user remembers one master passphrase, and the manager handles autofill, secure sharing among teams, and offboarding when staff depart. Without a manager, password reuse is statistically inevitable. With one, it becomes architecturally impossible. The audit you should run this quarter: pull the list of every system holding donor data, identify which accept passphrases of at least sixteen characters, and document whether each user has a manager profile.

2. Enable Multi-Factor Authentication (MFA)

Multi-factor authentication is the single highest-return security control you can deploy. Microsoft and Google both publish data showing that MFA blocks more than ninety-nine percent of automated credential attacks. Even when an attacker has a valid username and password from a credential stuffing list, the second factor stops them at the door.

Not all factors are equal. SMS-based codes are better than nothing but vulnerable to SIM-swap attacks against high-value accounts (your executive director, your finance lead). Time-based one-time password apps such as Google Authenticator, Authy, or Microsoft Authenticator are stronger and free. Hardware security keys following the FIDO2 standard—YubiKey, Google Titan—are the strongest option, immune to phishing because the key cryptographically verifies the actual domain. For a small nonprofit, the practical recommendation is: require app-based MFA for all staff on every system that supports it, and issue hardware keys to the executive director, finance director, IT lead, and anyone with administrative access to your donor database or banking platform. Document recovery procedures: what happens if a key is lost or a phone is destroyed. Maintain backup codes in your password manager.

3. Keep Systems Patched and Updated

The vast majority of malware exploits vulnerabilities for which patches have existed for months or years. The Equifax breach exploited a flaw patched two months before the incident. The WannaCry ransomware that crippled the National Health Service in 2017 used a Microsoft vulnerability patched two months earlier. Patching is not glamorous, but it is the difference between resilience and disaster.

For workstations and laptops, enable automatic updates and verify on a quarterly schedule that they are actually applying. Windows machines should run the latest supported version, with Tuesday-afternoon-of-the-month updates installed within seven days. macOS machines should similarly auto-update. Mobile phones used for organizational email or two-factor codes should be on supported operating system versions; retire devices that no longer receive updates. For servers, web applications, and any custom software, designate an owner, subscribe to vendor security advisories, and patch within thirty days of release for high-severity issues, fourteen days for critical ones. Anything older than that constitutes an audit finding.

4. Backup Your Data (Regularly, Offline)

Backups are the difference between a ransomware incident that costs you a week and one that costs you the organization. The traditional 3-2-1 rule remains correct: three copies of the data, on two different media, with one copy offline or otherwise immutable. For most nonprofits this translates to: live data in your operational systems; continuous cloud backup through a service like Backblaze, IDrive, or AWS Backup; and a monthly snapshot to an external drive that is physically disconnected and stored at a board member's home, a safety deposit box, or a fire-rated safe.

The control that most organizations skip and most regret is restoration testing. A backup that has never been restored is a hypothesis, not a recovery plan. Schedule a quarterly drill: pick a representative subset of files, attempt to restore them to a separate machine, time the process, and document what worked. Pay particular attention to applications with proprietary formats (your CRM, your accounting system) where simply restoring files is insufficient because you also need the database structure, the configuration, and the integrations. When you test, you discover that your backup excluded a critical folder, that your retention policy purged the version you need, or that your encryption keys are stored only on the laptop you are trying to recover. Better to find out during a drill than during a crisis.

5. Monitor for Breaches

Most data breaches at small nonprofits are not discovered through internal monitoring; they are discovered when a journalist calls, when a donor reports a fraudulent charge, or when stolen records appear on a forum. You can shorten that detection window with a handful of free or low-cost monitoring tools.

Subscribe every organizational email address to Have I Been Pwned, the free breach notification service operated by security researcher Troy Hunt. When credentials associated with your domain appear in a public breach corpus, you will receive an alert and can force a password reset before attackers exploit them. For your most sensitive accounts, configure login alerts so that any new device or new geographic location triggers an email. Review your CRM and email administration logs monthly: look for impossible travel (a login from your office at 9:00 a.m. and from another country at 9:30), bulk record exports outside business hours, and creation of new administrator accounts. Document a written process for what to do when an alert fires, including who is notified, what evidence is preserved, and when external counsel is engaged.

6. Secure Email

Email remains the single largest attack surface for any organization. Phishing, business email compromise, and malicious attachments all arrive through the inbox. The defenses fall into three layers: technical controls that filter and authenticate messages, configuration choices that harden your domain, and user training that catches what technology misses.

Technical controls begin with your email provider. Google Workspace and Microsoft 365 both include solid spam, malware, and phishing filtering at standard tiers, with significantly better detection at the higher tiers (Workspace Business Plus, Microsoft Defender for Office 365). For most nonprofits these are sufficient. If you operate your own mail server—do not, but if you must—you need a third-party gateway such as Proofpoint or Mimecast. Configuration includes implementing SPF, DKIM, and DMARC records to prevent attackers from spoofing your domain. A correctly published DMARC policy with reject mode means that messages claiming to come from your domain but failing authentication are dropped before they reach a recipient anywhere in the world. This protects not only your staff but your donors, who would otherwise receive convincing impersonation messages.

7. Implement Access Controls

The principle of least privilege says that each person should have access only to the systems and records required for their role, and that access should be revoked immediately when the role ends. In practice, nonprofits accumulate access over time. Volunteers who helped with a one-time event still have CRM logins three years later. Former board members retain admin access to the donation platform. Interns received account credentials that were never deleted.

Run an access review every six months. For each system holding donor data, financial information, or program records, export the user list. For each user, confirm that they are still active in the role that justified the access. Remove anyone who left, anyone whose role changed, and anyone whose access exceeds what their current role requires. Document the review. Tie offboarding to your HR process: the day someone departs, their accounts are disabled across every system, their MFA tokens are revoked, and their access to shared drives is removed. The single biggest source of ex-employee data theft is credentials that were never disabled.

8. Monitor for Unusual Activity

Logging is built into nearly every modern system, yet most nonprofits never review the logs. A meaningful monitoring practice does not require a security operations center; it requires a quarterly hour spent looking at the events that already exist. For your CRM, your email administration console, your accounting system, and your donation platform, identify the audit log location and read the last ninety days. You are looking for anomalies: failed logins followed by successful ones, mass exports of records, creation of administrator accounts, changes to security settings, and logins from unexpected geographies.

Where the platform supports it, enable real-time alerts on the highest-risk events. Most major platforms now allow you to receive an email when an administrator role is granted, when bulk data is exported, or when MFA is disabled on an account. Subscribe these alerts to a dedicated mailbox monitored by your IT lead and a backup. Establish what "normal" looks like in your environment so that abnormal stands out. Document baseline activity volumes during your quarterly review so that next quarter you can compare.

9. Use Encrypted Connections

Encryption protects data both in transit (while traveling between systems) and at rest (while stored on disk). For most nonprofits, the practical decisions are about transit. Every system you operate or use should require HTTPS; if a vendor still serves login pages over plain HTTP, replace the vendor. Your own website should use a TLS certificate, available free from Let's Encrypt, with HSTS enabled to force browsers to use the encrypted version even when users mistype.

When staff work remotely, especially over public or untrusted networks, use a virtual private network or, increasingly, a zero-trust network access tool. Modern alternatives such as Tailscale and Cloudflare Access provide identity-based access to internal resources without the operational cost of a traditional VPN. For sensitive data sent by email—donor health information, legal documents—use an encrypted file-sharing tool rather than attachments, or require recipients to authenticate before downloading. Encryption at rest should be enabled on all laptops via FileVault on macOS or BitLocker on Windows, on all phones via the platform's default encryption, and within your cloud storage tier where it is typically on by default.

10. Secure Vendor Relationships

Your security perimeter is only as strong as your weakest vendor. Every cloud platform, every consultant, every contractor with login credentials becomes part of your attack surface. The 2020 SolarWinds incident demonstrated at scale what nonprofits experience repeatedly at small scale: a vendor compromise becomes your compromise.

Establish a vendor security review as part of procurement. Before signing a contract, send a short questionnaire: Do you carry cyber liability insurance, and at what limit? Where is data stored, and is it encrypted at rest and in transit? Do you hold SOC 2 Type II or ISO 27001 certification, and may we see the most recent report under NDA? What is your breach notification commitment, and how quickly will you inform us? Who has access to our data, and how is that access reviewed? For high-risk vendors—those holding donor financial information, client medical data, or administrative access to your systems—require a written data processing agreement that specifies retention, deletion, and breach notification obligations. Maintain a vendor inventory with renewal dates and the date of the most recent security review.

11. Have an Incident Response Plan

An incident response plan is not a binder; it is a one-page document that anyone in the organization can act on at three in the morning. It identifies who is on the response team, with home phone numbers. It lists the first three actions: contain the affected system, preserve evidence, and notify the executive director and board chair. It names your cyber liability insurer with the policy number and the twenty-four-hour claims hotline. It identifies external counsel with breach experience. It lists your forensic provider, even if you have only spoken to them once. It identifies regulators that may need notification—state attorneys general, the IRS in cases involving tax records, HHS for protected health information—and gives the statutory deadlines.

Tabletop the plan annually. Gather the response team, present a fictional scenario ("a finance staffer just told you they wired forty thousand dollars based on an email from the executive director"), and walk through the first six hours. The exercise reveals every gap—the missing phone number, the unclear authority to disconnect a system, the assumption that someone else was monitoring email. Update the plan based on what you learn. The cost of the exercise is half a day; the value is enormous when the actual incident arrives, because muscle memory replaces panic.

12. Train Your Staff

Technology stops the easy attacks. People stop the rest. Every staff member, volunteer with system access, and board member needs annual security awareness training and ongoing reinforcement. The training does not need to be expensive; KnowBe4, Curricula, and Hoxhunt all offer nonprofit pricing, and TechSoup carries discounted plans. The content should cover phishing recognition, password and MFA practices, safe handling of donor data, mobile device security, social engineering by phone, and the specific reporting path inside your organization when something looks wrong.

The single most effective reinforcement technique is phishing simulation. Once a quarter, send a simulated phishing email to every account, measure who clicked, and provide a brief just-in-time training to those who did. The click rate will start uncomfortably high—twenty to thirty percent in many nonprofits—and decline steadily as people become accustomed to questioning unexpected requests. The goal is not punishment; it is calibration. Treat clicks as data, celebrate reports, and publicly thank the staff member who first identifies a real phishing attempt. Culture beats policy.

Implementation Roadmap

A twelve-item checklist can feel overwhelming when delivered all at once. Sequence the work across six months and the project becomes manageable, with measurable progress reportable to the board at each milestone.

Month one targets the two highest-leverage controls: passwords and multi-factor authentication. Deploy a password manager organization-wide, run a one-hour onboarding session for staff, and turn on MFA across every system that supports it, starting with email, the donor database, banking, and the donation platform. By the end of the month, every staff member should be operating from the password manager and authenticating with a second factor. This single month neutralizes the largest category of attack against nonprofits.

Month two addresses backups and patching. Confirm that automatic updates are enabled on every workstation, document the update cadence for servers and applications, and establish a written backup configuration that satisfies the 3-2-1 rule. Schedule the first restoration drill for the end of the month and treat it as a learning exercise.

Month three is the access audit. Pull user lists from every major system, reconcile with active staff and volunteer rosters, and remove orphaned accounts. Document who holds administrative access in each system and require that the list be reviewed every six months thereafter. Tie offboarding to the access audit so that future departures trigger immediate revocation.

Months four through six implement email security configuration (SPF, DKIM, DMARC), encrypted connections (HTTPS, VPN or zero-trust access for remote work), and the vendor security review process. None of these is glamorous, but each removes a category of risk. By the end of month six you have rolled out SPF and DMARC, completed a security questionnaire for every vendor handling donor or financial data, and replaced any vendor unable to demonstrate basic controls.

The closing piece is the incident response plan and the staff training program. Both should be written, exercised once, and added to the calendar for annual review. From month seven forward, the work is maintenance: quarterly access reviews, quarterly restoration tests, quarterly phishing simulations, annual training, annual tabletop exercise, and an annual board report summarizing the state of each control and the next investment under consideration.

When to Hire a Professional

Most small nonprofits can implement the checklist with internal resources, particularly when the executive director or operations lead is technically comfortable. There are, however, four situations in which hiring outside expertise is not optional.

First, if you handle protected health information, financial account data subject to PCI DSS, or other regulated categories, hire a consultant familiar with the relevant framework before the first audit. The cost of a small assessment is modest; the cost of a regulator finding that your controls are absent is materially larger. Second, if you have suffered an incident, hire a forensic provider and breach counsel immediately. Insurance often pays. Do not investigate yourself; you may destroy evidence, miss notification deadlines, and complicate any legal action.

Third, when staff exceeds twenty and IT capacity remains a half-time responsibility shared with operations, the gap between your needs and your capacity becomes structural. A virtual chief information security officer engagement—typically a few hours per month from a fractional consultant—provides the strategic oversight, vendor selection, and policy review that your team cannot sustain alongside their day jobs. Fourth, before any major technology change—a CRM migration, a move to a new email platform, or a transition to remote work—commission a brief security review of the proposed architecture. The cost of redesigning later, after the system is live and contains real data, is many multiples of the cost of advising during selection.

Key Takeaway

The argument of this lesson is simple: cybersecurity for a small or mid-sized nonprofit is a discipline of fundamentals, not an arms race. Strong unique passphrases, multi-factor authentication, current patching, tested backups, periodic access reviews, encrypted connections, vendor diligence, monitored logs, written incident response, and ongoing user training—done consistently—defeat the vast majority of attacks aimed at organizations like yours.

What this discipline asks of you is not technical brilliance but consistent attention. Quarterly access reviews. Quarterly restoration drills. Quarterly phishing simulations. Annual training. Annual tabletop. Annual board report. Add the calendar entries today, identify the named owner of each, and circle back next month to verify the password manager rollout is complete. A nonprofit that executes this checklist faithfully will be more secure than the typical for-profit business of comparable size, will protect the donors and clients who trusted it with their data, and will avoid the reputational catastrophe of a public breach. The data is valuable. The trust is irreplaceable. The work is achievable. Begin this week.

Frequently Asked Questions

What's the difference between SOC 2 and ISO 27001 certifications?

Both attest that a vendor has implemented security controls and submits to independent audit, but they differ in scope, geography, and audience. SOC 2, governed by the American Institute of Certified Public Accountants, is the dominant standard for U.S. service providers handling customer data. It is organized around five trust services criteria—security, availability, processing integrity, confidentiality, and privacy—and produces either a Type I report (controls designed at a point in time) or a Type II report (controls operating effectively over a period, typically six to twelve months). When evaluating a U.S. cloud vendor, ask for the SOC 2 Type II report under NDA and read the section listing exceptions and management responses. ISO 27001 is the international standard, governed by the International Organization for Standardization, and certifies an information security management system rather than a specific service. It is broader in scope, more procedural, and dominant in European and global enterprise procurement. For nonprofits, the practical guidance is: prefer vendors with at least one of the two, accept SOC 2 Type II as primary evidence for U.S. providers, and ask any vendor claiming security maturity but holding neither certification to explain why. Major platforms—Salesforce, AWS, Google Workspace, Microsoft 365—hold both.

Should we encrypt our entire database or just sensitive fields?

The right starting point for most nonprofits is field-level encryption of the elements that would constitute a notifiable breach if exposed: government identifiers (Social Security number, passport number), full payment card numbers, bank account and routing numbers, health information, and immigration status. Most modern CRMs—Salesforce Shield, NetSuite, modern fundraising platforms—offer this capability natively. Field-level encryption protects the most sensitive data without imposing performance overhead on operational queries that touch only ordinary fields. Beyond field-level encryption, ensure that the database itself is stored on encrypted disk (transparent data encryption or encryption at rest, almost always default in cloud platforms) and that backups are encrypted. Full database encryption with customer-managed keys provides additional protection in specific high-risk scenarios—holding research data, processing legally privileged communications—at the cost of additional key management complexity. Mature in stages: field-level for clearly sensitive elements first, encryption at rest enabled and verified, customer-managed keys later when scale and risk justify the operational cost.

How often should we change passwords?

Modern guidance—NIST 800-63B, the Center for Internet Security benchmarks, and Microsoft's own published research—has converged on a clear answer: do not require periodic password changes. Forced rotation produces predictable variants (Spring2026!, Summer2026!), encourages password reuse across systems, and trains users to write passwords on sticky notes. The combination of long unique passphrases stored in a password manager and multi-factor authentication produces materially stronger security than rotation ever did. The two exceptions are: when a credential is known or suspected to have been compromised (a breach corpus alert, a phishing incident, suspicious login activity), force an immediate change, and when an employee with shared-account access departs, change the shared credential as part of offboarding. Beyond those, leave passwords alone, invest the policy energy in MFA enrollment and password manager adoption, and measure reuse and breach exposure rather than rotation cadence.

Is cloud storage (Google Drive, Dropbox) secure for sensitive data?

Major cloud storage providers operate security programs that exceed what any small or mid-sized nonprofit can replicate internally. They employ full-time security engineers, run twenty-four-hour operations centers, hold multiple compliance certifications, and patch continuously. For most categories of nonprofit data, cloud storage is the more secure option compared to a local server in a closet. The remaining considerations are configuration and category. Configuration: enforce MFA on every account, restrict link sharing to specific people rather than 'anyone with the link,' enable audit logging, and configure data loss prevention policies that flag uploads of unusual file types or volumes. Category: data subject to specific regulatory regimes—HIPAA-protected health information, PCI cardholder data, or research data with contractual restrictions—must be stored in tiers and configurations that match the regime, often requiring a business associate agreement with the provider, encryption with customer-managed keys, or storage in a dedicated regulated cloud. Ask each provider about encryption at rest, encryption in transit, key management, geographic data residency, and breach notification commitments before storing sensitive content.

What if we get hacked? What's our legal obligation?

Notification obligations vary by jurisdiction, by data category, and by the nature of the incident, but every state in the United States has a breach notification statute, most require notification of affected individuals within thirty to ninety days of discovery, and many require simultaneous notification of the state attorney general when the incident exceeds a threshold (often five hundred or one thousand affected residents). Federal statutes layer on top: HIPAA requires notification of the Department of Health and Human Services for breaches of protected health information, the Gramm-Leach-Bliley Act applies to financial services nonprofits, and the IRS requires notification when tax records are involved. The first practical steps the moment you suspect an incident: preserve evidence (do not wipe affected systems, do not let staff investigate informally), notify your cyber liability insurer to activate their breach response panel, engage outside counsel experienced in data breach response (insurance often pays), and convene your incident response team. Counsel will determine your specific notification obligations based on which states' residents are affected and what categories of data were exposed. Document everything contemporaneously: the attorney general questionnaire, when it arrives, will ask in detail what you knew and when. Attempting to handle this yourself, without counsel, is the most common way nonprofits transform a manageable incident into a regulatory crisis.