Every website has an answer to the question "who can change this?" On many sites the answer is "everyone with a login", arrived at not by decision but by accumulation: accounts created for a launch, permissions granted to unblock someone on a Friday, a shared administrator login that a departed colleague still knows. The site works, so nobody revisits it. This article is about designing that answer deliberately, so that the people who edit your site have exactly the access they need, and so that when something changes you can say who did it and when.
Roles are job descriptions
Drupal's permission system is built around roles: named bundles of permissions that are assigned to people. The design mistake is to think of roles technically, as lists of checkboxes. The useful way to think of them is as job descriptions. What does a content editor actually do on this site? Create and edit articles and pages, upload images, save drafts. What do they never need to do? Change site configuration, install modules, manage other people's accounts. A role written from that description grants the first list and nothing from the second.
Most organizations need surprisingly few roles. A typical set is an editor who creates and edits content, a publisher who can also make it live, a site manager who handles menus, taxonomies and other people's accounts, and an administrator, held by very few people, who can do everything. Specialized sites add roles for specific content: a shop manager for products and orders, a support agent for tickets, a translator for a language. The test for adding a role is whether a real group of people has a distinct set of tasks. If not, the existing roles are enough.
Least privilege, in practice
The principle is that each person holds the least access that lets them do their work. In practice this has three parts.
First, the roles themselves are minimal, as above. Second, people hold the roles their current job needs, and the roles change when the job does: the intern who became a marketing manager should not still have the intern's role plus three others. Third, powerful access is temporary where it can be. Someone who needs administrator access for a specific task can be granted it for the afternoon and have it removed after, which is far safer than a permanent grant that everyone forgets.
Drupal supports this well because roles are configuration: exported, versioned and deployed with the rest of the site. A change to what an editor may do is reviewed like a code change, tested on staging and released. Permissions stop drifting because they cannot change without leaving a trace.
Field-level and content-level control
Roles decide broad capabilities. Some sites need finer control: an editor who can change an article's body but not its publication date, a regional manager who can edit pages in their region only, a partner who sees their own documents and nobody else's. Drupal handles all of these through field permissions, content access rules and, where needed, small custom access checks that run on every request. Because the platform enforces them centrally, a rule applies everywhere the content appears: in the editorial interface, in listings, in search results and in API responses. There is no route around it.
This is the same machinery that makes portals and member areas practical. Public site and private application share one permission system, and a rule written once holds in both.
Who changed what, and when
Permissions decide what people may do. Audit trails record what they did. Drupal keeps a revision of every piece of content each time it is saved, with the author and the time, so any page can be compared with any earlier version and restored to it. We extend that to configuration: every change to the site's settings, roles, content types and views is exported and committed, so the history of the site's shape is as complete as the history of its content. And we log the administrative actions that fall outside both, such as logins, role changes and account creation, in logs stored outside the site.
Audit trails are rarely needed and enormously valuable when they are. They answer "why does this page say that?" in a minute. They turn "someone changed the menu" into a name and a timestamp, without accusation, because the answer is usually a reasonable person doing something reasonable that nobody else knew about. And they are what a customer's security questionnaire means when it asks about change management.
The review nobody schedules
Roles and permissions are set up once and then drift. People join and leave, jobs change, temporary grants become permanent by forgetfulness. The remedy is a short review, twice a year, that asks three questions: who has an account, does each person still need the roles they hold, and has anyone left? For sites we maintain, this review is part of the maintenance calendar, and it usually takes a client contact fifteen minutes to confirm the list. That quarter of an hour is one of the best security investments available.
Designing it for your organization
A good permission model comes from a conversation, not a template. We start by asking who works on the site, what each group actually does, and what would be a problem if it happened by accident. From that we propose a small set of roles, walk through them with the people who will hold them, and refine until the roles match the work. Then we implement, export, test and release, and the model becomes part of how the site is maintained rather than something that was configured once.
If your site's answer to "who can change this?" is longer than it should be, we can help you shorten it. It is a small project with a lasting effect, and the people who edit your site tend to prefer an interface that shows them only what they need.