The employee left, the agency contract ended, and the website kept working. Months later, nobody can explain which accounts still have administrative power or who receives recovery messages. That is not necessarily evidence of an attack. It is evidence that access decisions have become detached from the business relationships that justified them.

A website admin access audit should reconnect those decisions without locking out the people who need to operate the business. Begin with an authorized inventory, distinguish ownership from permission, and plan changes in a safe order. Deleting unfamiliar accounts first and asking questions later can destroy useful evidence or break essential work.

Map the doors around the website

The WordPress user list is only one part of access. Hosting, domain registration, business email, payment services, analytics, backups, and integrations may each have their own users and recovery routes. Someone without a website login may still influence the site through a connected service or the account that controls its environment.

Start by identifying the systems that can affect the public website, its information, or its availability. Record the business owner, responsible provider, and authorized route for reviewing access in each. Do not collect passwords or recovery codes into the inventory. It should explain control and responsibility, not become another sensitive credential store.

For a fictional print studio, this map might reveal that a former coordinator receives domain renewal notices while the current owner controls the website itself. Removing the coordinator’s website account would not resolve that dependency. The business must review the separate domain relationship with the authorized provider and establish a legitimate replacement route.

Clarify the relevant web hosting responsibilities before assuming a developer can change everything. A hosting account may belong to the business, a supplier, or a managed arrangement with defined limits. Establish authority and scope through the proper parties rather than interpreting technical access as permission to take ownership.

Build an account list that answers a business question

For each account, record its role, intended user or service, business purpose, approving owner, and whether access is still required. Note the source of the information and any uncertainty. An unfamiliar name needs investigation, not an automatic label of malicious activity. A familiar name does not prove the permission remains appropriate.

NIST’s Security and Privacy Controls, Revision 5 includes account management, least privilege, and personnel termination controls. These provide useful principles for a proportionate review. They are not a requirement that every small business copy a federal control catalog verbatim or a certificate that a completed spreadsheet makes the website secure.

Read the list against current work. Can the content editor do the assigned task without installing software? Does a short-term contractor still need unrestricted administration after delivery? Are there accounts nobody can associate with a current purpose? Record proposed decisions with the accountable owner before implementing them.

Separate a person from an automated service. An account used by an integration may not resemble an employee name, but removing it could interrupt a legitimate process. Conversely, calling an account service does not justify unexplained power. Find its purpose, scope, technical owner, and supported replacement or revocation method.

Hands sort blue and orange geometric cards into separate groups beside a laptop and black pen.

Establish reliable business control before removing old routes

Identify at least the necessary authorized people who can administer the relevant service and complete its supported recovery process. Avoid making one employee’s personal inbox or phone the only way back into an essential system. The appropriate arrangement depends on the service and the business, so confirm what its account model actually supports.

Ownership is not just a role label. The business may need access to billing, contract records, domain contacts, or an organizational owner function separate from everyday administration. Document the distinction and arrange legitimate transfers through the provider where necessary. Do not attempt to assume an account by borrowing a departed person’s identity.

Before changing recovery details, verify the new route through the service’s authorized process. Coordinate timing and required approvals. If the business cannot establish legitimate control, escalate to the responsible provider rather than disabling the only working administrator and hoping support can reconstruct the situation afterward.

Treat this as continuity work, not permission to retain every old user indefinitely. The aim is a safe transition to an appropriate arrangement. Record temporary exceptions with a reason, responsible owner, and review point, especially where a supplier must complete a dependency before its access can be reduced.

Shared logins hide several different problems

A shared administrative login makes it harder to associate actions with a particular person and to remove one person’s access cleanly. Where the service supports it, use individually attributable accounts with roles suited to the work. Do not preserve an all-powerful shared login simply because creating proper invitations feels inconvenient.

Changing a shared password may be necessary during a transition, but it is not a complete access review. Recovery routes, active sessions, application passwords, tokens, and connected services can have separate behavior. Ask the responsible administrator which access mechanisms exist and what the provider’s supported process does or does not revoke.

NIST’s July 2025 Authentication and Authenticator Management guidelines address authentication, account recovery, and session management. These are related but distinct concerns. Strong authentication helps establish control of an account; it does not decide whether that person should retain administrative authority after the business purpose has ended.

The same distinction applies to multi-factor authentication and passkeys. Review suitable methods and recovery arrangements with qualified support, but do not treat a stronger login method as a substitute for removing unnecessary privilege. A former contractor who can authenticate securely may still have access the business no longer intends to grant.

Offboarding needs an order of operations

Coordinate the approved access change with the relevant employment or supplier process. Identify responsibilities that must transfer, information the business must retain, and services that depend on the departing person’s account. Timing may be sensitive and should be determined by authorized leadership with appropriate professional advice.

For the fictional print studio, an ordinary handover might include assigning a new content reviewer, transferring a reporting destination, and replacing an integration authorization through its supported process. Those steps differ from simply deleting a user. The technical administrator should explain which actions disable access, which change ownership, and which affect stored content.

Retain appropriate business records while respecting privacy and applicable obligations. A website review is not permission to browse an employee’s unrelated information or export everything into an unsecured folder. Define what must be preserved, who may access it, and how the authorized transition will be documented.

After the approved changes, verify the intended outcomes using supported administrative evidence. Do not test by impersonating the former user or asking someone to share their authentication factors. Confirm that authorized staff can still perform necessary work and that the reviewed access routes reflect the approved decision.

A woman in mustard works at a laptop among blue and coral paper stacks while a coworker in teal sorts samples behind.

Close indirect routes without breaking integrations

Connected services can preserve authority after an obvious login disappears. Review delegated applications, API credentials, deployment access, and recovery dependencies where relevant to the actual setup. Keep the review within authorized scope and use each provider’s supported management tools. An inventory of secret values is neither necessary nor desirable for the editorial decision record.

For every integration, ask what it does, whose authorization it uses, and what happens when that authorization changes. If a customer enquiry integration relies on a departed employee’s account, the replacement should be planned and tested through an approved route. Revoking first may stop the process without telling the business why enquiries have disappeared.

Not every connection can be reduced in the same way. Some services support narrowly scoped credentials; others require a different account or subscription arrangement. Have the responsible specialist explain the available options and limitations. Record residual dependencies instead of describing an integration as fixed merely because someone renamed its account.

A useful review also considers suppliers that remain engaged. They may need temporary administrative access for a particular change but a lower routine role afterward. Agree how access is requested, approved, limited, and reviewed. The objective is appropriate ongoing access, not making every supplier repeatedly fight an improvised lockout.

Suspicious activity changes the job

An unexplained account, unexpected recovery change, or unfamiliar privileged action may require incident investigation rather than routine cleanup. Do not announce compromise solely from a name you do not recognize. Equally, do not erase relevant records or quietly reset everything before qualified people can assess what happened.

NIST’s April 2025 incident response recommendations connect investigation, evidence, response, and recovery within risk management. Apply the relevant principles through an agreed response role. Preservation and containment decisions depend on the circumstances; this article is not a forensic procedure or a substitute for specialist advice.

Escalate through the business’s approved contacts and protect sensitive findings. Record what was observed, when it was discovered, and what authorized action followed, without spreading unsupported conclusions. Employment, contractual, notification, and legal decisions may require advisers outside the website maintenance relationship.

Motta Industries’ trust and security information can inform a discussion about responsibilities and expectations. A public statement does not establish that a particular account has been reviewed, that an incident has been investigated, or that every connected service is covered by the same provider.

Make the record useful without storing secrets

The review record should let another authorized person understand the decision later. Identify the service, account reference, approved purpose, responsible owner, and evidence used to verify the change. Do not include full credentials, private recovery material, or unnecessary personal details. Limit access to the record itself because even a list of administrative relationships can reveal sensitive operating information.

Distinguish proposed, approved, implemented, and verified changes. Those states answer different questions: a manager’s approval does not prove a provider completed the work, and an administrative change does not prove the business task still functions. Keep unresolved dependencies visible until the responsible person supplies the appropriate evidence, rather than treating a closed email conversation as completion.

Turn cleanup into a repeatable access decision

Keep a concise record of the approved account purpose, role, owner, and next review trigger. A staff departure, supplier change, new integration, or material responsibility change should prompt the relevant review. An occasional full check can catch overlooked relationships, but event-driven updates keep the list connected to daily operations.

Ask how access review fits into website maintenance, including what the provider can inspect and what requires another account owner or specialist. Agree the boundary explicitly. The business should not assume hosting, email, domain registration, and website users are all governed by one maintenance promise.

The useful outcome is not the smallest possible user count. It is a defensible explanation for necessary access, reliable business control, and safe removal of authority that no longer belongs. Begin with one critical service, find its legitimate owner, and follow every meaningful route by which someone can still administer it. Review permissions, not appearances.