Cyber Security for Nonprofits: A 90-Day Action Plan Sequenced for Budget Constraints and Board Approval Cycles

title: Cyber Security for Nonprofits: A 90-Day Action Plan Sequenced for Budget Constraints and Board Approval Cycles author: GXA IT Security Practice Team credentials: Managed Security Service Provider serving DFW nonprofits, healthcare organizations, and professional services firms schema: [Article, FAQPage, HowTo] date: 2026-04-15

Most cybersecurity guides for nonprofits fail in the same place: they hand you a checklist without accounting for the two constraints that make nonprofit IT fundamentally different from corporate IT. First, you likely need board approval — or at minimum board awareness — before committing to any spend tier above a threshold that may be as low as $500. Second, a meaningful share of your IT footprint is operated by volunteers who won’t tolerate complexity and can’t attend mandatory security training on a Tuesday afternoon.

The 90-day plan below is built around those constraints. Steps are sequenced by impact-to-cost ratio, not alphabetically or by category. Spend tiers are flagged as either zero-cost, operational-budget, or grant-fundable so you can route approvals correctly. Every phase produces a deliverable you can actually present to a board that isn’t sure why this matters.

AEO Definitive Answer

Nonprofits should approach cybersecurity by sequencing zero-cost controls first (MFA, access audits, password policy), then hardening donor and payment data in the second phase, then deploying endpoint and email protection in the third. Each phase maps to a distinct spend tier that aligns with typical board approval thresholds and grant eligibility windows.

Days 1–14: Quick Wins That Cost Nothing (MFA, Password Policies, Access Audit)

The most dangerous assumption in nonprofit IT is that a limited budget justifies delayed action. The three controls below cost nothing in licensing fees and can be deployed before your next board meeting.

1. Enable MFA Across All Existing Platforms

If your organization uses Microsoft 365 or Google Workspace — both of which offer nonprofit licensing at steep discounts through TechSoup — multi-factor authentication is already included. The barrier isn’t licensing; it’s the internal will to enforce it. Set a 14-day enforcement deadline for all staff and board member accounts. Volunteers who access organizational systems need to be included. Build a one-page visual guide specific to your org’s platform (Microsoft Authenticator vs. Google Prompt) and send it with the enforcement notice.

The payoff is disproportionate to the effort. Credential-based attacks — phishing, password stuffing — are the most common entry vector for nonprofit breaches. MFA interrupts the majority of them without touching your budget.

2. Run a Privilege Audit

Open your Microsoft 365 Admin Center or Google Admin console and export a list of all users with administrator-level access. In most nonprofits that haven’t done this in 12+ months, you’ll find 2–4 accounts that belong to former staff or volunteers who were never offboarded. Remove those accounts immediately. Then audit which active users have Global Admin or equivalent roles — most should be demoted to standard user with elevated permissions only where documented job function requires it.

Document this audit in a spreadsheet with columns: username, role, last login date, justification for current access level, action taken. This document becomes Exhibit A in your board security report.

3. Set a Password Policy That Volunteers Will Actually Follow

Passphrase-based policies (three random words, 16+ characters) outperform complex-but-short passwords in both security and memorability. NIST’s current guidance (SP 800-63B) explicitly moves away from mandatory special-character complexity in favor of length. Update your policy to reflect this, push it through your identity provider, and set a minimum length of 16 characters. This takes under an hour to configure and significantly reduces help desk burden from lockouts — a real cost in volunteer-dependent environments.

Phase 1 deliverable: A one-page Access Audit Summary showing accounts reviewed, accounts removed, admin roles rationalized, and MFA enforcement status. This is your first board-facing artifact.

Days 15–30: Donor Data and Payment Processing Security Hardening

Donor data is your most sensitive asset and your highest regulatory exposure. If your organization processes donations via credit card — even through a third-party platform like Stripe, PayPal, or Bloomerang — you are in scope for PCI DSS, even at a minimal level.

Map Where Donor Data Actually Lives

Before you can protect it, you need an honest inventory. Donor records typically scatter across: your CRM (Salesforce NPSP, Bloomerang, DonorPerfect), email archives, exported spreadsheets saved to staff desktops or personal Google Drives, printed reports in file drawers, and board member personal devices used for solicitation calls. The spreadsheets and personal devices are your highest-risk items.

For organizations using Salesforce NPSP or the newer Nonprofit Cloud — which Techforce notes continues to be heavily adopted through 2026 — the CRM itself has robust permission controls that most orgs underutilize. Audit which staff profiles have access to giving history and contact data, and restrict to development staff and leadership only.

Eliminate Unnecessary Data Copies

Every exported spreadsheet containing donor names, emails, and giving history that lives on a local drive or personal cloud account is an uncontrolled copy. Establish a policy: donor data exports require IT approval, must be stored only in designated shared drives with audit logging, and must be deleted within 30 days of their purpose being fulfilled. Send a written notice to all staff requesting voluntary deletion of unauthorized copies, with a 2-week deadline.

Verify Your Payment Processor Is Doing the Heavy Lifting

If you use a hosted payment page (Stripe, PayPal, Classy, Bloomerang Payments) where donors enter card data directly into the processor’s environment, your PCI scope is minimal — but you still need to verify this is actually how your donation flow works. If anyone on your staff manually keys card numbers into a terminal or a system, that changes your scope significantly. Confirm the architecture with your payment processor and document it.

Phase 2 deliverable: A one-page Data Map showing where donor PII lives, what has been consolidated or deleted, and confirmation of payment processing architecture. Include this with your board report.

Days 31–60: Endpoint Protection and Email Security Deployment

This is the first phase where budget enters the picture — and where many nonprofits stall waiting for board approval. If you front-load the zero-cost phases correctly, you enter this conversation with documented evidence of your current posture and a clear case for the next investment tier.

Endpoint Protection

For most nonprofits operating under 50 seats, Microsoft Defender for Business (included in Microsoft 365 Business Premium, which is available at reduced nonprofit pricing through TechSoup at approximately $5/user/month) provides enterprise-grade EDR (Endpoint Detection and Response) without requiring a separate security product. If your org is already on Business Basic or Business Standard, this is an upgrade decision, not a new vendor decision.

For organizations not on Microsoft 365, options like Malwarebytes for Teams or Huntress (which has a specific nonprofit pricing tier) are worth evaluating. The key criteria: centralized management console, automated remediation, and alerting that goes to someone who can act on it — not just a log file that gets reviewed quarterly.

Email Security: The Control That Pays for Itself

Business email compromise (BEC) — where an attacker impersonates your executive director or a board member to redirect wire transfers or gift card purchases — is the most financially damaging attack pattern for nonprofits. Three DNS-level controls block the majority of spoofing attacks:

• SPF (Sender Policy Framework): Specifies which mail servers can send email on behalf of your domain
• DKIM (DomainKeys Identified Mail): Cryptographically signs outbound email
• DMARC (Domain-based Message Authentication, Reporting & Conformance): Tells receiving servers what to do when SPF/DKIM fail

These are DNS record configurations — no licensing cost. Check your current status at MXToolbox DMARC Lookup. If you don’t have DMARC at enforcement (p=quarantine or p=reject), adding it is a half-day project for whoever manages your DNS.

For additional email filtering beyond what Microsoft 365 or Google Workspace provides natively, products like Proofpoint Essentials (nonprofit pricing available) or the built-in Microsoft Defender for Office 365 Plan 1 add attachment sandboxing and link detonation.

Phase 3 deliverable: An Endpoint & Email Security Summary showing what products are deployed, on how many devices, with a screenshot of your DMARC record status. Budget impact for board: list the per-user monthly cost and annualized total.

Days 61–90: Monitoring, Incident Response Plan, and Board Reporting Template

By day 60, you have MFA enforced, donor data mapped and hardened, endpoints protected, and email authentication in place. The final phase establishes what happens when something goes wrong — and how you communicate security posture to the board on an ongoing basis.

Monitoring: Proportionate to Your Size

Full SIEM (Security Information and Event Management) is overkill for most nonprofits under 100 staff. What you actually need:

1. Microsoft 365 Audit Log alerts for impossible travel logins, mass email deletions, and permission escalations — configurable within the existing admin console
2. Endpoint alerts routed to a monitored inbox — whether that’s your IT staff, an outsourced managed security provider, or a co-managed arrangement
3. Monthly review of Azure AD / Entra sign-in logs for anomalous activity

For nonprofits that lack internal IT staff to monitor these alerts, this is the most common point where engaging an outsourced IT support provider makes sense — not to manage all of IT, but specifically to handle alert triage and incident response escalation.

Incident Response Plan: One Page Is Enough

A nonprofit incident response plan doesn’t need to be a 40-page document. It needs to answer five questions:

1. Who declares an incident? (Named role, not just “IT”)
2. Who gets notified in the first hour? (Executive director, board chair, legal counsel if applicable)
3. What systems get isolated first?
4. Who handles external communication? (Donors, regulators, media)
5. What’s the recovery order?

Document the answers, have the executive director and board chair sign it, and store it somewhere accessible offline (printed copy in a physical location known to leadership, not just in the cloud system that might be the one that’s down).

Board Reporting Template

Boards govern risk, but most board members aren’t equipped to interpret technical security metrics. Translate your security posture into three dimensions they do understand:

This format respects board members’ time and gives them enough information to fulfill their fiduciary duty without requiring technical literacy.

How to Present Cybersecurity Costs to a Nonprofit Board

The most common failure mode isn’t inadequate security — it’s adequate security that never gets funded because the request was framed incorrectly.

Boards respond to risk framing, not feature lists. Instead of “We need Microsoft Defender for Business at $5/user/month,” present it as: “Our current endpoint configuration leaves us exposed to ransomware, which has a median recovery cost that would exceed our operating reserve. Defender for Business closes that gap at $X annually.”

According to Forrester’s 2026 Security Budget Planning Guide, security investments need to be tied to business outcomes and risk reduction — not technology capabilities — to win budget approval. The same principle applies directly to nonprofit boards: tie every investment to a specific risk scenario and its financial consequence to the organization.

Two tactical points that improve approval rates:

Break requests into spend tiers that match your board’s approval thresholds. If the board requires a vote for anything over $2,500, don’t bring a $12,000 annual security package as a single line item. Break it into quarterly or phased commitments that route through the appropriate approval channel.

Name the grant opportunity alongside the budget request. If a cost is grant-fundable (see below), say so explicitly. “This $4,200 annual investment is eligible for the [specific grant program]. We’re applying in the next cycle. We’re requesting operational budget as a bridge.” That’s a materially different ask than a standalone budget request.

Grant-Fundable vs. Operational-Budget Security Investments

The distinction between what can be grant-funded and what must come from operations is underutilized in nonprofit security planning. As Lúgh Studio’s 2026 nonprofit trends analysis notes, cybersecurity is increasingly appearing as an eligible line item in capacity-building grants — but only if the request is structured correctly.

Typically grant-fundable (capacity-building framing):

• Security risk assessments and penetration tests (one-time, produces deliverable)
• Security awareness training platforms (Proofpoint Security Awareness, KnowBe4)
• Initial deployment of endpoint protection (first-year licensing, setup costs)
• Incident response plan development (if delivered by a vendor with documentation)
• Hardware replacement cycles tied to security lifecycle (EOL workstations running unsupported OS)

Typically operational-budget (recurring, infrastructure):

• Ongoing endpoint protection licensing
• Managed security monitoring fees
• Password manager licensing
• Email security filtering subscriptions

Funders to investigate: CISA has published guidance on nonprofit cybersecurity resources. State-level community foundation capacity grants often include IT security. If your organization serves vulnerable populations (healthcare adjacent, legal aid, housing), HHS and HUD capacity grants have included security infrastructure.

For nonprofits in the DFW area specifically, understanding how to structure an IT security engagement — whether fully managed or co-managed — is worth reviewing alongside how managed IT security service providers actually structure their engagements, particularly around what’s included vs. what accrues as out-of-scope costs.

FAQ Block

Q: What is the most important cybersecurity control for a small nonprofit with no IT staff?

MFA on all accounts is the single highest-impact, zero-cost control available. If email accounts, CRM access, and cloud storage are protected by MFA, the majority of credential-based attacks — which represent the most common breach vector for nonprofits — are interrupted before they result in data loss or financial harm.

Q: Does a nonprofit need to comply with PCI DSS if it uses a third-party donation platform?

Yes, but scope varies significantly. If donors enter payment data directly on a hosted page operated by the payment processor (Stripe, PayPal, Classy), the nonprofit’s PCI scope is minimal — typically a self-assessment questionnaire. If staff manually process card numbers, the scope expands considerably. Confirm your payment architecture with your processor and document it in writing.

Q: Can cybersecurity costs be included in grant applications?

Increasingly, yes. Capacity-building grants from community foundations, state-level funders, and some federal programs accept cybersecurity risk assessments, training platforms, and endpoint protection as eligible expenses. The key is framing the investment as organizational capacity, not IT infrastructure. Work with your development staff to identify funders whose capacity-building guidelines explicitly include technology or security.

Q: How often should a nonprofit conduct a security risk assessment?

Annually is the practical standard for most nonprofits, with a more comprehensive assessment every two to three years. Organizations that handle sensitive client data (health information, legal records, housing data) should assess annually at minimum and consider compliance-specific assessments if HIPAA or other regulations apply. A risk assessment is also a logical prerequisite before applying for cybersecurity grant funding.

Q: Why is network security important for nonprofits specifically, given their limited data compared to corporations?

The premise of “limited data” is usually incorrect. Nonprofits hold donor financial information, client records (often for vulnerable populations), employee HR data, and banking credentials — all high-value targets. Attackers specifically target nonprofits because security investment is typically lower than the corporate sector while data sensitivity is comparable. Why network security is important isn’t a different question for nonprofits — the consequences of a breach (donor trust erosion, regulatory penalty, operational shutdown) can be existential in ways that don’t apply to larger enterprises with deeper recovery reserves.

The one thing to do this week: Pull a list of all admin-level accounts in your Microsoft 365 or Google Workspace tenant. Count how many belong to people no longer with your organization. That number — before any other security work — tells you more about your current exposure than any framework assessment. Start there.