Shared Hosting Security Checklist: Who Owns Each Control

A shared hosting security checklist names one owner and one piece of evidence for each control a small business can see. The controls are the domain account, the hosting panel, WordPress users, everyday access, backups, and incident contacts. Editorial review date: 10 October 2026. The original publication date is unchanged. Updates, access control, and reducing exposure are layers. Each layer can shorten an outage or limit who holds a powerful login. There is no absolute prevention here. The layers do not prevent every attack.

Shared hosting security checklist

An owner is a person you can reach this week. A job title is not an owner. Evidence is a screen, a dated note, or a phone number that still connects. If that evidence is missing, leave the row open so the next reviewer sees the gap.

The domain registrar login can move the name, renew it, or start a transfer. On a small team it often still belongs to whoever paid the first bill. Evidence is the account email, the recovery phone, and the date of the last successful sign-in. Recovery access is the inbox and the phone the registrar uses when the daily password fails. If that inbox belongs to someone who left, point it at a current person and write both channels beside the owner.

Strong authentication on the registrar is a unique password in a manager the business controls, plus a second sign-in step where the registrar offers one. Recovery codes stay with the recovery contact, not in a chat. Least privilege keeps transfer rights with the owner. A name-server change uses a limited user where one exists, or a request to the owner where it does not. Editing pages on the website does not include the power to give the domain away.

The hosting panel login is a separate account. It creates mailboxes, shows files, and opens the tools that manage the site. Evidence is the user list with the owner marked and extra users named. Least privilege means a person who reads mail is not an account administrator. Unused accounts are their own row: list each panel user with no task this month, remove or disable that user, and date the list. If the host has no second sign-in step, write that limit in the evidence so the gap stays visible.

An illustrative case: a three-person Abbottabad clinic kept one panel password in a family chat group. The doctor, the receptionist, and a cousin who helped with the website all signed in as the same user. The cousin left the chat. The password stayed. A Sunday sign-in could not be tied to a person, because the panel knew only one name. The clinic is illustrative. The panel row asks for one living owner and a date on every extra user.

Everyday user access covers the people who sign in for mail, page edits, or orders. Each person needs a login of their own. A login shared across a desk makes the user list useless, because the list cannot say who acted. When a job changes, the access list changes the same week. The owner of this row can add and remove those logins, and the evidence is the dated list of who still has one.

WordPress admin count is the number of accounts that can install software, change themes, or create users. Read it on the Users screen on a chosen day, then write the names and the date. A small staff often needs one administrator and a second named administrator for recovery. Everyone else receives the role that matches this month's work. A shared administrator login hides several people inside a count of one, so split those accounts and count again.

Unused WordPress accounts include old form addresses, authors who published once, and agency administrators after the contract ended. Choose delete or disable, and record the date. Deleting can move posts to another user, so decide before anyone acts. This page does not give production configuration commands. Strong authentication for each remaining administrator is a unique password and a second step where the site can ask for one.

The WordPress hardening documentation is background on accounts, updates, and related habits. The person who owns the admin count can read WordPress hardening documentation before changing roles. The evidence is still the dated tally. A shorter list reduces exposure. It does not prevent every attack.

Backup location is the screen, the off-site store, or the person who can request a download, together with the newest copy's date and the two people allowed to retrieve it. Recovery access is the second of those people. If only one person can fetch a copy, write that in the row so the limit is visible.

A finished backup is not a proven restore. The archive can look complete and still fail on the file you need. A restore drill takes one file from a backup onto a copy of the site, or into a folder that is not the live site, and checks that the file opens. Record the last restore date, the file name, the person, and the result. If the drill fails, leave the date blank and write the failure.

The WordPress backup documentation explains why files and the database belong in one recovery story and why a test belongs with the copy. Send the drill owner to WordPress backup documentation before week 3. Your evidence is the date you recorded.

Incident contacts are the people you call when the site shows a page you did not publish, when mail goes out that nobody sent, or when customers cannot reach you. The incident phone is a named person, a second number, and the hours they answer, written on the same sheet as the registrar owner. Add the host channel and the registrar channel, each with the account identifier and the person allowed to open a ticket. Someone off the account may be turned away. Recovery access includes being recognized by those desks.

A business can place pro support beside the internal incident owner when it wants a technician on a ticket. The internal name stays. The technician works inside the access you grant and does not become the registrar owner by joining a call. Panel changes still need the panel owner.

Updates reduce exposure from flaws maintainers have already patched. Run them on a copy of the site first. Open the front page, the contact path, any booking or shop path, and the staff sign-in. Record the version you started from, the version on the copy, and what failed. Updates, access control, and a tested copy are separate layers. The update owner is the person who writes that note.

shared hosting is the setting for the sheet. The business does not run the whole server, and other customers share the machine. Reachable controls are the logins you hold, the WordPress users you created, the copies you can obtain, and the phones you list. Controls that live only on the provider's platform stay off the sheet until you have them in writing.

When someone leaves, move the rows they own in the same week: registrar recovery, panel user, WordPress role, backup retrieval, and the incident phone. The new owner sets a fresh password on each account the leaver held. Record the new name and the date. Keep the sheet where two current staff can open it, and keep passwords off the sheet. A sheet that lives only on the site will be missing when you need to recover.

Owners and evidence

Fill one row per control. The owner is a person the office can call. The evidence is something a later reviewer can open without guessing.

A 30-day review

Repeat the sheet every 30 days. Week 1 is the access list: the registrar, the panel, the WordPress administrators, and unused accounts, each with a keep-or-remove decision written that week. Week 2 is updates on a copy. Record versions and failures on the copy before anyone discusses the live site. Week 3 is the restore of one file from backup. Record the last restore date only when that file opened and matched. Week 4 is the contact check. Ring the incident phone and the second number, and confirm the host channel and the registrar channel still match the account. A week you skip stays blank.

Finishing the four weeks means you looked. It does not mean a login, a plugin, or a mailbox will resist every misuse. A quiet month is not proof that the layers were unnecessary. This page assigns owners and evidence. It is not legal advice.

Write the owner's name next to the registrar login this week. Add the recovery email and the recovery phone on that same line. If you cannot name the person, the other rows may describe accounts outside your reach. Date the line, and keep the sheet where the incident contacts can find it without signing in to the site.