Charities hold donor, beneficiary and payment data with a fraction of the security budget of a commercial organisation, and most of their exposure comes through accounts: shared logins, volunteers who never get offboarded and trustees on personal email. The UK Cyber Security Breaches Survey 2025 found that 30% of charities identified a breach or attack in the previous 12 months, that phishing featured for 86% of those, and that only 35% had two-factor authentication on networks or applications. This guide sets out the identity controls that cost little or nothing, how to handle the people charities actually have (staff, volunteers, trustees, partner organisations), how to protect donor data and how to report when something goes wrong. It is written for the person who looks after IT in a small or medium charity, often part time, and for trustees who need to know what good looks like.
Key takeaways
- Turn on what you already have: Microsoft Entra security defaults and Google Workspace 2-Step Verification are free and remove most password-only risk in an afternoon.
- Every person gets their own account: shared logins for the office, the social media page or the donor database make offboarding and investigation impossible; use delegation, shared mailboxes and password manager sharing instead.
- Volunteers need a lifecycle, not a password on a sticky note: give them time-limited, low-privilege accounts tied to a named coordinator who confirms they are still active.
- Protect the money and the donor list first: admin accounts, finance and banking, the CRM and fundraising platforms get phishing-resistant MFA before anything else.
- Trustees own the risk: in England and Wales trustees must report serious incidents, including cyber-crime and significant data breaches, to the Charity Commission promptly, separately from any police or ICO report.
Why charity identity risk looks different
CISA groups civil society organisations with other high-risk communities and notes that limited cyber security budgets make them a "uniquely attractive target". The identity problems that follow are structural rather than technical:
- A mixed workforce: a few paid staff, many volunteers, trustees who meet quarterly, and partner organisations that need access to a shared drive or case system. Each group has a different lifecycle and a different level of trust.
- Personal devices and personal email: volunteers and trustees often work from home computers and forward charity mail to personal accounts, so the charity loses control of where its data sits.
- Accounts created by whoever was there: social media pages, the website, the online shop, the fundraising platform and the email newsletter tool were often set up by a past volunteer using their own email address as the recovery contact.
- Money and trust are the targets: attackers want to redirect donations, invoice the charity with fake supplier bank details, or use the charity's name and sender domain to run donation scams against the public.
- Little monitoring: nobody reads sign-in logs, so a compromised mailbox can run for weeks while the attacker reads conversations and waits for a payment.
The common thread is that attackers use valid accounts (MITRE ATT&CK T1078.004 Cloud Accounts) obtained through phishing (T1566) or password spraying (T1110.003), then send internal phishing from the trusted mailbox (T1534). Controls that make a stolen password useless therefore give the best return.
Free and low-cost controls by platform
Most charities run on Microsoft 365 or Google Workspace, both of which have charity pricing. The security features that matter for identity are available at the cheapest tiers or free.
| Control | Microsoft 365 | Google Workspace | Cost |
|---|---|---|---|
| MFA for everyone | Entra security defaults: MFA registration at next sign-in, number matching in Microsoft Authenticator | 2-Step Verification, enforced from the Admin console for an organisational unit | Free on all tiers |
| Block legacy authentication | Security defaults block IMAP, POP3, SMTP basic auth and Exchange ActiveSync basic auth | Turn off POP and IMAP where not needed and restrict third-party app access in API controls | Free |
| Stronger MFA for admins | Security defaults require MFA on every sign-in for 16 privileged roles, including Global Administrator | Security keys can be required for admin accounts | Free; FIDO2 keys cost per key |
| Policy-based access (location, device) | Conditional Access, needs Entra ID P1 (included in Business Premium) | Context-aware access on higher editions | Paid tier |
| Retention and eDiscovery for investigations | Purview features in Business Premium | Vault in Business Plus and Enterprise | Paid tier |
| Charity pricing | 75% discount on Business Premium for eligible non-profits; up to 5 F3 volunteer seats per licensed E3/E5 seat | Workspace for Nonprofits at no cost; Business Standard and Plus discounted; 2,000-user cap on those editions | Eligibility checks apply |
- Security defaults first: Microsoft states security defaults need no extra licence and work on the free tier of Entra ID. They are all on or all off and cannot be combined with Conditional Access, so a charity on Business Premium should replace them with Conditional Access policies rather than run both. See the Microsoft 365 Security Guide.
- Test before enforcing: blocking legacy authentication breaks old scanners, printers and apps that send email via SMTP basic auth. List them, move them to modern authentication or an SMTP relay, then switch on.
- Google tenants: enforce 2-Step Verification with a short enrolment window, require security keys for super admins, and review which third-party apps can access Google data. See the Google Workspace Security Guide.
- Eligibility caveats: Google excludes governmental entities, hospitals and schools from Google for Nonprofits (their charitable arms may qualify) and verifies status through its validation partner; in the US it requires 501(c)(3) status. Check before planning a migration around a discount.
Choosing MFA methods on a charity budget
The NCSC ranks MFA methods for online services in this order: FIDO2 credentials (passkeys on a trusted device or a roaming security key), challenge-based authenticator apps such as push approval, app-based code generators, hardware code generators and, last, message-based methods (SMS, email, phone call). It says message-based methods are only likely to be appropriate when no other method is possible, and that push approvals are only partially phishing resistant because of prompt fatigue (ATT&CK T1621).
| Group | Recommended method | Practical notes |
|---|---|---|
| IT admins and anyone with a global or super admin role | FIDO2 security key or passkey, two per person | The highest-value purchase a small charity can make; keep the spare in a safe |
| Finance, CEO, fundraising leads, CRM admins | Passkey or security key; authenticator app with number matching as fallback | These are the targets of payment diversion and invoice fraud |
| Staff | Authenticator app with number matching, moving to passkeys | Free; works on personal phones if staff agree |
| Volunteers | Authenticator app or passkey on their own device | Offer a security key to volunteers without a smartphone rather than falling back to SMS |
| Trustees | Passkey or authenticator app on a charity account, not a personal email | Board papers often contain safeguarding and financial detail |
CISA states that MFA makes an account 99% less likely to be hacked; the bigger gain for a charity is closing the most common path, a phished or reused password. See the Phishing-Resistant MFA Guide and the MFA Guide.
Volunteers, trustees and shared accounts
Volunteer lifecycle
- Joiner: a named coordinator requests the account, states the role and an end date (event date, project end, or a 6 or 12 month review). Use a separate group or organisational unit for volunteers so policies apply automatically.
- Least privilege: volunteers get access to the folders, case records or rota they need, not the whole shared drive. Avoid giving them admin rights on social media pages or the website.
- Mover: when a volunteer becomes a staff member or changes project, remove the old access before adding the new.
- Leaver: disable the account on the end date or when the coordinator confirms they have stopped (NIST SP 800-53 AC-2(3) Disable Accounts), revoke sessions, transfer files to a team drive and remove them from shared password vault folders.
- Review: each quarter, send coordinators the list of their volunteers and disable anyone not confirmed.
See the Joiner-Mover-Leaver Guide and the Employee Offboarding Security Guide.
Replacing shared accounts
| Shared login today | Replacement | Why it helps |
|---|---|---|
| info@ or office@ mailbox with one password | Shared mailbox with delegated access from named accounts | No password to share; each sender is logged |
| Social media page owned by one volunteer's personal account | Business manager or page roles with at least two named staff admins | Recovery does not depend on one person |
| Donor CRM with a single "fundraising" login | Named users with role-based permissions and SSO where offered | Exports and deletions are attributable |
| Banking portal credentials kept in a spreadsheet | Individual bank users with dual authorisation for payments | One stolen login cannot move money alone |
| Website or shop admin known to "whoever built it" | Named admin accounts with MFA; supplier access through its own account | Supplier access can be removed at contract end |
| Accounts that genuinely cannot be individual | Password manager shared folder with MFA on the vault | Rotation on leaver; access is logged |
For the password manager itself, see the Password Manager Buyer's Guide. The NCSC's advice that email needs a strong password not used anywhere else applies with extra force to any mailbox used as the recovery address for other charity services.
Trustees and partner organisations
- Trustees: give each trustee a charity account for board papers rather than emailing documents to personal addresses, and apply the same MFA policy.
- Partner organisations: for joint programmes, invite partner staff as guest accounts tied to their own organisation's identity. Entra security defaults treat B2B guests like your own users for MFA. Set an expiry on guest access and review it when the partnership ends. See the Third-Party Access Guide.
- IT suppliers: a managed service provider with admin rights holds the keys to the tenant; ask how its staff authenticate and how access is removed. Assess supplier risk before signing (NIST CSF 2.0 GV.SC-06).
Protecting donor data and the charity's name
- Know where donor data lives: the CRM, the fundraising and payment platforms, the email marketing tool, spreadsheets on shared drives and exports in personal downloads folders. Restrict exports to a small role and log them (CSF 2.0 PR.AA-05).
- Card data: use hosted payment pages from the payment provider so card numbers never touch charity systems; this keeps PCI DSS scope small. See the PCI DSS 4.0 Guide.
- Personal data law: donor and beneficiary data is personal data under UK GDPR; beneficiary data may include special category data such as health. See the UK GDPR and Data Protection Act 2018 Guide.
- Charity scams using your name: fraudsters register look-alike domains or spoof the charity's sender address to collect donations. Publish SPF and DKIM, move DMARC to a reject policy once legitimate senders (newsletter tool, CRM, payment receipts) are aligned, and tell supporters which domains and payment pages are genuine. See the DMARC, SPF and DKIM Guide.
- Payment diversion: any request to change supplier or grant recipient bank details is confirmed by phone using a number already on file, never one in the email. See the Business Email Compromise Response Playbook.
- Backups: keep a copy of the donor database and key files that a compromised admin account cannot delete (CSF 2.0 PR.DS-11). See the Backup Security and Immutable Backup Guide.
A phased rollout for a small team
- Week 1, inventory: list every service the charity uses, who the admins are and which email address recovers each one. Move recovery addresses off personal accounts.
- Week 1, admins: create two cloud-only emergency access accounts with long random passwords stored offline, as Microsoft recommends before moving to Conditional Access. Give admins separate admin accounts and security keys. See the Break-Glass Account Guide.
- Week 2, pilot: enable MFA for staff in one team, with a short guide and a drop-in session. Record which devices and apps break when legacy authentication is blocked.
- Weeks 3 to 4, everyone: enable security defaults or enforced 2-Step Verification for all users, including volunteers and trustees. Revoke existing sessions so users must register.
- Month 2, shared accounts: replace shared logins using the table above and roll out a password manager for what remains.
- Month 3, lifecycle and review: set volunteer end dates, run the first quarterly coordinator review and remove stale guests.
- Rollback: if a critical device or app fails, exclude only that integration (a Conditional Access exclusion or an SMTP relay) for a fixed period with an owner, rather than switching MFA off for everyone.
Small charities without Business Premium should stop at security defaults and a password manager; larger charities with paid tiers should add Conditional Access, compliant device rules for staff laptops and Cyber Essentials certification. See the Cyber Essentials Guide and the Small Business Identity and Access Security Guide.
Detection, reporting and measurement
- What to watch: new mailbox forwarding or inbox rules, sign-ins from unexpected countries, MFA method changes, new admin role assignments, bulk exports from the CRM and new OAuth app consents (CSF 2.0 DE.CM-03). Built-in alerts in both platforms cover most of these at no cost.
- Charity Commission: in England and Wales, responsibility for reporting serious incidents rests with the trustees. Cyber-crime and significant data breaches are reportable, and reports should be made promptly. Reporting to the police or Report Fraud does not replace the Commission report; obtain a crime reference number and say you represent a charity.
- ICO: a personal data breach that is likely to result in a risk to individuals must be notified to the ICO within 72 hours of becoming aware (UK GDPR Art. 33). See the Data Breach Notification Checklist.
- US organisations: CISA accepts reports 24/7 at [email protected] and lists a Cyber Volunteer Resource Center and Project Upskill training for high-risk organisations.
| Metric | Target |
|---|---|
| Accounts (staff, volunteers, trustees) with MFA registered | 100%, exceptions named with an end date |
| Admin accounts using a security key or passkey | 100% |
| Volunteer accounts past their end date and still enabled | 0 |
| Shared logins remaining outside the password manager | Falling each quarter |
| Services whose recovery email is a personal address | 0 |
| Days from volunteer or staff departure to account disabled | 1 working day or less |
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Threat addressed (ATT&CK) |
|---|---|---|---|
| Named accounts for everyone, no shared logins | PR.AA-01 | AC-2 | T1078.004 Cloud Accounts |
| MFA for all users, phishing-resistant for admins | PR.AA-03 | IA-2(1), IA-5 | T1566 Phishing, T1110.003 Password Spraying, T1621 MFA Request Generation |
| Volunteer end dates and quarterly review | PR.AA-05 | AC-2(3) | T1078 Valid Accounts |
| Separate admin accounts | PR.AA-05 | AC-6(5) | T1098 Account Manipulation |
| Trustee accountability | GV.RR-02 | ||
| Supplier and partner access | GV.SC-06 | T1078 Valid Accounts | |
| Protected backups of donor data | PR.DS-11 | T1486 Data Encrypted for Impact |
Common failure patterns
- MFA for staff but not volunteers or trustees: attackers pick the account without it. The Snowflake Breach 2024 showed how infostealer credentials on accounts without MFA were enough to reach customer data warehouses.
- SMS as the default: chosen because it is easy, then never upgraded, even for finance and admins.
- Push approvals without number matching: users approve prompts they did not start, as in the Uber Breach 2022, where MFA fatigue and a contractor's password led to internal systems.
- Donor portals that accept reused passwords: supporter accounts on a fundraising site or shop are exposed to credential stuffing, as the 23andMe Breach 2023 showed at scale. Offer MFA or passkeys to supporters and rate-limit logins.
- Founder or volunteer as the only admin: when they leave, the charity loses its social media page, domain or tenant, or keeps an orphaned admin account nobody monitors.
- Turning everything off when one app breaks: a single failing scanner leads to security defaults being disabled for the whole tenant, rather than a scoped exception.
Practitioner checklist
- Enable Entra security defaults or enforced Google 2-Step Verification for every account, including volunteers and trustees.
- Buy two FIDO2 security keys for each administrator and the finance lead, and require them for admin roles.
- Create two emergency access accounts, store their credentials offline and alert on any sign-in.
- Replace shared logins with shared mailboxes, page roles and named CRM users; put the rest in a password manager.
- Move the recovery email for every service off personal addresses onto a monitored charity mailbox.
- Give every volunteer account an end date and a named coordinator, and run a quarterly confirmation.
- Require call-back verification on any change to bank details for suppliers, grantees or payroll.
- Publish SPF, DKIM and DMARC, and move DMARC to reject once all senders are aligned.
- Write down who reports a serious incident to the Charity Commission, Report Fraud and the ICO, and how quickly.
Standards and references
- NCSC: Recommended types of MFA
- NCSC: Cyber security for small and medium-sized organisations
- Charity Commission: How to report a serious incident in your charity
- DSIT: Cyber Security Breaches Survey 2025
- CISA: High-Risk Communities
- Microsoft Learn: Security defaults in Microsoft Entra ID
- Google for Nonprofits: Google Workspace for Nonprofits
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Small Business Identity and Access Security Guide · Phishing-Resistant MFA Guide · Joiner-Mover-Leaver Guide · Password Manager Buyer's Guide