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 two 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 involve four to six people in content decisions but have 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 Equality Act 2010 requires that services — including digital services — be accessible to disabled users. The policy should specify:

• The accessibility standard the organisation commits to (WCAG 2.1 AA is the current 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

GDPR compliance responsibilities should also be covered — specifically who reviews cookie consent settings, privacy policy accuracy, and data collection practices, and at what frequency.

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 for a nonprofit with an annual budget of £2–5 million typically runs eight to fifteen pages. It 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:

1. Purpose and scope — why this document exists and what it covers
2. Roles and responsibilities — decision authority tiers
3. Content governance — approval workflows by content type
4. Technical maintenance — operational responsibilities
5. Compliance obligations — accessibility, GDPR, and regulatory requirements
6. Procurement and suppliers — external engagement authority
7. 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.