Most Drupal permission problems come from one shortcut: somebody needed to do one thing, got handed the administrator role to do it, and kept it forever. This lesson is the unhurried version — roles that match jobs, nothing extra, and a clean way to offboard people. You’ll need an admin account and the list of humans who touch the site. No code required, though we’ll note the drush shortcuts as we go.

Map the jobs before the roles

Before opening any admin screen, write a plain list: who touches this site, and what does each person actually do? Not their title — their tasks. “Sarah writes and edits articles. Tom publishes them and manages the menu. The intern fixes typos.” Each distinct job on that list becomes one role. If two people do the same job, they share a role; if one person does two jobs, they get two roles. Roles describe work, not people — that’s the whole design.

Build each role with least privilege

Go to People → Roles (/admin/people/roles), add a role per job, then open People → Permissions (/admin/people/permissions) and check only what that job needs. Two rules keep you honest:

Start from nothing and add, never start from everything and subtract.
Any permission flagged with a warning like “Give to trusted roles only” is Drupal telling you it can be used to take over the site. Believe it.

Then assign people their roles on each account’s edit page, or from the command line:

drush user:role:add 'editor' sarah@example.com

And retire the shortcut: nobody gets the administrator role because it was Tuesday and something was urgent. If a job needs one more permission, add it to the role — that’s the system working, not failing.

Test as the role, not as admin

Admins can’t see permission problems — every door is already open to you. Create a throwaway account, give it just the new role, and log in as it in a private browser window. Try the job: write the article, publish it, fix the menu. Also try what shouldn’t work, like reaching /admin/config. Fifteen minutes of this catches the gaps before your editor does, and “can’t publish on deadline” is a worse way to find out. (The Masquerade module makes this one click once you’re doing it often.)

Audit the dangerous permissions

Now flip your view: instead of “what can this role do,” ask “who can do this scary thing?” On the permissions page, check who holds Administer users, Administer permissions, Administer modules, and Administer site configuration — each of those is effectively full control, whatever the role is named. Or pull the list:

drush role:list

The answer for each should be a name you know and a reason you remember. Put a note on the calendar to repeat this quarterly; permissions only ever accumulate, like gear in a canoe you keep forgetting to unpack.

Retire accounts the right way: block, don’t delete

When someone leaves, block their account — don’t delete it. Blocking locks the door but keeps their name on everything they wrote; deleting can orphan or destroy their content, and Drupal’s cancellation screen offers some genuinely destructive options (“delete account and its content” means what it says). Blocking is one click on the account edit page, or:

drush user:block sarah@example.com

The account stays in the list, blocked, as a record — that’s a feature, not clutter.

You’re done when three things are true: every human has a role that matches their job and nothing more, the dangerous-permissions audit turns up only names you expect, and your test account proved each role can do its work. Do the audit again next quarter. It’s twenty minutes, and it’s the cheapest security work on the whole site.