Start with tasks, not job titles
Website access often grows one quick request at a time. Someone needs to fix a page, so they receive an administrator account. Months later, that access remains even though their work has changed. A safer starting point is to give each person the least access needed for their actual tasks. This limits what an account can change, whether a mistake is made or the account is misused.
List the recurring website tasks before choosing permission levels. Who drafts pages? Who publishes them? Who updates plugins or settings? Who manages other users? A staff member who writes event descriptions may need to edit content but not install software or change billing details. A volunteer who checks a single campaign page may not need an account at all if they can send feedback another way.
Different website platforms name their roles differently, so check what each role can actually do. In particular, look beyond whether someone can edit a page: can they publish without review, delete content, upload files, change site settings, or create other accounts? Write down the smallest suitable role for each set of tasks.
Make individual accounts the default
Give each staff member their own account rather than sharing a general login. Individual accounts make it easier to remove one person's access without disrupting others and to understand who made a change. They also keep permissions tied to a person and a purpose, instead of to a password that may have been passed around.
Use an administrator role sparingly. A small organization might have one person responsible for routine site administration and a second trusted person who can help if the first is unavailable. An editor could manage published content without receiving control over technical settings. If a contractor is hired to update the site design, create a separate account for that work rather than lending them a staff member's login.
Where the platform supports it, require multi-factor authentication, especially for accounts that can publish, change settings, or manage users. Encourage unique passwords stored in a password manager. These safeguards do not replace careful permissions, but they help protect the accounts that hold them.
Use a simple process for access requests
A permissions process does not need to be complicated. When someone asks for access, record their name, the tasks they need to complete, the areas of the site involved, who approved the request, and when the access should be reviewed. Then choose a role that matches those tasks. If no role fits, consider whether the work can be done through an existing review process before granting broader access.
For example, a fundraising coordinator preparing a new appeal might need to draft and revise a landing page. A colleague with publishing permission can review and release it. The coordinator does not need administrator access simply because the page is important. If they later take responsibility for publishing all campaign pages, that is a new request with a clear reason to reconsider their role.
Temporary work deserves an end point. Note when a contractor's project is expected to finish, and set a reminder to remove or reduce their access afterward. If the platform allows time-limited permissions, use them; otherwise, a calendar reminder and a named account owner are a workable alternative.
Review access when work changes
Permissions should change when people's responsibilities change. Build an access check into onboarding, role changes, project handovers, and departures. Before someone leaves, identify any website tasks only they perform and move those responsibilities to another person. Then disable or remove their account promptly according to your organization's process.
A periodic review can catch access that no longer has a purpose. Open the platform's user list and, for each account, ask: Who is this? Do they still need access? Is this the right role? Pay particular attention to administrators, former contractors, inactive accounts, and accounts with names nobody recognizes. Investigate an unfamiliar account before deleting it, since it may support a legitimate service or workflow.
Keep a short record of changes so the next person responsible for the site can understand them. A simple access register with names, roles, reasons, approvals, and review dates is often more useful than an elaborate policy that no one maintains.
Check the boundaries beyond the website
The website login may not be the only route to important changes. Hosting, domain registration, analytics, email marketing, backups, and payment services can each have separate accounts. Review those permissions using the same task-based approach. Someone who needs to read website traffic reports, for instance, may not need permission to change analytics settings.
Finally, make sure the organization can recover access without relying on one person's private email address or device. Keep recovery details in an organization-controlled process, protect them carefully, and confirm that the right people know how to use them. The goal is not to make everyday work difficult. It is to make useful access easy to request, clear to approve, and straightforward to remove when it is no longer needed.
