Cybersecurity for Charities and Non-Profits Guide

Charities and non-profits hold donor payment details, beneficiary records and sometimes the identities of people at real risk, but run them with small budgets, volunteers on personal devices and fundraising platforms they do not control. The UK government's Cyber Security Breaches Survey 2025 found that 30% of UK charities identified a breach or attack in the previous year, and the largest incidents in the sector have come through suppliers and unpatched systems rather than sophisticated tradecraft. This guide covers the threats that recur in the sector, the regulator and data protection duties that apply when something goes wrong, and the priority controls for organisations that cannot afford a security team. It is written for trustees and directors, operations and IT leads, and the volunteers or providers who look after a charity's systems. For the identity layer in depth, see the Non-Profit Identity Security Guide.

Key takeaways

Phishing is the dominant attack. Among UK charities that identified a breach or attack in the 2025 survey, 86% experienced phishing, so email protection and payment verification come before anything exotic.
Your fundraising platform is your biggest data risk. The Blackbaud ransomware incident in 2020 exposed donor and supporter data held on behalf of non-profit customers; the FTC later ordered Blackbaud to delete data it no longer needed and keep a retention schedule.
Trustees own the reporting decision. In England and Wales the Charity Commission expects trustees to report a significant data breach or cyber crime as a serious incident as soon as reasonably possible, alongside any report to the ICO and the police.
Some charities face state actors. Humanitarian, human rights, advocacy and diaspora organisations are targeted by state-sponsored groups, as CISA, the NCSC and partners set out in their 2024 guidance for civil society.
Free and cheap controls cover most of the risk. MFA on email and banking, automatic updates, separated backups and individual accounts for every volunteer are achievable without a security budget, and Cyber Essentials gives a recognised target.

Why the sector is a distinct risk

A charity combines the data of a retailer (card payments and direct debits), a healthcare or social care provider (beneficiary case records), and a public campaign (a high-profile brand that hacktivists and fraudsters can exploit). Several features make it harder to secure than a business of the same size.

Volunteers and trustees: people who are not employees, change often, and use personal email and devices. Leavers are rarely offboarded from shared drives and social media accounts.
Thin IT capacity: many small charities have no IT staff and rely on a volunteer or a local provider, so patching and backup testing depend on goodwill.
Donated and discounted technology: non-profit licensing programmes from cloud vendors are valuable, but free tiers can lack the logging, conditional access or retention controls of paid plans.
Sensitive beneficiaries: refugees, survivors of abuse, detainees, missing people and their families, whose exposure can cause physical harm, not only financial loss.
Weak supplier oversight: the 2025 survey found only 9% of charities reviewed the cyber risks from their immediate suppliers and 4% from their wider supply chain, while CRM, fundraising, payment and mailing platforms hold most of the data.
Limited board engagement: 30% of charities in the same survey had a trustee with explicit responsibility for cyber security.

Threat picture

The table maps the threats seen most often against charities to ATT&CK v20 techniques and the control that does most to reduce each.

Threat	How it plays out in a charity	ATT&CK	Primary control
Credential phishing	Fake shared document or donation receipt captures a staff or volunteer Microsoft 365 or Google password	T1566.002 Spearphishing Link, T1078 Valid Accounts	MFA on email, link protection, reporting culture
CEO or trustee impersonation fraud	Email from a lookalike address asks finance to pay an invoice or buy gift cards urgently	T1583.001 Domains, T1657 Financial Theft	Second-channel verification, dual authorisation
Password spraying	Common passwords tried against cloud accounts of volunteers who reuse passwords	T1110.003 Password Spraying	MFA, banned password lists, block legacy authentication
Supplier compromise	Fundraising or CRM vendor breached, donor data stolen from the vendor's systems	T1199 Trusted Relationship	Supplier due diligence, data minimisation, retention limits
Exploitation of unpatched systems	Internet-facing server or authentication module exploited with a known vulnerability	T1190 Exploit Public-Facing Application	Automatic updates, patch service levels, retire unsupported systems
Ransomware and extortion	Files and backups encrypted, beneficiary or donor data threatened with publication	T1486 Data Encrypted for Impact	Separated backups, restore testing, least privilege
Hacktivism	Website defaced or taken offline during a campaign or appeal	T1491.002 External Defacement, T1498 Network Denial of Service	Managed website hosting, DDoS protection, admin MFA

The International Committee of the Red Cross (ICRC) attack shows the high end of the range. Attackers exploited an unpatched critical vulnerability in an authentication module, CVE-2021-40539 (Zoho ManageEngine ADSelfService Plus, listed in CISA's Known Exploited Vulnerabilities catalog), on 9 November 2021. The ICRC determined on 18 January 2022 that they had access to the personal data of more than 515,000 people, including missing people and their families and detainees. Its endpoint detection and response agents found the intrusion, and it relaunched systems with two-factor authentication and changed its vulnerability management processes. See the Phishing Guide and the Ransomware Prevention Guide.

Regulation and reporting duties

There is no charity-specific cyber law in the UK, US or EU. Obligations come from charity regulators, data protection law, payment card rules and the terms of funders and contracts. Confirm current requirements with each regulator.

Obligation	Applies to	What it means in practice
Serious incident reporting (England and Wales)	Registered charities, Charity Commission guidance	A significant data breach or loss is an example of a reportable incident. Trustees are responsible for reporting as soon as reasonably possible; reporting to the police or Report Fraud does not replace it. Charities with income over £25,000 declare in the annual return that there were no unreported serious incidents.
Scotland and Northern Ireland	OSCR and the Charity Commission for Northern Ireland	Separate regulators with their own notifiable events regimes; the NCSC Small Charity Guide points Scottish charities to OSCR.
Security of personal data	UK GDPR and EU GDPR Article 32	Security appropriate to the risk. Beneficiary records often include special category data (health, ethnicity, religion), which raises the bar.
Breach notification	UK GDPR and EU GDPR Articles 33 and 34	Notify the ICO or lead supervisory authority within 72 hours of becoming aware of a reportable breach; tell affected people where the risk to them is high.
Card donations	PCI DSS v4.0.1	Any charity taking card payments has PCI DSS obligations; hosted payment pages and reputable payment providers shrink the scope considerably.
US state breach laws and sector rules	US non-profits holding residents' data	State breach notification laws generally apply to non-profits as they do to businesses; health-related non-profits may also be HIPAA covered entities or business associates.

The Blackbaud case shows how regulators view the supplier side. The FTC alleged that a hacker exploited weaknesses in Blackbaud's network in early 2020, went undetected for three months and removed unencrypted data including Social Security and bank account numbers, and that Blackbaud took nearly two months to notify customers. The final order (20 May 2024) requires Blackbaud to delete data it no longer needs, set a retention schedule and run a comprehensive security programme. For the charities that were customers, the lesson is that donor data held by a vendor is still the charity's data protection problem. See the UK GDPR and Data Protection Act 2018 Guide and the Data Breach Notification Checklist.

Priority controls on a small budget

The NCSC's Small Charity Guide groups the basics under five headings. The table turns them into concrete settings and adds the step that charities most often miss.

Area	Minimum setting	Often missed
Backups	Automated backups of finance records, supporter and beneficiary databases and governing documents, stored separately from the original with restricted access	Testing a restore; checking that SaaS data such as the CRM is exported or backed up at all
Malware protection	Antivirus and firewall on every laptop, apps only from official stores, automatic updates, devices replaced at end of support	Removing admin rights from daily accounts; controlling USB drives
Phones and tablets	PIN or biometric, encryption, tracking and remote wipe, mobile device management for charity devices	Volunteers' personal phones that sync charity email with no PIN
Passwords and accounts	Individual accounts for every person, two-factor authentication on email and banking, password manager, default passwords changed	Shared logins for social media, the donation platform or the office mailbox
Phishing	Staff and volunteers know normal payment processes, verify unusual requests from trustees or managers by another channel, and report without blame	SPF, DKIM and DMARC on the charity's domains, so fraudsters cannot spoof them

Beyond these, two settings deliver outsized benefit. First, turn on conditional access or the equivalent security defaults in the charity's Microsoft 365 or Google Workspace tenant to block legacy authentication and require MFA for administrators. Second, enforce a data retention schedule in the CRM and shared drives: donors who lapsed years ago and closed beneficiary cases are a liability, as the Blackbaud order makes explicit. See the Email Security Guide and the Backup Security and Immutable Backup Guide.

Volunteers, trustees and where identity fits

A charity's identity estate is unusual: a small core of staff, a larger and changing group of volunteers, trustees who may sit on several boards, and supporters with online accounts on the donation platform.

One account per person: the NCSC guide says nobody should share logins. Give volunteers named accounts, even on free or low-cost licences, so access can be removed when they leave and activity can be traced.
Joiner and leaver process for volunteers: CISA's civil society guidance calls for auditing accounts, disabling unused ones and removing access for departing staff. Review volunteer access every quarter and on the end of each campaign or event.
Trustee email: trustees using personal email for board papers place confidential data outside the charity's control. Provide charity accounts with MFA, or a board portal.
Stronger MFA for those at risk: finance staff, administrators and anyone working on human rights or humanitarian cases should use phishing-resistant methods such as security keys, which CISA recommends for civil society. See the Phishing-Resistant MFA Guide.
Integrations and API keys: donation forms, CRM sync, mailing tools and payment gateways connect with API keys and OAuth grants that often outlive the person who set them up. Record them and rotate keys when a supplier or volunteer developer leaves. See the Third-Party Access Guide.

High-risk organisations: humanitarian, rights and advocacy groups

CISA, the FBI, the NCSC and partners in Canada, Estonia, Japan and Finland published "Mitigating Cyber Threats with Limited Resources: Guidance for Civil Society" in May 2024. It describes state-sponsored targeting of non-profit, advocacy, faith-based, think tank, journalist, dissident and diaspora organisations, mainly attributed in industry reporting to Russia, China, Iran and North Korea, using tailored spearphishing and commercial spyware.

Organisational measures: keep software updated, implement phishing-resistant MFA, apply least privilege and avoid admin accounts for daily work, vet cloud and managed service providers, and review contracts for logging, monitoring and incident notification.
Provider connections: use a dedicated VPN or equivalent controlled path for managed service provider access rather than open remote desktop.
Individual measures for at-risk staff: hardware tokens, encrypted messaging, limited public personal information, careful app permissions, regular reboots of mobile devices and Lockdown Mode on iPhones in high-risk situations.
Beneficiary data minimisation: collect only what the service needs, and separate the most sensitive records (locations of people in danger, case notes) from the general CRM with tighter access.

See the Threat Intelligence Guide for how smaller organisations can consume advisories relevant to their mission.

Implementation roadmap

Month 1, assign ownership: name a trustee responsible for cyber risk and a staff or volunteer lead; record the charity's essential data and where it lives, including in suppliers' systems.
Month 1 to 2, lock the front door: MFA on all email, banking, CRM and social media accounts; individual accounts replace shared logins; security defaults or conditional access enabled in the cloud tenant.
Month 2 to 3, stop payment fraud: written rule that changed bank details and unusual payment requests are confirmed by phone; dual authorisation in online banking; SPF, DKIM and DMARC published.
Month 3 to 4, make recovery possible: automated backups stored separately with restricted access, including exports of the CRM; one restore tested and timed.
Month 4 to 6, certify: work towards Cyber Essentials, which assesses firewalls, secure configuration, security update management, user access control and malware protection. UK organisations with turnover under £20 million that certify their whole organisation are entitled to cyber liability insurance arranged by IASME.
Month 6 onwards, suppliers and rehearsal: ask fundraising, CRM and payment providers about MFA, encryption, retention and breach notification; run a tabletop with the NCSC's free Exercise in a Box, including the Charity Commission, ICO and donor communication decisions.

Testing and rollback: enable MFA for staff and administrators first, then volunteers in groups, with a help contact for each group. Keep two emergency administrator accounts with strong, separately stored credentials excluded from conditional access so a lockout can be reversed. Run DMARC in p=none reporting mode until mailing and donation platforms are aligned, then tighten.

Decision guidance by size

Decision	Small charity (volunteer-led)	Large charity or international NGO
Assurance target	Cyber Essentials, using the self-assessment route	Cyber Essentials Plus, ISO/IEC 27001 where funders or contracts demand it
Who runs IT security	Named volunteer or local provider, with written responsibilities	Internal security team, managed detection and response
Device approach	Personal devices allowed with app-level protection and MFA	Managed devices for staff, separate controls for field offices
Donor data	Hosted donation pages from the payment provider, no card data stored	CRM with field-level access, data loss prevention, retention automation
High-risk work	Security keys for anyone handling at-risk beneficiaries	Separate systems for sensitive caseloads, threat intelligence, spyware awareness

Mission matters as much as size. A small refugee support group may face a more capable adversary than a large national charity whose risk is mainly fraud, so the high-risk measures above apply by the nature of the work, not by income.

Detection and measurement

Use what the cloud tenant already provides: sign-in logs, alerts on new inbox forwarding rules and new MFA methods, and admin role changes. Ask suppliers how they will notify you of a breach and how quickly. Track a few indicators and report them to trustees.

MFA coverage: percentage of staff, volunteer and trustee accounts with MFA (target 100% for email and banking).
Leaver lag: days between a volunteer or staff member leaving and their access being removed.
Restore test: date and duration of the last successful restore of the CRM and finance data.
Patch status: number of devices or servers past end of support or with updates pending more than 14 days.
Supplier coverage: share of suppliers holding personal data that have answered security questions and agreed notification terms.
Phishing reports: number of suspicious emails reported by staff and volunteers, a sign of a healthy reporting culture.

Framework mapping

Charity control	NIST CSF 2.0	NIST SP 800-53 Rev. 5	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Trustee ownership and regulatory duties	GV.OC-03	n/a	n/a	A.5.31
Individual accounts and MFA	PR.AA-03, PR.AA-05	IA-2, AC-2	5, 6	A.5.16, A.5.17, A.8.5
Awareness and verification of requests	PR.AT-01	AT-2	14	A.6.3
Backups and restore testing	PR.DS-11	CP-9	11	A.8.13
Supplier assessment	GV.SC-07	SR-6	15	A.5.19, A.5.21
Monitoring sign-ins and mailbox changes	DE.CM-09	SI-4	8	A.8.16
Incident reporting to regulators	RS.CO-02	IR-6	17	A.5.24, A.5.26

Common failure patterns

Shared logins that outlive everyone. A single password for the social media account or donation platform, known to a dozen past volunteers, cannot be revoked from one person and leaves no audit trail.
Trusting the supplier to keep data safe. Blackbaud customers learned of the 2020 incident nearly two months after the vendor, and much of the exposed data was older than any operational need. Contracts without notification deadlines and deletion terms leave the charity exposed.
Patching left to chance. The ICRC intrusion used a vulnerability for which a patch existed but had not been applied. Without automatic updates and someone checking, internet-facing systems drift.
Backups on the same drive or account. A USB drive left plugged in or a sync folder is encrypted along with everything else. The NCSC guide stresses keeping backups separate and restricting access to them.
Not reporting because it seems minor. The Charity Commission sets no minimum loss figure and expects repeated low-value fraud or cyber crime to be reported. Unreported incidents also complicate the annual return declaration.
Treating hacktivism or state targeting as someone else's problem. Campaigning and humanitarian charities that hold location data or case notes on vulnerable people need the high-risk measures regardless of size.

Practitioner checklist

Appoint a trustee with explicit cyber security responsibility and report a short set of metrics to the board at least twice a year.
Enable MFA on every email, banking, CRM, donation platform and social media account, with security keys for finance, admins and high-risk caseworkers.
Replace shared logins with individual accounts and remove volunteer access on the day they leave.
Require phone verification of changed bank details and unusual payment requests, and dual authorisation in online banking.
Publish SPF, DKIM and DMARC on all charity domains and move DMARC to enforcement.
Back up finance, supporter and beneficiary data automatically to a separate, restricted location and test a restore.
Turn on automatic updates and replace devices and servers that are out of manufacturer support.
Ask every supplier holding personal data about MFA, encryption, retention and breach notification, and write the answers into contracts.
Apply a retention schedule to donor and beneficiary records and delete what is no longer needed.
Agree who reports to the Charity Commission or OSCR, the ICO, the police and donors, and rehearse it with Exercise in a Box.

Cybersecurity for Charities and Non-Profits Guide: Threats, Regulation and Priority Controls