Website Governance Policy for Nonprofits: What to Include and Why
Key takeaways
- A website governance policy defines who can publish, who approves changes, how the site is maintained, and what happens when something goes wrong. It is a document most nonprofits do not have.
- When a site problem surfaces, the underlying cause is usually a governance failure rather than a communications one: no formal framework ensured the right things were updated by the right people.
- The policy should set out ownership tied to a role rather than an individual, with clear decision tiers from routine operational updates through to Board-level sign-off.
- It should cover content approval workflows by content type, technical maintenance including the frequently neglected area of access management, and accessibility and GDPR compliance obligations.
- Name WCAG 2.2 AA as the accessibility benchmark, with checks before publication and audits at least annually, and specify who is responsible for remediation.
- Keep it to plain-English guidance written for Board members and senior staff, and frame it to Trustees as the digital equivalent of a financial controls policy.
Summary
A practical guide to writing a website governance policy for established NGOs: content approval workflows, access management, accessibility compliance obligations, and how to present it to your Board.
A website governance policy is a document that defines how your organisation’s website is managed: who can publish content, who approves changes, how the site is maintained, and what happens when something goes wrong. For most nonprofits, this document doesn’t exist. The website gets updated by whoever has the login, on whatever schedule feels urgent, with no formal record of decisions made.
That’s not a small problem. It’s an institutional liability. When a new Communications Director joins, there’s no record of why content decisions were made. When the Board asks about the website during a governance review, there’s no framework to present. When a platform update breaks something, there’s no protocol for response.
This guide covers what a nonprofit website governance policy needs to contain, how to structure it for a Board-level audience, and how to maintain it as the organisation evolves.
Why Website Governance Policies Matter More Than You Think
Most organisations treat their website as a communications tool maintained by whoever has technical access. This works until it doesn’t, and when it stops working, the consequences are disproportionate to the apparent cause.
A funder conducting due diligence finds outdated programme information. A journalist discovers your annual report hasn’t been updated in years. A new Executive Director inherits a website nobody understands. A Board member asks who approved a recent content change and nobody can answer.
These are governance failures, not communications failures. The underlying cause isn’t that someone forgot to update the website. It’s that no formal framework existed to ensure the right things were updated by the right people with appropriate oversight.
A governance policy doesn’t prevent all problems. What it does is establish accountability structures that make problems easier to identify, address, and explain to oversight bodies when they occur.
What a Website Governance Policy Should Cover
Ownership and Decision Authority
The policy should define who owns the website as an institutional asset. This is usually a specific role (Head of Communications, Digital Manager) rather than a named individual, so ownership transfers with the role rather than requiring a policy update every time someone leaves.
It should also define the decision tiers:
- Operational decisions: who can publish routine content updates without approval
- Tactical decisions: who can change navigation, add pages, update service descriptions
- Strategic decisions: who must approve platform changes, structural redesigns, or significant changes to how the organisation is presented
- Board-level decisions: what requires Trustee awareness or sign-off
Most nonprofit websites have several people involved in content decisions but no formal framework for who can do what. The policy establishes this without requiring Board sign-off for every blog post.
Content Governance
This section defines how content moves from draft to published. Key elements:
- Who can create content: typically anyone in the Communications team, sometimes extended to Programme staff
- Who must review before publication: usually the Head of Communications, sometimes the Executive Director for specific content types
- Approval requirements by content type: annual reports, governance documents, and financial disclosures typically require a higher approval level than news updates or blog posts
- Accuracy review responsibilities: who is accountable for ensuring programme information is current
- Archiving protocols: what happens to time-sensitive content after the relevant date has passed
Technical Maintenance Responsibilities
This covers the operational maintenance that keeps the website functioning and secure:
- Access management: who holds admin access, how credentials are managed, and what happens when someone leaves (this is consistently the most neglected area in nonprofit website governance)
- Platform updates: who is responsible for updates and when they should be applied
- Backup protocols: how often backups occur and how they are tested
- Incident response: who is contacted if the website goes down, what the escalation path is, and what constitutes an incident requiring Board notification
- Performance monitoring: who reviews analytics, at what frequency, and what metrics constitute a concern requiring escalation
Accessibility and Compliance
For UK-registered charities, WCAG AA accessibility compliance is an increasingly standard expectation. The legal basis is the Equality Act 2010: section 29 prohibits a service provider from discriminating in the provision of a service to the public, paid for or not, and section 20 places a duty to make reasonable adjustments so that disabled people are not put at a substantial disadvantage. A website through which you provide services or information is a service for this purpose. The policy should specify:
- The accessibility standard the organisation commits to (WCAG 2.2, the current W3C Recommendation, at Level AA is the benchmark)
- How new content and pages are checked for accessibility before publication
- Frequency of accessibility audits (annually as a minimum, following significant site changes)
- Who is responsible for remediation when accessibility issues are identified
Data protection responsibilities should also be covered: specifically who reviews cookie consent settings, privacy policy accuracy, and data collection practices, and at what frequency. Two laws apply, and the policy should name both. Cookie consent is governed by PECR regulation 6, which requires consent before non-essential information is stored on or read from a visitor's device; since 5 February 2026, under Schedule 13 of the Data (Use and Access) Act 2025, the ICO's maximum penalty for a serious PECR breach is £17.5 million or 4% of global annual turnover, the same ceiling as UK GDPR. The same Act added a statistical purposes exception for analytics, but the ICO's guidance limits it to aggregate data that is not personal data. The privacy policy itself is a UK GDPR obligation, the right to be informed, and has to describe what you actually collect. The GDPR checklist for nonprofit websites walks through both.
Procurement and Vendor Management
This section matters most for organisations that engage external suppliers for website work:
- Who has authority to commission external development work and up to what value
- What level of work requires Board approval
- How handover of credentials and intellectual property is handled when an engagement ends
- What documentation is required from suppliers (code comments, CMS training, handover documentation)
Review and Version Control
The policy itself needs a maintenance schedule. An annual review is the minimum, more frequently during periods of significant organisational change. The document should record:
- The date of the last review
- Who conducted the review
- What was changed and why
- When the next review is scheduled
Format and Length
A website governance policy should be written in plain English, not technical language, because the primary audience is Board members and senior staff, not developers.
The document structure I use with clients:
- Purpose and scope: why this document exists and what it covers
- Roles and responsibilities: decision authority tiers
- Content governance: approval workflows by content type
- Technical maintenance: operational responsibilities
- Compliance obligations: accessibility, data protection, and regulatory requirements
- Procurement and suppliers: external engagement authority
- Review schedule: when and how this document is maintained
How to Get This Approved
In most nonprofits, a website governance policy needs Board awareness but not necessarily formal Trustee sign-off. The framing that works is: this is the digital equivalent of your financial controls policy. It’s not asking Trustees to make operational decisions; it’s giving them confidence that operational decisions are being made within a clear framework.
Present it as a risk management measure, not a new bureaucracy. Boards understand fiduciary duty. A website that anyone can edit, with no audit trail of content decisions, and no incident response plan, is a governance gap. The policy closes that gap.
When to Write One
The honest answer is: before your current website becomes a problem. In practice, most organisations develop a governance policy in one of three situations:
- During a website rebuild, when the new site creates a natural opportunity to establish formal governance before the platform goes live
- After a leadership transition, when the incoming Communications Director or Executive Director inherits a website with no documentation
- After a governance incident: an accessibility complaint, a data breach, outdated content that caused a funder or reputational problem
The third situation is the most common, and the most expensive, because it involves both addressing the immediate problem and establishing the policy under conditions of organisational stress.
Establishing the governance policy as part of implementation, rather than after launch, is part of what I cover in the Blueprint Audit. The audit identifies existing governance gaps and the implementation includes a governance framework your team can maintain and present to Trustees.
For how content governance connects to broader technical decisions in a Webflow build, see How to Prepare Your Nonprofit Website to Go Live. For the accessibility compliance elements in detail, see How to Achieve WCAG AA Accessibility Compliance on a Webflow Nonprofit Website.
For related guidance, see A website maintenance schedule and Webflow backups and version control.
Two clicks. Three things.
Send the address of your website. Within two working days you get a short email naming the three things a funder would hold against it, including what AI assistants like ChatGPT and Google’s AI Overviews currently say about you. No report, no call, no follow-up unless you ask.
Received. Your three things arrive within two working days.
That did not send. Email hello@socialectric.com with your website address and I will reply from there.
Frequently asked questions
- What is a website governance policy?
A document that defines how the website is managed: who can publish content, who approves changes, how the site is maintained, and what happens when something goes wrong. For most nonprofits it does not exist. The site gets updated by whoever has the login, on whatever schedule feels urgent, with no formal record of the decisions made.
- What should a nonprofit website governance policy include?
Seven sections: purpose and scope; roles and decision authority; content governance and approval workflows by content type; technical maintenance, including access management; compliance obligations covering accessibility and UK GDPR and PECR; procurement and supplier authority; and the policy's own review schedule.
- Who should own the website under the policy?
A role rather than a named individual (Head of Communications or Digital Manager, for example), so ownership transfers with the role instead of needing a policy update every time someone leaves. Under that, set decision tiers: operational, tactical, strategic, and what requires trustee awareness or sign-off.
- How long should the policy be, and who is it written for?
Long enough to cover the seven sections above, and no longer. Write it in plain English rather than technical language: the primary audience is trustees and senior staff, not developers.
- Does it need Board approval?
In most nonprofits it needs Board awareness rather than formal trustee sign-off. The framing that works is that this is the digital equivalent of a financial controls policy: it is not asking trustees to make operational decisions, it is giving them confidence that operational decisions are made within a clear framework.
- When do organisations usually write one?
Before the current website becomes a problem, ideally. In practice it happens during a rebuild, after a leadership transition when someone inherits a website with no documentation, or after a governance incident such as an accessibility complaint or outdated content that caused a funder problem. The third is the most common and the most expensive.