Editor Access, Admin Power: Where to Draw the Line in Your CMS

Most CMS permission problems do not begin with someone trying to break the site. They begin with someone trying to help. A colleague needs to fix a form, add a redirect, or nudge the homepage banner before a campaign goes live. The fastest route is to make them an administrator. It works, everyone moves on, and the account stays that way for years.

That is the blur worth fixing. Content editors and CMS administrators do different jobs, but plenty of lean UK web teams hand out the same level of access to both. The result is not usually a dramatic breach. It is a slow accumulation of risk: plugins installed without testing, templates edited during a quiet Friday afternoon, user accounts nobody remembers creating, and a site that becomes harder to explain when someone asks who changed what.

Why the line gets blurry

In a small team, everyone wears several hats. The person who writes the newsletter may also manage the events listing, update the staff directory, and keep an eye on the contact form. When a problem lands, the quickest fix is often to give them more access rather than spend an hour working out which role they actually need.

Agency handovers can make this worse. A developer builds the site, gives the in-house team administrator accounts so they can 'manage everything', and moves on. Legacy accounts linger after a restructure. Shared logins survive because they are convenient. Before long, the list of administrators is longer than the list of people who genuinely need to configure the CMS.

None of this makes anyone careless. It is just what happens when a small team prioritises momentum over permission hygiene.

What configuration access actually means

Content work is the day-to-day editing of pages, media, events, products, blog posts, taxonomy terms, and publishing schedules. Configuration work changes how the CMS itself behaves: user roles, plugins or extensions, theme templates, integrations, API keys, form definitions, security settings, backups, and workflow rules.

That distinction matters because the consequences are different. Changing a paragraph is usually reversible through revisions. Installing an untested plugin can affect the whole site. Editing a global template can break every page that uses it. Changing a form definition can alter what personal data your organisation collects. Adding a user account can open a door that nobody audits for another two years.

For UK organisations handling personal data, access control is not just a technical preference. UK GDPR accountability and data minimisation principles sit comfortably alongside a least-privilege approach. You do not need a legal essay to justify it. You need a sensible role model and a bit of discipline.

A permission audit you can do in an afternoon

You do not need a consultancy engagement to get a clearer picture. Start with what you have.

1. Export or screenshot the full user list. Include roles, last login dates, and any accounts that look dormant.
2. List the tasks people actually perform. Separate content tasks from configuration tasks. Be honest about the tasks that only happen once a quarter.
3. Flag every shared login. If two or more people use the same account, you cannot tell who did what.
4. Count the administrators. Then ask, for each one, which configuration tasks they personally need to perform.
5. Review custom roles. If your CMS lets you create granular permissions, check what each role can actually do rather than what it was meant to do.
6. Test a high-risk action. Can an editor install a plugin? Can they change a user role? Can they edit global templates? If yes, decide whether that is intentional.
7. Write down the exceptions. There will be some. The point is to know what they are and who owns them.

A simple spreadsheet is fine. The audit is not the deliverable. The decisions are.

A simple role model for editors and administrators

Most mainstream CMS platforms can support a version of this model, even if the labels differ.

A practical setup usually has three or four groups: editors who create and edit content, publishers who can approve and schedule it, administrators who configure the CMS, and a read-only or auditor role for people who need oversight without the ability to change anything. Agency or developer access should be named, time-limited, and reviewed when the support arrangement ends.

If your CMS cannot separate these permissions cleanly, use workflow and environment separation to compensate. Editors can work in a staging site; administrators promote changes. It is not perfect, but it is better than giving everyone the keys because the role editor is too blunt.

Tightening access without slowing publishing

The fear with permission changes is that publishing grinds to a halt. That usually happens when the new rules are vague or when approval steps are added without warning. A few practical moves keep things moving.

• Give every person a named account. No shared logins, no generic 'webteam' account.
• Turn on multi-factor authentication for anyone who can publish or configure.
• Apply least privilege by default. Start with editor access and add permissions only when a specific task requires them.
• Use approval workflows for publishing rather than making everyone an administrator.
• Keep a staging environment for configuration changes and test there first.
• Use temporary elevation for one-off admin tasks, then remove it.
• Review administrator accounts quarterly. It takes ten minutes and prevents drift.
• Log high-risk changes and ask a second person to review plugin installs, template edits, and integration changes.
• Document exceptions so the next person understands why they exist.

None of this needs to be heavy. The aim is not to create a permission bureaucracy. It is to make the safe path the easy path.

The awkward conversation

If someone has administrator access because they are trusted, separating content and configuration can feel like a comment on their competence. It is not. It is about reducing the blast radius of mistakes and making the site easier to support. A good line to use is: 'We are not taking away your ability to do your job. We are making sure the CMS reflects the job you actually do.'

Small UK web teams do not need enterprise-grade role matrices. They need a clear line between editing the content and changing the machine. Draw that line once, review it now and then, and publishing gets no slower. It just gets easier to explain.