Who Actually Has Access? How to Conduct an Access Audit in WordPress

Category: Website Security

Old user accounts are a common blind spot in WordPress. Employees change roles, agencies complete assignments, freelancers finish their work and integrations are replaced. Yet access often remains in place. The result is more possible entry points to the website than the organization has an overview of.

An access audit is about determining who and what can log in, what permissions they have and whether access is still necessary. It should not be limited to the user list in WordPress. The hosting environment, domain administration, code repositories, analytics tools, security services and systems that exchange data with the website must also be assessed.

The goal is not to remove access as a precaution. The goal is for every person and technical service to have the right access, in the right place, for as long as the need exists.

Start by defining what the audit covers

WordPress is rarely an isolated system. An administrator may be able to change content and install plugins, while someone with access to the hosting environment can modify files, databases and backups without logging in to WordPress.

Therefore, create a simple overview of the systems that can affect the website:

• WordPress users and roles
• hosting environment and control panel
• file transfer, command-line and database tools
• domain and DNS
• code repositories and deployment solutions
• backup and recovery
• monitoring and security alerts
• form, email, analytics and payment solutions
• integrations with CRM, ERP or other business systems

For each system, you should register an internal owner. The owner does not need to perform all technical tasks, but must be able to decide who should have access and who should be contacted in the event of an incident.

Distinguish between people and technical accounts

A good user overview distinguishes between personal accounts and accounts used by integrations, automation or operations. These must be handled differently.

Personal accounts should be linked to one identifiable person. Names such as “admin,” “web” or “marketing” make it difficult to know who actually made a change. Shared accounts also make access termination more difficult because the password must be changed for all users.

Technical accounts may be necessary when a system needs to publish data, monitor uptime or perform scheduled tasks. They should have a clear name, a documented purpose, an accountable owner and the minimum access necessary. An integration that only needs to read product information does not normally need administrator privileges.

If you cannot explain what an account is used for, it should be investigated before it is retained. Do not delete unknown technical accounts impulsively. Disable them in a controlled manner or test the consequences in a safe environment first.

Check permissions, not just usernames

It is easy to terminate the account of a former employee. The more difficult part is assessing whether active users have overly extensive permissions.

In WordPress, the administrator role should be reserved for people who actually need to change the website’s technical setup, manage users or handle plugins. A content producer usually does not need these capabilities. Editors can be given responsibility for content without also being able to install code.

Ask three questions about each user:

1. Does the person still need access?
2. Does the person need access to this particular system?
3. Does the person need all the permissions the account has?

Also consider how often the access is used. An external developer may need administrator privileges during a project, but not permanently. Temporary access should have an agreed end date and be removed once the work has been approved.

Make strong authentication a requirement

Access management loses much of its effectiveness if accounts are protected only by weak or reused passwords. All accounts with significant privileges should use multifactor authentication where possible. This applies not only to WordPress, but also to the email account used for password resets, the hosting environment and domain administration.

Users should have unique passwords stored in an approved password manager. Login details must not be shared by email, chat or documents. If a shared account cannot be avoided, the organization must have a controlled way to store, share and change the credentials.

At the same time, review the account recovery process. An attacker does not need to know the password if it is easy to take over the email account or trick customer service into resetting access.

Look for access outside WordPress

A tidy user list in WordPress does not necessarily mean that the website is well secured. A former provider may still have access to files or the database. A developer may have access through a code repository. An old integration key may still work.

Therefore, check:

• users and keys in the hosting environment
• access to the code repository and deployments
• active API keys and integrations
• who can change DNS and domain settings
• who can retrieve or restore backups
• recipients of security and operational alerts

Backups require particular attention. They may contain databases, personal data, configuration, and other sensitive information. Access to backups should therefore be treated as access to the production environment itself.

Connect the review to updates and vulnerabilities

Access management and technical maintenance are closely related. If no one knows who is responsible for an extension or integration, it is also unclear who should assess security updates and vulnerabilities.

Use the review to verify that each critical component has a responsible party. It should be clear who monitors alerts, who assesses the impact of an update, who tests it, and who can approve deployment.

A vulnerable extension should not remain in place simply because the original provider is still the only party with the necessary access. The organization must retain control of administrative accounts, licenses, technical documentation, and the ability to change providers.

Use logs to verify actual activity

The user list shows who can log in. Logs can show who actually has. During the review, you should investigate unexpected logins, changes to user roles, the creation of new administrators, and technical changes without a known work order.

It is also useful to look for accounts that have not been used for a long time. Inactivity is not automatically proof that an account can be deleted, but it is a clear signal that the need for it should be confirmed.

Monitoring must have a recipient and a response plan. An alert about a new administrator is of little value if it is sent to a closed email account or no one knows who should investigate it.

Establish a consistent process for onboarding, role changes, and offboarding

The most effective access review is one that gradually becomes less extensive because the day-to-day process works. Access should be managed as part of the employee's or provider's lifecycle.

When someone starts

• Create a personal account.
• Grant the minimum necessary role.
• Enable strong authentication.
• Record the system owner and purpose.
• Agree on an end date for temporary access.

When someone changes roles

• Remove access associated with the previous role.
• Assess new needs from scratch.
• Check access to external systems, not just WordPress.

When someone leaves

• Disable personal accounts promptly.
• Transfer ownership of content, integrations, and alerts.
• Change shared passwords and relevant keys.
• Remove access to operations, code, backups, and the domain.
• Document that the offboarding has been completed.

Document decisions in a simple access matrix

You do not need a heavy governance system to get started. An access matrix can include the person or service, system, role, justification, owner, approval date, and next review date.

The review itself should result in concrete actions, not just an updated list. Examples include downgrading an administrator to editor, retiring an old integration key, redirecting backup alerts to the correct recipient, or requiring multi-factor authentication before the next login.

Perform the review regularly and always after major organizational changes, provider changes, or completed projects. The website's importance and the number of users determine how often it is necessary.

Good website security starts with a simple question: Who can do what? When the answer is documented, verified, and tied to clear responsibility, updates, vulnerability management, backups, and monitoring all become safer to manage.