A CMS administrator review should answer who can change site configuration, code, themes, plugins, users, content, and data through every access path. Export the current user and role list, map each account to a person or workload, inspect effective capabilities rather than titles, remove stale access in a controlled order, and verify both normal work and emergency recovery.
Define the full administration boundary
List every site, environment, and management plane: the CMS, hosting control panel, domain and DNS account, source repository, deployment service, database tool, file transfer account, backup console, analytics, forms, email delivery, and third-party plugins or apps. CMS access alone is not the whole website.
Record the site owner, operational administrator, backup administrator, hosting provider, and the business impact of losing access. Separate production, staging, and development identities when the platform supports it.
Export users, roles, and capabilities
For each CMS account, capture username, verified owner, role or roles, effective capabilities, last sign-in if available, multifactor-authentication state, creation date, purpose, and review decision. Include service users, API tokens, application passwords, single-sign-on groups, agency or collaborator accounts, and emergency accounts. Never place passwords, private keys, or recovery codes in the review sheet.
WordPress assigns capabilities through roles such as Administrator, Editor, Author, Contributor, and Subscriber. Its documentation says an Administrator has access to all administration features on a single site and warns that individual capabilities can grant broader access than their labels imply (WordPress roles and capabilities). On Multisite, Super Admin and site Administrator are materially different, so record the installation type.
Drupal likewise groups permissions into roles and notes that users receive the combined permissions of every assigned role (Drupal user guide). Review all roles together; a low-privilege role does not offset a second role that grants administration.
Match access to current tasks
Write the tasks each person performs: drafting, publishing, media upload, comment moderation, template editing, plugin installation, user management, configuration, exports, or network administration. Then map only the capabilities required for those tasks. Preserve a separate path for rare administrative work rather than making a daily content account a permanent full administrator.
Flag shared accounts, unknown owners, dormant contractors, former employees, generic `admin` identities, and accounts whose administrator role has no current task. Treat these as findings to verify, not as permission to delete immediately.
Drupal's security guidance for its special administrative account recommends using other named accounts for normal administration and granting only the permissions needed for administrative work (Drupal administrator security). The same separation principle is useful in other CMS platforms even when the account model differs.
Review non-user access
Inventory application passwords, personal access tokens, webhooks, deployment keys, database credentials, and hosting or support access that can change the site without a CMS login. Link each credential to an owner, workload, storage location, scopes, last-use evidence, rotation method, and expiration or review date. Store references, never values.
Check whether a plugin or page builder created custom roles or capabilities. Compare the live effective permissions with the CMS defaults; installing or removing extensions can change what a familiar role can do.
Change access safely
Back up the user and role configuration and confirm a tested recovery administrator before reducing access. Change one account or role at a time. For an uncertain account, suspend or remove the high-risk role first when the platform provides a reversible path, then observe through a normal work cycle. Avoid deleting content ownership with the user; follow the CMS process for reassignment.
Test the replacement role with a representative task. Confirm that content can still be drafted or published as intended, media and approvals work, and prohibited functions such as plugin installation, user administration, or configuration changes are no longer available. Test sign-out and sign-in rather than relying on an already-open session.
Verify recovery and evidence
Confirm that at least two authorized people can reach the documented recovery process without sharing a password. Verify host and domain access separately from CMS access. Record the final users, roles, removed sessions or tokens, test results, approver, timestamp, and next review date.
Completion check
The review is complete when every CMS and non-CMS access path has an owner, effective capabilities match current duties, stale or shared access is resolved, high-risk changes were tested with rollback, routine work still succeeds, and a protected recovery administrator remains available.
Sources
- Roles and Capabilities — WordPress.org
- Concept: Users, Roles, and Permissions — Drupal.org
- Securing the admin super user (#1) — Drupal.org