Who Should Be Able to Edit Your Charity's Website
Key takeaways
- Give each person the least access their job needs. Very few people should hold full control of the site, and content staff need content access only.
- Every login should belong to one named person. A shared password cannot show who changed what, and cannot be withdrawn from one person alone.
- Keep a simple record of who holds which access and when it was granted, and remove access on someone's last day as a formal step in offboarding.
- Permissions do not answer the governance question. They settle who can do what, not who should decide, what gets reviewed before it goes live, or who acts when key people are away.
- A publishing permission will not always act as your review step, so choose a publishing policy: trust and process, draft first, or restricted publishing for high-stakes content.
- When you work with an agency, the organisation should own the account and the site, with the agency's access agreed upfront and removed or transitioned when the project ends.
Summary
User roles and permissions best practices for a charity or nonprofit website: who needs which level of access, why every login should be named, what to do when someone leaves, and the governance questions that permissions cannot answer.
Who should be able to edit a charity or nonprofit website? As few people as the work allows, each on their own named account, each with only the access their job needs. That is user roles and permissions best practice, and it fits in one sentence.
The harder part is what surrounds them. Most organisations have at least one person who can log in. Far fewer have established who is allowed to change what, how content gets reviewed before it goes live, and what happens when the person who built the site leaves. This guide covers both.
What User Roles and Permissions Decide
A login gets someone into the site. A role decides what they can do once inside. CMS user roles have different names on every platform, but they tend to settle into three levels: full control of the site, content editing, and view and comment.
Before assigning any of them, map out what content needs to change, how often, and who on your team can realistically maintain it. Common needs:
- News and blog posts (ongoing)
- Events and programme information (seasonal)
- Team profiles (occasional, triggered by staff changes)
- Homepage and key landing pages (infrequent, high-stakes)
- Funder and partner acknowledgements (occasional)
That tells you how many content accounts you need, where the boundaries sit, and how much the structure of your content is carrying.
An Example: Who Gets Which Role
| Who | Level of access | What it allows |
|---|---|---|
| Whoever is responsible for the technical build | Full control | Layouts, styles, structure, custom code, publishing the whole site |
| Communications staff and content managers | Content editing | Text, images, news items and event listings, within the existing design |
| A trustee who needs to see work before it goes out | View and comment | Reading and commenting, nothing else |
| Former staff and contractors | None | Removed on their last day |
Apply the Principle of Least Privilege
Give people access to what they need to do their job, nothing more. This isn't about distrust. It's about reducing the risk of accidental changes by people who didn't intend to make them. Someone who holds content access only cannot delete a page layout or break a navigation structure, regardless of what they click.
Full control is the level to ration. It should sit with whoever is responsible for the technical build, and at most one trained senior internal stakeholder.
Named Accounts, Never Shared Logins
Each person who edits the site should sign in as themselves. A shared password cannot show who made a change, and it cannot be withdrawn from one person without changing it for everyone.
Maintain a simple record of who holds which access and when it was granted. This is basic governance hygiene: when someone leaves, you need to know what to remove.
Remove Access When People Leave
A common access failure is former staff or contractors still holding active logins months or years after they've left. Build a formal step into offboarding: when someone leaves, their access is removed on their last day.
Any account with full control should also have two-factor authentication enabled. This is non-negotiable: a compromised account at that level can take your site offline, change domain settings, or delete content. For content accounts it is strongly recommended, and especially important for anyone with authority to publish public-facing content.
Permissions Do Not Answer the Governance Question
Permissions handle the technical question of who can do what. They don't handle the governance questions: who should make which decisions, what review content goes through before publication, or how to handle urgent updates when key people are unavailable.
A setting can look as though it answers these and not do so. On Webflow, for example, a member restricted from publishing can still publish individual CMS items. Someone with content access there can write a post and make it live with no review. Depending on your communications policy and risk tolerance, that may or may not be appropriate.
Options for managing publishing:
- Trust and process: content editors can publish, but are expected to follow internal review procedures. This requires strong internal culture and suits experienced, communications-trained staff.
- Draft first: editors always save as draft and notify the Communications Director for review and publishing. This adds friction but ensures a review stage.
- Restricted publishing for key content: high-stakes content (homepage updates, major programme announcements) needs review by someone with full control, while routine content (blog posts, event listings) goes out directly.
Those decisions belong in a document that lives outside the website. My website governance policy guide carries a template structure, and content governance covers what it looks like in practice.
User Roles in WordPress
WordPress is a useful illustration because its levels are published in full. WordPress documents its default user roles as follows:
- Administrator: all the administration features within a single site.
- Editor: publishes and manages posts, including those of other users.
- Author: publishes and manages their own posts.
- Contributor: writes and manages their own posts but cannot publish them.
- Subscriber: manages their own profile only.
A network of sites adds a Super Admin above these. Note where the publishing line falls: it sits between Author and Contributor, so the role you choose decides whether a review stage exists at all. For how to set any of this up, use that documentation.
Agencies, Consultants and Who Owns the Account
If you work with an external agency or consultant, establish clearly:
- What level of access they hold
- Whether they work through your account or their own
- What happens to that access when the project ends
- Who retains the site if the relationship ends (you should always retain ownership)
Count your editors before you agree the arrangement, because access can carry a recurring cost and a limit. Webflow, for one, gives suppliers a small allowance of client seats and more cannot be bought. That is a purchasing decision, and it is better settled at the outset than discovered the first time an extra person needs to publish.
On Webflow? The platform-specific steps are in Platform Notes.
Access is one part of a framework that also covers content review, update procedures, performance monitoring and emergency protocols. If you're planning a new site or a major update, the Blueprint Audit reviews your current governance arrangements and recommends the structure you'll need.
Next Step
Once the right people hold the right access, make sure someone is watching how the site behaves: Website Performance Monitoring for Charities and Nonprofits.
Free download
Your website, for the board.
A two-page briefing you can fill in and put in the next board pack. It covers the six things funders check, how to see what AI tools say about you, and the options to put to trustees.
That did not send. Email hello@socialectric.com and we will send you the briefing. The spam check did not finish. Try again, or email hello@socialectric.com and we will send you the briefing.
Frequently asked questions
- Who on a charity's team should have full control of the website?
Very few people. Typically the person or agency responsible for the technical build, and possibly one senior internal stakeholder who has been trained and understands the consequences of structural changes. Everyone else who updates content, such as communications staff and content managers, should hold content access only. The principle is least privilege: it is not about distrust. Someone with content access cannot accidentally delete a page layout or break the navigation. The prior question is whether your team can maintain the site at all.
- Can someone with editing access publish straight to the live site?
Often, yes, so check rather than assume. WordPress's Author role publishes its own posts while its Contributor role cannot publish, and on Webflow a member restricted from publishing can still publish individual CMS items. There are three workable approaches: trust and process, where trained staff publish but follow an internal review procedure; draft first, where editors save a draft and notify the Communications Director; or restricted publishing for high-stakes content such as homepage updates, while routine posts and event listings go straight out. Whichever you pick, document it.
- What should happen to a nonprofit's website access when someone leaves?
It should be removed on their last day, as a formal step in your offboarding process. A common access failure is former staff and contractors still holding active logins months or years after they have gone. Keep a simple record of who holds which access and when each was granted, so you know what to remove.
- If an agency builds our site, who should own the account?
You should. The organisation owns the account and the site, and agencies or consultants are given access to it. Agree at the outset what level of access they hold, whether they work through your account or their own, what happens to that access when the project ends, and who retains the site if the relationship ends.
- Do we need two-factor authentication on website accounts?
Any account with full control of the site should have it enabled, and that is non-negotiable: a compromised account at that level can take your site offline, change domain settings or delete content. For content accounts it is strongly recommended, and especially important for anyone with the authority to publish public-facing content.