Your not-for-profit just launched a brand new website. It looks great, the agency did a wonderful job, and everyone on the board is thrilled. Fast forward a year or two and the events page still lists last year’s fundraiser, the staff directory has three people who no longer work there, and nobody can remember who is supposed to approve new content. Sound familiar?
This is one of the most common problems in web design for nonprofits, and the frustrating part is that it is almost entirely preventable. The fix does not happen after launch. It happens before the build even begins.
Governance, meaning who owns the site, who can update it, who approves changes, and who is responsible when things go wrong, needs to be settled early. Not in the handover notes. Not at the six-month review. Before anything gets designed or built.
In this post, we will walk through everything you need to know to get this right. From understanding why NFP websites go stale, to building a simple approval workflow, to having the governance conversation with your designer or developer before you sign a contract.
The 18-Month Problem: Why NFP Websites Go Stale
Most not-for-profit websites launch well. But visit that same site a year or two later and the signs of drift are often unmistakable: a team page featuring staff who left over a year ago, events that closed six months back, a donation form that no longer works, and program descriptions for services the organisation no longer delivers.
This isn’t a story about bad intentions. Every organisation that builds a new site intends to keep it current. The problem is almost always a lack of clarity, specifically, who is responsible for what, and what happens when that person leaves. Without that written down and agreed upon before go-live, accountability quietly evaporates.
For NFPs, this gap tends to be wider than for commercial organisations. A business with a dedicated marketing team has structural ownership baked in. Not-for-profits commonly operate with lean staff and competing priorities, with boards engaged at a governance level but not positioned to manage day-to-day content. When the one person who “knew the website” moves on, the site stalls.
Website management is an ongoing commitment, not a one-time project. The moment an agency hands over a site is the moment that commitment needs a formal structure behind it. If you’re still in the planning stage, our NFP website brief checklist covers what to tell your agency before you start and includes governance as a core item to settle early.
Why Governance Belongs in the Brief, Not the Handover Notes
So the handover document lands in your inbox on go-live day, and suddenly everyone is looking around the room asking: “Who’s actually responsible for this?”
That moment is too late.
Most agencies deliver a handover pack after launch, covering logins, CMS basics, and technical documentation. What it rarely covers is the human side: who approves a content change, who can push it live, and what happens when that person goes on leave. By the time handover arrives, there’s launch pressure, everyone is tired, and governance decisions default to whoever is available rather than whoever is best placed for the role.
The briefing phase is where this belongs. When ownership is defined before the build starts, the technical decisions follow. Your CMS can be configured with the right user roles and permission levels from day one. Navigation structures can reflect how your team will actually manage content, not how it looked in a wireframe. Governance should be defined early to shape the build around real operational needs.
Skipping this creates expensive problems later. Adding approval layers after launch, restructuring navigation to match content workflows that were never discussed, or rebuilding access controls once staff have already gone rogue in the CMS: these are all retrofits that cost far more than an early conversation would have.
For not-for-profit website development projects, governance is a strategic input. Treat it like one.
Board Oversight vs. Day-to-Day Operations: Where the Line Sits
Governance belongs in the brief, but it helps to be clear about which layer of the organisation that means.
NFP boards carry core fiduciary duties that require trustees to exercise prudent judgement over all organisational assets, and that now includes your website. Boards are responsible for understanding what digital assets the organisation holds and ensuring appropriate policies protect them.
But “responsible for” does not mean “hands-on with.” The National Council of Nonprofits describes the board’s proper role as providing foresight, oversight, and insight, not managing daily operations. Setting policy and defining escalation thresholds is board work. Approving individual blog posts or updating an events listing is not.
Operational website management sits firmly with staff: creating, editing, and publishing content is day-to-day work that needs to move at operational speed.
The chief executive sits at the boundary between these two layers. The CEO is accountable to the board for the website’s strategic alignment and policy compliance, but responsible for delegating the actual management to the right staff member.
This separation matters in both directions. Without it, boards drift into micromanaging content updates. Alternatively, no one owns accountability at all, and the site quietly deteriorates. A clear line between board-level policy and staff-level operations prevents both outcomes.
The Four Roles Every NFP Website Needs Someone to Fill
With the board’s role defined at policy level, the practical question is who on staff holds responsibility for each website task.
Most NFPs need four roles covered. One person can hold more than one; the point is that every role has a named owner.
Content Editor handles the day-to-day writing and updating: program pages, news posts, team profiles, event listings. This is typically a communications coordinator or program manager, but in smaller organisations it might simply be whoever has the time and the login.
Content Approver reviews changes before anything goes live. In a lean team this is often the communications lead, operations manager, or CEO. Their job is to check that content is accurate, on-brand, and consistent with current organisational messaging before it reaches the public.
Publisher is the person with technical access to actually push approved content live in the CMS. In practice, the approver and publisher are often the same person in a small NFP. That is fine, but naming the distinction still matters: it keeps accountability clear, especially when something goes live that shouldn’t have.
Escalation Contact is the person responsible when something falls outside normal operations: a broken site, a sensitive content decision, or anything that needs board awareness. This is usually the CEO or a nominated senior staff member.
In a small team, one person may cover two or three of these roles. That is completely workable. What is not workable is leaving any of them unnamed.
How to Build a Simple Approval Workflow for Website Updates
Knowing who holds each role is the foundation; the approval workflow describes how content moves between them.
Step 1: Split your content into two categories. Routine updates (staff profiles, event listings, contact details) need a simple one-step sign-off. Strategic updates (homepage messaging, campaign pages, program descriptions) warrant a more considered review path. Different content, different rules.
Step 2: Write it down. A one-page table listing who initiates, reviews, and publishes each content type is worth more than any verbal agreement. People leave, memories fade, and a document stays.
Step 3: Set time limits on every approval stage. Routine updates might allow 48 hours; a crisis communication or urgent funding announcement needs same-day turnaround. Without a defined ceiling, updates stall in inboxes while the site shows outdated information.
Step 4: Define your escalation triggers. Not everything needs to go up the chain, but some things must. Content that carries reputational risk, legal implications, or contradicts current organisational policy should go to the CEO or board before it goes live. Write those thresholds down so the decision isn’t made under pressure.
Step 5: Bake it into your CMS. Most modern CMS platforms support role-based permissions. Give editors draft access only, reserve publishing rights for approvers, and restrict sensitive sections accordingly. Technical controls reinforce procedural ones and remove the need to rely on everyone remembering the rules.
Setting a Review Cadence That a Lean Team Can Actually Keep
A review cadence complements your workflow, instead of governing how updates move, it sets when someone checks that the site still reflects reality.
A review cadence is a scheduled, recurring commitment to check that your content is current, accurate, and aligned with your organisation’s current priorities. Without one, small inaccuracies pile up quietly until the site becomes a liability rather than an asset.
Quarterly is a workable target for most NFPs. Monthly reviews are difficult to sustain with lean teams. Annual reviews leave too much room for drift, and by the time you catch a problem, it has often been visible to funders or service users for months.
Each quarterly review should cover four things:
- Program and service information: does it still reflect what you actually deliver?
- Team and contact details: any staff changes since last quarter?
- Forms and donation pathways: click through every one and confirm they work
- Messaging alignment: does the content still reflect your current strategy or campaigns?
This is a manageable commitment when you work from a simple checklist reviewed on the same schedule each quarter, the same week, so it becomes routine rather than urgent.
One critical detail: assign the review to a named role, not a named person. Staff changes are a routine reality in NFP organisations, and governance tied to an individual breaks the moment they resign. “The Communications Coordinator reviews the site each quarter” survives a handover. “Jess does it” does not.
What to Put in a Website Governance Document
Once you have your review cadence in place, the next step is putting everything in writing. A governance document gives your whole team a single reference point, so nothing relies on memory or word of mouth.
Here is what it should cover:
Role definitions. Name the four roles (Content Editor, Content Approver, Publisher, Escalation Contact), list who currently holds each one, and note what happens when that person leaves. A one-line handover process for each role is enough.
Content approval workflows. Document the path for routine updates separately from strategic ones. Include who initiates, who approves, and how long each stage should take. Note what triggers escalation to the CEO or board.
Access and credentials. Record who holds CMS logins, who manages hosting access, and how those credentials are transferred when staff change. Do not store passwords in the document itself; reference where they are kept securely.
External partner contacts. List the agency or developer handling technical support, what their maintenance arrangement covers, and how to raise a support request. If you are evaluating whether your current partner is the right long-term fit, this guide to choosing between strategic partners and build shops for custom web development in Melbourne is worth reading before you commit.
Review schedule. Record your quarterly audit dates, what each audit covers, and who signs off on completion.
Keep the document to two or three pages. Anything longer rarely gets read. Store it somewhere the whole team can access, not just in one person’s inbox. A shared drive folder works fine.
How to Raise Governance With Your Website Designer or Developer
Once your governance document is drafted, bring it into the agency conversation early, ideally during the briefing phase, before any platform decisions are made.
Raise it directly: ask how the agency’s preferred CMS supports role-based access, and whether their handover process includes governance documentation as standard. A good agency working on website design or development for nonprofits will welcome this conversation. It reduces post-launch support requests on their end and produces a site that stays well-maintained on yours.
Ask specific questions about user permissions:
- Can you create separate logins for editors and publishers?
- Can access to sensitive sections, such as financial content or board documents, be restricted by role?
- What happens to credentials when a staff member leaves?
Also confirm what ongoing support looks like after handover. Is there a maintenance arrangement in place? A support desk? A named contact for technical escalations? These are not uncomfortable questions; they are reasonable expectations for any organisation investing in website development.
At Slant Digital, governance and support structures are part of the discovery conversation, not an afterthought. That means the site is built around how your team will actually manage it day to day, not just how it looks at launch. If you are ready to start that conversation, you can craft the perfect website brief and submit it here, or if your project involves more complex requirements, submit a brief through our custom web development page.
A Website Without Governance Is a Liability Waiting to Happen
All the frameworks in this post mean nothing if no one is assigned to act on them. The single most important decision you can make is this: agree on who owns the website before the build begins, not after the agency hands it over.
That means applying the framework above, roles, workflow, cadence, and a single written document, before the build begins, not after.
If you are currently planning a not-for-profit website development project, add governance to the brief as a non-negotiable scope item, alongside budget, timeline, and content. It shapes CMS decisions, permission structures, and handover processes. Leaving it out costs more to fix later than it does to include upfront.
If your site is already live and governance was never formalised, the second-best time to do it is now, before content drift takes hold. Start with a simple one-page role and workflow document. It does not need to be perfect to be useful.
A well-governed website is a long-lived one. You can explore what that looks like in practice through our website design and development resources, or see how we build websites that work for your organisation from strategy through to ongoing support.
To discuss how governance planning can be built into your next project from day one, reach out to the team at Slant Digital.
Conclusion
Website governance is not a bureaucratic afterthought. It is the difference between a site that keeps working for your organisation and one that quietly becomes a liability.
The framework is straightforward: clear roles, a documented workflow, a review cadence, and one written reference.
Built in from the start, governance costs very little. Left out, it is expensive to retrofit.
Whether you are planning a new site or managing one already live, the next step is the same. Pick up the governance document template, fill in the names, and make it official.
A website with clear ownership is a website that stays accurate, credible, and useful. That is worth protecting from day one.
