The questions that don’t get asked nearly enough are the governance ones. Who owns the website? What does it cost to run? Is it legally compliant? How will you know whether it’s working?
Those are the questions trustees are actually well placed to ask. They’re also the ones that tend to get skipped.
Who actually controls the website?
This is the question that surprises people most. It sounds basic. It often isn’t.
Who has the login to the hosting account? Who registered the domain name? Who holds the administrator password for the website itself? If your developer stopped responding tomorrow – not because anything has gone wrong, just as a thought experiment – could your organisation access everything it needed?
A surprising number of charities I speak to aren’t sure. The site was built a few years ago, set up under the developer’s own accounts, and while the relationship is fine right now, nobody’s thought through what happens if it isn’t.
What trustees should be looking for: the domain is registered to the organisation. The hosting account is in the charity’s name and paid on the charity’s card. At least two people inside the organisation have full administrator access to the website – not just the developer.
This isn’t about distrust. It’s the same reason you wouldn’t have a single trustee as the sole signatory on your bank account.
Legal compliance is a board responsibility
This one makes people uncomfortable. It involves admitting you might not be compliant. But it sits squarely in governance territory, and ‘we didn’t know’ isn’t a defence. I’ve sat in a lot of board meetings. Not always literally – sometimes it’s a director recounting what happened, or a frustrated email a few weeks later – but the pattern is consistent.
Someone presents a website proposal. The trustees listen politely. Then either the budget gets rubber-stamped without anyone really understanding what they’ve agreed to, or the whole thing stalls because someone’s nephew builds websites, and perhaps he could take a look.
Neither outcome is great.
Trustees don’t need to understand WordPress. I’m not suggesting anyone sign up for a development course. But a lot of boards are making decisions about something that represents their charity’s public face, holds personal data about donors and service users, and costs real money to run – without the information they need to do that properly.
That’s a governance problem. And it’s a fixable one.
I’ve been building websites for charities and social enterprises for years. Before that, I spent 15 years on the client side, in education and partnerships, so I know what it’s like to be the person trying to explain a website project to a board. The gap between what the project actually involves and what trustees think it involves is, in my experience, reliably large. Here’s my attempt to close it.
What trustees usually focus on
Design. Almost always design.
Does it look modern? Are the brand colours right? Is it easy to navigate? These aren’t bad questions. But they’re mostly judgment calls – the kind of thing your staff team, your developer, and ideally some actual users from your community should be working through. Not a board meeting.
There are a few areas that matter most.
Data protection and cookies
If your website collects any personal data – contact form submissions, newsletter signups, even just analytics cookies – you have obligations under UK GDPR. Your privacy policy needs to be accurate and current. Your cookie consent needs to actually work, not just exist to tick a box. And if you take donations online, your payment processing needs to be through a properly compliant provider.
Accessibility
Since September 2020, public sector bodies have had a legal duty to meet the Web Content Accessibility Guidelines (WCAG 2.1 AA). Many charities in receipt of public funding have equivalent obligations. But even where it isn’t a strict legal requirement, it’s worth asking whether your website can actually be used by people with visual impairments, cognitive differences, or those relying on screen readers.
Most of the charities I work with exist to tackle inequality in some form. A website that excludes disabled users sits oddly with that mission. (And usually it isn’t that hard to fix.)
Charity Commission transparency
Charities are required to be transparent about their governance, activities, and finances. Your website should accurately represent what you do, who runs the organisation (including trustees) and how to make a complaint. The Charity Commission has specific guidance on this, and it’s worth checking you’re meeting it.
Trustees don’t need to audit all of this themselves. But ‘when did someone last check?’ is a reasonable question to ask at a board meeting.
The build cost is not the whole cost
This one catches a lot of boards out.
A new website isn’t a one-off purchase. There’s hosting (typically £20-100/month for a charity website), domain renewal (around £15-30/year), and then ongoing maintenance – security updates, WordPress updates, backups, monitoring – which is either covered by a care package or, if it isn’t, quietly not happening.
A WordPress website left without maintenance will develop problems. Outdated plugins get exploited. Things break. It usually costs more to fix than it would have to prevent. And the timing is never convenient.
So if the board has just approved a £12,000 website build, the follow-up question is: is the ongoing cost in the budget too? What’s the total annual cost of ownership? Not to block the project – just to make sure there are no nasty surprises six months in.
How will you know if it’s working?
This question should come before the budget discussion, not after. In my experience, it rarely does.
‘Working’ means different things for different charities. For some, it’s donations – does the website generate them, and is the process straightforward? For membership organisations, it’s signups and renewals. For service providers, it’s referrals and self-referrals. For awareness campaigns, it’s whether people are finding you when they search for your cause.
If you can’t define what success looks like before the build starts, you can’t evaluate it six months after launch.
The ask is simple: agree on two or three specific things you’ll measure, make sure there’s a way to track them (Google Analytics at minimum, often something more specific), and decide who’s going to review them and when.
It sounds obvious. It rarely happens without someone asking.
How to make board conversations about websites actually work
Most charity boards aren’t bad at governance. They’re just not set up to have good conversations about digital. A few things I’ve seen work well:
Appoint a digital lead. One trustee who takes an interest in the website and follows up. They don’t need technical knowledge – just a willingness to ask questions and bring things to the board’s attention. Think of it like a trustee lead on finance or safeguarding. They’re not doing the accounts; they’re making sure the right questions get asked.
Ask for a one-pager, not a presentation. When a website proposal comes to the board, a single document covering the problem you’re solving, the total cost (build and ongoing), who manages it, and how you’ll measure success is all you need to make a good decision. Not slides. Not design mockups.
Separate the strategic decision from the design discussion. These are two different conversations. Agree on the strategy and budget first – that’s the board’s job. Then let the staff team and the developer get on with the build. Trying to do both in the same meeting rarely goes well.
A note for directors (who might be sharing this with their board)
(Hello. Yes, I know this happens.)
Trustees can make a website project significantly easier or significantly harder, depending on how they engage with it.
The most helpful thing a trustee can do is come up with a budget range rather than waiting to be quoted. ‘How much would a new website cost?’ can only be answered with another question: ‘How much do you have?’ A realistic number on the table from the start makes for a much more useful conversation.
Trusting your director and your developer on design decisions is also genuinely helpful. If a proper process has been run – user research, testing with real users, working with someone who understands the sector – the board doesn’t need to relitigate the navigation structure. Approve the strategy. Get out of the way. Let the people you’ve hired do their jobs.
And the nephew question. I know it feels unkind to say no. But a charity website holds donor data, processes payments, and represents the organisation to the people it exists to serve. It needs someone who understands WordPress security, accessibility requirements, UK GDPR, and what to do when something breaks at 11 pm before your biggest fundraising push. That’s not a slight on anyone – it’s just a different job.
A governance checklist for the board
Before you sign off on any significant website work, run through this. None of it needs technical knowledge – just someone willing to ask.
I’d start with these four areas and ensure the following:
Ownership and access
- Your domain is registered to the organisation, not an individual
- The hosting account is in the charity’s name and was paid with the charity’s card
- At least two people inside the organisation have administrator access to the website
- All credentials are stored securely using a password manager, not a spreadsheet or a Post-it
Legal compliance
- Verify that the privacy policy is current and accurate
- Ensure that your cookie consent is working properly and is not just decorative
- Review your accessibility compliance against WCAG 2.1 AA standards, or have a plan in place to achieve this standard
- You are meeting the transparency requirements set by the Charity Commission
Costs
- Include hosting and domain renewal costs in the annual budget
- Ensure ongoing maintenance is covered by a care package or accounted for in staff time
Measuring success
- Agree on success metrics before the project starts
- Establish a method for tracking these metrics
- Assign someone the responsibility for reviewing the metrics
None of this is about making things difficult. It’s about making sure the right questions get asked – and that someone’s actually paying attention.
Digital literacy doesn’t mean what people think
It doesn’t mean learning to use WordPress. It doesn’t mean every board needs a trustee who can write code.
At the board level, digital literacy means being comfortable saying, ‘I don’t understand this – can someone explain it in plain English?’ And knowing which questions actually matter.
The boards I’ve seen handle website projects poorly aren’t the ones with no technical knowledge. They’re the ones where nobody feels able to ask the basic questions – and the silence gets filled with either rubber-stamping or obstruction.
Your website exists to support your mission. Making sure it’s doing that – that the organisation controls it, that it’s not creating legal or financial risk, that the money spent on it is money well spent – that’s not a technical question.
You’ve been asking the governance version of it your whole trustee career.
If your board is heading into a website project
I’m happy to help think it through. Sometimes that means working with a director on a brief that gives the board what it needs. Sometimes it’s reviewing your current website against the checklist above. Sometimes it’s just a conversation.
