A nonprofit running WordPress needs three things to stay safe: automatic core and plugin updates, a small and vetted set of plugins, and off-site daily backups you have actually tested. Most breaches trace back to an outdated plugin, not a sophisticated attacker who woke up wanting to take down your cause. Get those three right and you have handled the majority of the real risk.
The short version
- Plugins are the attack surface. Patchstack attributed 91% of new WordPress vulnerabilities reported in 2025 to plugins, not to WordPress core.
- The problem is growing. Patchstack recorded 11,334 new WordPress vulnerabilities in 2025, a 42% jump over the year before.
- Patching fast is not always possible. Nearly half of disclosed vulnerabilities, 46%, had no fix ready at the moment they went public.
- A maintenance plan is a process, not a login. It means automatic updates, tested backups, uptime monitoring, and update testing that will not break your multilingual pages.
- Doing nothing has a date on it. Your highest-traffic season, year-end giving, is also when a broken or defaced donation page costs the most.
The real threat is your plugin list, not attackers hunting your mission
Small nonprofits tend to worry about the wrong threat. The picture is almost never a hacker who singled out your food bank. It is an automated bot scanning millions of sites for one specific outdated plugin with a known hole in it. Patchstack's State of WordPress Security in 2026 report counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, up 42% year over year, and 91% of them lived in plugins. WordPress core itself accounted for six. So when people ask me whether WordPress is safe, my honest answer is that WordPress is fine. The forty plugins bolted onto it are the question.
Speed is the part that surprises people. In the same report, roughly half of high-impact vulnerabilities were exploited within 24 hours of becoming public. That is the window you are working against. A site that gets patched whenever someone happens to log in is not inside that window.
Updates are non-negotiable, but blind updates break multilingual sites
Turn on automatic updates, then make them safe to trust. WordPress applies minor core security releases automatically by default, but plugin and theme auto-updates stay off until you switch them on for each item (the WordPress documentation on background updates covers exactly what is and is not automatic). For a plain brochure site, I turn plugin auto-updates on and move on. For anything running WPML, the WordPress Multilingual plugin, I do not.
When I run maintenance for a legal-services nonprofit on WPML, an unattended plugin update is exactly how the French and Spanish versions of a page quietly lose their translations, or throw a fatal error that only appears on the non-English URLs while the homepage looks fine. So those sites get a staging copy, updates applied there first, a click through every translated template, and only then a push to production. It takes about twenty minutes a month and it has never once taken a donation page down. WPML compatibility is not a nice-to-have on a multilingual nonprofit site. It is the whole reason the update process has to be deliberate instead of automatic.
Backups only count if you have restored one
An untested backup is a guess. I have watched more than one organization discover, in the middle of an incident, that their daily backup was a plugin quietly writing to the same server that just got compromised, or a job that had not actually run in months. A backup you cannot restore is not a backup. The setup I trust is off-site, meaning a different provider than your host, running daily, retained for at least 30 days, and restored on purpose at least once so you know the button works. If your host offers backups too, good, but treat those as the second copy, not the only one.
A minimal, vetted plugin set beats a security plugin bolted on top
Every plugin you remove is attack surface you delete for free. The instinct is to install a security plugin and feel covered. That helps, but it does nothing about the eleven other plugins you forgot you installed. Two habits matter more. First, delete deactivated and abandoned plugins entirely, because a deactivated plugin still ships its vulnerable code on your server. Second, be skeptical of the idea that paid means safer: Patchstack found premium and commercial plugins carried roughly three times as many known-exploited vulnerabilities as free ones, so we bought it is not a security review. Before I keep any plugin on a client site, I check when it was last updated, whether the developer responds to security reports, and whether a core feature or a lighter plugin can replace it.
The maintenance plan a nonprofit actually needs
Here is the whole thing, and it is smaller than most vendors will sell you. Every month: apply and test updates, on a staging copy if the site runs WPML or online donations, confirm the latest off-site backup exists, scan for known vulnerabilities, and review any plugin that has gone quiet. Once a quarter: restore a backup on purpose to prove it works. Always on: automatic minor-core updates, uptime monitoring that pings a human when the site goes down, and multi-factor authentication on every admin login. That last one is nearly free and closes off the brute-force path almost entirely. You do not need a 24/7 security operations center. You need this done on a schedule by someone who will actually restore the backup when it matters.
What this does not cover
This is a maintenance and security baseline, not everything web. I am not covering host selection, content delivery network setup, or defending against a targeted distributed denial-of-service (DDoS) attack, which are separate conversations most small nonprofits do not need to have yet. I am also not covering accessibility, which is its own legal and ethical topic, or the bigger question of whether to stay on WordPress at all. If you are asking that last one seriously, my replatform checklist is a better starting point than this post.
Frequently asked questions
How often should a nonprofit update WordPress plugins?
Enable automatic updates for minor releases and check the site at least once a month for major plugin updates. On a simple brochure site, monthly is fine. On a site running WPML or online donations, apply major updates on a staging copy first so a bad release cannot take your live donation page down.
Do we need a paid security plugin or a firewall?
A reputable security plugin with a web application firewall helps, but multi-factor authentication and current updates matter more. Patchstack's 2026 report found that traditional hosting and firewall defenses blocked only a small fraction of WordPress-specific attacks, so a firewall is one layer, not a substitute for keeping plugins current and minimal.
Is WordPress safe enough for a nonprofit, or should we move off it?
WordPress is safe enough when it is maintained, and most breaches come from neglect rather than the platform. If no one owns updates and backups, any content management system will eventually fail you. Move off WordPress for reasons like multilingual complexity or membership needs, not out of fear.
What is the cheapest safe setup for a small nonprofit?
Automatic minor-core updates, monthly plugin updates, multi-factor authentication on admin logins, and a free or low-cost off-site backup you have tested once. That covers most of the real risk for a few dollars a month plus about an hour of attention.
If you want me to run a security and maintenance audit on your nonprofit's WordPress site, plugin by plugin, with a real backup-restore test and a WPML-safe update check, book a 20-minute read-out and I will walk you through what is exposed and what to fix first, in order.