A website maintenance access audit should cover every control plane, not only the content-management system. Inventory CMS users, hosting and domain accounts, DNS and CDN access, source repositories, deployment services, analytics, forms, email delivery, backups, and third-party maintenance vendors. For each entry, identify an owner, role, business purpose, and end date.
Start with the CMS roster
List every user and role, including accounts that appear dormant. In WordPress, the Users screen supports finding users, filtering them by role, changing roles, and deleting users. See the WordPress Users screen documentation. Compare this roster with the people and services that are currently authorized to maintain the site.
Do not assume two role names have similar powers. WordPress defines six standard roles, and their capabilities differ substantially. An Administrator can reach all administration features on a single site, an Editor can manage and publish posts including other users' posts, and an Author can manage and publish only their own posts. WordPress also notes that the `edit_theme_options` capability is the primary control for Site Editor access and can grant access to other theme-related administration. Review the exact role and capabilities in Roles and Capabilities.
Trace access beyond WordPress
Record who can change DNS, renew or transfer the domain, edit hosting settings, read backups, push code, change environment variables, install integrations, view analytics, and alter payment or form destinations. Check group membership and inherited access in each service. A developer removed from the CMS may still be able to redeploy the site or change its domain.
Create a simple responsibility map. Content editors may need page and media access but not plugins or DNS. A deployment account may need a narrowly scoped token but no interactive administrator login. The business owner should retain a documented recovery route for the domain and hosting account. Do not rotate credentials or transfer ownership during an audit unless that action is separately approved and a recovery path has been verified.
CISA recommends removing unnecessary accounts, periodically reviewing whether access remains needed, and giving accounts only the minimum permissions required. Use those principles to classify findings as keep, reduce, remove, or investigate. See CISA hardening guidance.
Check evidence before changing access
Review available user-management events, repository history, hosting audit logs, domain change history, and recent deployments. Match privileged changes to a maintenance ticket or owner decision. Preserve a dated inventory before removing access so an accidental lockout or broken automation can be diagnosed. Do not treat a missing log entry as proof that an account was unused; some services retain only a limited history.
Verify revocation and continuity
After approved changes, test low-risk operations with representative roles. Confirm that an editor can update draft content but cannot change restricted configuration, that an administrator can still perform emergency maintenance, and that removed accounts and old tokens fail. Check that scheduled backups, deployments, forms, and monitoring still work because those processes may depend on service accounts.
Finish with an exceptions list and next review date. The result should show who can change content, code, infrastructure, and ownership; why each permission exists; and how the site can be recovered if a key maintainer becomes unavailable.
Sources
- Users screen — WordPress.org
- Roles and Capabilities — WordPress.org
- Enhanced Visibility and Hardening Guidance for Communications Infrastructure — Cybersecurity and Infrastructure Security Agency