How to Protect Nonprofit Donor Data from Breaches

What You’ll Learn

1. Why Donor Data Is a High-Value Target
2. Step 1 — Inventory and Classify the Data You Hold
3. Step 2 — Encrypt Data at Rest and in Transit
4. Step 3 — Enforce Access Controls and Least Privilege
5. Step 4 — Train Staff to Recognize Phishing and Social Engineering
6. Step 5 — Vet and Monitor Third-Party Vendors
7. Step 6 — Build and Test an Incident Response Plan
8. Step 7 — Align with Compliance Requirements
9. Frequently Asked Questions
10. Your Next Steps

Why Donor Data Is a High-Value Target

Donors trust nonprofits with more than their money. A single donor record can contain a full name, home address, email, phone number, and credit card or bank account information. When a nonprofit also delivers health, social, or legal services, that same record may include protected health information, case notes, or immigration status.

That combination makes the nonprofit sector a consistent target. The IBM Cost of a Data Breach Report 2024 put the global average cost of a single breach at $4.88 million — a figure most nonprofits could not survive. Smaller organizations face lower absolute losses but proportionally greater damage: reputational harm, donor attrition, and the cost of mandatory notifications can be existential for a 20-person shop.

Attackers also know that nonprofits typically operate with lean IT staff, outdated systems, and limited security budgets. Those are the conditions that make a breach likely, not just possible. Scottship Solutions works with nonprofits to close those gaps before attackers find them.

Step 1 — Inventory and Classify the Data You Hold

You cannot protect data you do not know you have. Start with a data inventory: a documented map of every system, database, file share, and cloud application that holds donor or constituent information.

For each data store, classify the sensitivity level:

• High sensitivity: payment card numbers, bank account data, Social Security numbers, protected health information, donor ID with giving history
• Medium sensitivity: email addresses, home addresses, phone numbers
• Low sensitivity: publicly available information, anonymized aggregate statistics

Classification drives every downstream decision — encryption standards, access controls, retention limits, and breach notification obligations all depend on what you actually hold and where it lives. Common findings at nonprofits include donor exports in shared Google Drive folders with open access, payment records in decade-old spreadsheets, and CRM data replicated to personal devices.

Step 2 — Encrypt Data at Rest and in Transit

Encryption is the baseline technical control. If an attacker reaches your data, encryption makes it unreadable without the corresponding key.

At rest: All donor databases, file servers, and cloud storage should use encryption at rest. Most cloud platforms — Microsoft 365, Google Workspace, Salesforce NPSP, Bloomerang — enable this by default. Verify that encryption is active and that key management is under your control, not a shared vendor default.

In transit: Any data moving across a network must travel over encrypted connections (TLS 1.2 or higher). Enforce HTTPS on every page of your website, not just the donation form.

End-user devices: Laptops and mobile devices used by staff must have full-disk encryption enabled. On Windows that is BitLocker; on macOS, FileVault. Both are built into the OS at no additional cost.

Step 3 — Enforce Access Controls and Least Privilege

Access control determines who can reach what data and under what conditions. The guiding principle is least privilege: every staff member, volunteer, and contractor should have access only to the data their role requires — nothing more.

• Role-based access control (RBAC): Define roles in your CRM, email platform, and file systems. A program coordinator does not need access to the full donor database.
• Multi-factor authentication (MFA): Require MFA on every system that holds sensitive data. Microsoft 365 and Google Workspace both support MFA at no additional cost. This single control blocks the majority of credential-based attacks.
• Privileged access management: Limit administrator accounts to IT staff only. Create separate standard-user accounts for routine tasks.
• Offboarding procedures: Revoke all access within 24 hours of an employee or volunteer departure. Lingering credentials are a frequent source of insider incidents and external compromise.

Scottship Solutions helps nonprofits audit their current access configurations and implement RBAC across Microsoft 365, Google Workspace, and nonprofit CRM platforms. See our cybersecurity services for details.

Step 4 — Train Staff to Recognize Phishing and Social Engineering

The Verizon Data Breach Investigations Report consistently ranks phishing and social engineering as the leading causes of initial breach access. For nonprofits, the risk is compounded by high staff turnover, large volunteer populations, and the frequency of external email from donors, grantors, and partner organizations.

• Phishing simulations: Send test phishing emails to staff and track who clicks. Use results to identify training gaps, not to punish individuals. Repeat quarterly.
• Scenario-based training: Cover gift card scams, wire transfer fraud, and impersonation of executive staff.
• Clear reporting protocols: Staff need a simple, low-friction way to report suspicious emails.
• Volunteer and board coverage: Include volunteers and board members in training, not just paid staff.

According to the Proofpoint State of the Phish Report 2024, 84 percent of organizations experienced at least one successful phishing attack in the prior year. Training alone will not eliminate the risk, but it dramatically reduces the attack surface.

Step 5 — Vet and Monitor Third-Party Vendors

Most nonprofits depend on vendors that process or store donor data: payment processors, CRM platforms, email marketing tools, grant management software, and cloud storage providers. Each vendor extends your attack surface.

Vendor vetting checklist:

• Does the vendor have a published security policy and SOC 2 Type II certification or equivalent?
• Does their data processing agreement clearly define how they store, process, and protect your data?
• Do they support MFA, encryption at rest, and role-based access?
• What is their breach notification timeline and procedure?
• Do they subcontract data processing to fourth parties, and if so, are those subcontractors also vetted?

Review vendor agreements annually. Vendors change their subprocessors and update their terms — often without proactive notification.

Step 6 — Build and Test an Incident Response Plan

A data breach is not a question of if — it is a question of when and how prepared you are to respond. An incident response plan defines what you do in the first hours after a confirmed or suspected breach.

1. Detection and containment: How do you know a breach occurred? Who has authority to isolate affected systems?
2. Internal notification: Who gets called first — the executive director, board chair, legal counsel, cyber insurance carrier?
3. External notification: Most states require breach notification within 30–90 days. HIPAA requires notification within 60 days of discovery.
4. Evidence preservation: Do not delete logs or reformat systems before investigation.
5. Communication: Prepare template donor notifications and board communications in advance, not during the crisis.

Test the plan at least annually with a tabletop exercise. A plan that has never been rehearsed will not hold under real pressure.

Step 7 — Align with Compliance Requirements

• HIPAA: Applies if your nonprofit handles protected health information. Requires a security risk assessment, documented policies, breach notification, and Business Associate Agreements with vendors touching PHI.
• PCI DSS: Applies to any nonprofit that accepts credit card payments. Requires quarterly network scans and annual self-assessment questionnaires.
• State privacy laws: California (CCPA), Colorado (CPA), Virginia (CDPA), and Connecticut (CTDPA) impose data rights and notification obligations regardless of where the nonprofit is headquartered.
• NIST CSF 2.0: Not legally required but widely used as a roadmap across six functions: Govern, Identify, Protect, Detect, Respond, Recover.

Scottship Solutions helps nonprofits identify which frameworks apply and build a compliance roadmap that maps controls to budget reality.

Frequently Asked Questions

Your Next Steps

1. Run a data inventory. Map every system and file that holds donor information and classify data by sensitivity level.
2. Audit your access controls. Review who has access to your CRM, financial systems, and shared drives; revoke any access that exceeds role requirements.
3. Enable MFA. Turn on multi-factor authentication for Microsoft 365 or Google Workspace if you have not already done so.
4. Review your vendor agreements. Pull the data processing agreements for your top five vendors and confirm breach notification timelines and data handling terms.
5. Schedule a free consultation with Scottship Solutions — our team evaluates your current security posture, identifies the highest-priority gaps, and builds a remediation roadmap scaled to your organization.

Sources

• IBM — Cost of a Data Breach Report 2024
• Verizon — Data Breach Investigations Report 2024
• Proofpoint — State of the Phish Report 2024
• U.S. Department of Health and Human Services — HIPAA Breach Notification Rule
• PCI Security Standards Council — PCI DSS v4.0 Overview
• NIST — Cybersecurity Framework 2.0

Written by

Josh Bass

Cybersecurity Consultant at Scottship Solutions

Josh leads security assessments and compliance audits for mission-driven organizations. He helps nonprofits build defensible security postures, meet HIPAA and state privacy requirements, and respond to threats before they become incidents.

Certifications

CompTIA Security+ Certified

Industries Served

Healthcare & Community Health (HIPAA), Human Services, Child Advocacy, Foundations & Grantmakers