Website Security for Nonprofits: What the Board Needs to Know | Socialectric

Website security rarely appears on a nonprofit Board agenda. It is not in the risk register. It is not discussed at trustee meetings. It is not part of the annual governance review. The assumption, usually unstated, is that whoever built the website took care of security and that it continues to be taken care of without anyone needing to think about it.

That assumption holds until it does not. A website is defaced. A donation form is compromised. Donor data is exposed. A phishing page appears on a subdomain nobody knew existed. At that point, the Board discovers that nobody was responsible for security, nobody was monitoring it, and the organisation has no incident response plan. The reputational damage, regulatory consequences, and loss of donor trust that follow are disproportionate to the cost of the governance that would have prevented them.

Website security is not a technical problem that belongs to IT. It is a governance responsibility that belongs to the Board.

Why nonprofits are targeted

Nonprofits are attractive targets for exactly the reasons that make them unlikely to invest in security. They handle sensitive data (donor payment information, beneficiary personal details, staff records) but typically have less security infrastructure than commercial organisations of similar size. They often run on platforms with known vulnerabilities, particularly self-hosted WordPress installations with outdated plugins. And they frequently have unclear accountability for who maintains the technical infrastructure, which means vulnerabilities persist longer before anyone notices.

The most common attacks are not sophisticated. They are automated scans that look for known vulnerabilities in outdated software. A WordPress plugin that has not been updated in eighteen months. An admin login page with no rate limiting. A contact form with no spam protection that gets turned into a relay for phishing emails. These are not targeted attacks by adversaries who care about your mission. They are opportunistic exploits by automated systems that do not care what your organisation does.

The consequence, however, is specific to your organisation. A commercial website that gets compromised loses some traffic. A nonprofit website that gets compromised loses donor trust, may breach Charity Commission expectations around data stewardship, and faces potential regulatory action under GDPR if personal data is exposed.

What the Board should be asking

The Board does not need to understand the technical detail. They need to ask the right questions and receive clear answers. If the answers are unclear, that is itself a governance finding.

The first question is: who is responsible for the security of our website? Not "who built it" or "who hosts it," but who is actively responsible for ensuring it remains secure on an ongoing basis. If the answer is "our web developer," the follow-up is: is that documented in a contract, is there a defined scope of security responsibilities, and when did they last perform a security review?

The second is: what data does our website collect and where is it stored? Donation forms collect payment details. Contact forms collect personal information. Newsletter sign-ups collect email addresses. Volunteer forms may collect DBS numbers, medical information, or safeguarding-relevant data. The Board should know what categories of data flow through the website and whether the storage and processing of that data meets GDPR requirements.

The third is: what would happen if our website were compromised tomorrow? Does the organisation have a backup? Who would be responsible for restoring the site? How long would it take? Is there a communication plan for notifying affected donors or stakeholders? If the answer to any of these is "we do not know," the organisation is operating without a basic incident response framework.

The fourth is: when was the website last reviewed for security vulnerabilities? For self-hosted platforms like WordPress, this includes checking for outdated core software, plugins, and themes. For managed platforms like Webflow, the hosting provider handles infrastructure security, but the organisation is still responsible for third-party scripts, form handling, and access management. A review should happen at minimum annually.

Platform choice is a security decision

The platform your website runs on determines a significant portion of your security posture, and most nonprofits do not think about it in those terms.

Self-hosted WordPress installations are the highest-risk option for organisations without dedicated technical staff. WordPress itself is regularly updated, but the security of the site depends on every plugin, theme, and server configuration being kept current. A single outdated plugin with a known vulnerability is enough for an automated attack to gain access. If your team does not have someone responsible for applying updates within days of release, the site is accumulating risk with every week that passes.

Managed platforms like Webflow, Squarespace, and similar services handle infrastructure security, SSL certificates, and hosting at the platform level. This removes an entire category of risk. The organisation still needs to manage access credentials, third-party scripts, and form data handling, but the underlying server infrastructure is not their responsibility. For nonprofits without technical staff, this is a meaningful security advantage.

The point is not that one platform is inherently secure and another is not. It is that platform choice has security implications, and those implications should be part of the rebuild or remediate decision rather than an afterthought.

The basics that most nonprofits miss

Security governance for a nonprofit website does not require enterprise-level investment. It requires attention to a small number of fundamentals that are frequently neglected.

Access management is the first. Who has admin access to the website? Is it documented? Are there former staff or former agency partners who still have login credentials? When someone leaves the organisation, is their website access revoked as part of the offboarding process? For most nonprofits, the honest answer is that access has never been audited, and there are almost certainly credentials in circulation that should have been revoked years ago.

SSL and HTTPS are the second. Every page on the site should be served over HTTPS. This is non-negotiable and has been for years. If any page on your site shows a "Not Secure" warning in the browser, donors will not complete a payment on it, and they should not be asked to.

Third-party scripts are the third. Every external script loaded on your site (analytics, chat widgets, donation embeds, social media pixels) is a potential vector for compromise if the third-party provider is breached. The cookie consent implementation should be managing which scripts load and when, but the organisation should also maintain a list of every third-party service connected to the website and review that list annually.

Backups are the fourth. Can your website be restored if it is compromised or deleted? Who holds the backup? How recently was it taken? Managed platforms like Webflow include automatic backups. Self-hosted sites require someone to configure and verify backups. If nobody can confirm that a current backup exists, the organisation is one incident away from losing its entire web presence.

Making security a governance item

The single most effective thing a nonprofit can do about website security is put it on the Board agenda once a year. Not as a technical briefing, but as a governance item. The responsible person (usually the Communications Director or whoever manages the website) presents a short summary: what platform the site runs on, who has access, what data it handles, when it was last reviewed, and whether there are any known risks.

This takes fifteen minutes. It creates accountability. It ensures that security does not remain invisible until an incident forces it into view. And it gives the Communications Director a governance reason to request the resources needed to address any gaps, rather than absorbing the risk quietly because nobody asked.

Question 1: Is our Webflow site secure, or do we still need to worry about security?

Webflow handles infrastructure security, SSL, and hosting. That removes the most common category of risk (server vulnerabilities, outdated software). But you are still responsible for access management (who has admin credentials), third-party scripts (what external services are connected to the site), and form data handling (where submissions go and how they are stored). Platform-managed security is significantly better than self-hosted, but it does not eliminate governance responsibility entirely.

Question 2: We had a website built by an agency three years ago. Should we be concerned?

If the site is self-hosted WordPress and the agency is no longer actively maintaining it, yes. Outdated plugins and themes are the most common vulnerability. If nobody has applied updates in the past six months, the site is likely running software with known, exploitable vulnerabilities. Contact whoever has hosting access and ask for a current status. If you cannot get a clear answer, that is your answer.

Question 3: What should we do if our website is compromised?

First: take the site offline to prevent further damage or data exposure. Second: notify your hosting provider or platform (they may be able to restore from backup). Third: assess what data may have been exposed and whether you need to report the breach to the ICO under GDPR (you have 72 hours from discovery). Fourth: communicate with affected stakeholders. If you do not have a documented plan for this, create one before you need it. A one-page incident response plan is better than no plan at all.

If you are not certain whether your website's security posture meets your governance obligations, or if the Board has never received a security briefing on the organisation's web infrastructure, a Blueprint Audit includes a technical infrastructure review and identifies the specific risks that need to be addressed.