Hosting Account Access Records: Knowing Who Can Change Your Site
Most small sites run for years on access that nobody fully remembers granting. The developer who set up the server has moved on, a former marketing hire still has a login, and the billing email points to a mailbox that no one checks. None of this shows up as a problem until something needs changing, renewing, or recovering. An access record is a simple document that answers who can do what on your hosting account, how those permissions were granted, and what happens if the person responsible becomes unavailable. This article walks through how to build one, what to include, and the questions to ask before you trust a setup you inherited.
Why Access Records Matter More Than Passwords
A password manager tells you where a secret is stored. It does not tell you who is supposed to hold it, why they hold it, or whether they still should. For a hosting account, the important questions are about roles: who can log into the control panel, who can open support tickets on behalf of the company, who receives renewal and billing notices, and who can change DNS or upload files. Those roles often drift over time without anyone deciding to change them.
Small teams tend to share a single login or a shared inbox because it is convenient in the short term. The cost shows up later, when a departure leaves no clear owner or when an unexpected charge goes to an address nobody reads. A written access record turns these informal arrangements into something you can review, correct, and hand over.
What to Include in a Hosting Access Record
Start with the account itself. Record the provider name, the account identifier as shown in your dashboard, the primary administrative email, and the billing contact. Note the plan type, such as shared hosting, managed WordPress, or a VPS, because the access model differs between them. A shared plan may expose a single control panel login, while a VPS usually involves SSH keys, a root or sudo user, and separate application credentials.
Next, list every person or service with access. For each entry, capture the name or role, the type of access (panel admin, file access, database access, DNS editing, billing), the date it was granted, the reason, and who approved it. Include automated access too, such as deployment tokens, backup integrations, and monitoring services. These are easy to forget because they do not appear as people, yet they often hold the most powerful permissions.
Finally, record recovery paths. Note which email addresses and phone numbers are attached to the account for password resets and two-factor recovery. Note where backup codes or recovery keys are stored and who can retrieve them. A record that lists permissions but not recovery is incomplete, because the question you will eventually face is not only who has access today but how access gets restored when someone is locked out.
A Practical Review Routine
Once the record exists, it needs a schedule. A quarterly review is reasonable for most small teams: open the provider dashboard, compare the list of active users against your record, and mark anything that no longer matches. Look specifically for accounts tied to people who have left, shared logins that have multiple unknown users, and billing contacts that do not match a current inbox.
During the review, check the notification settings as well. Confirm that renewal, billing, and security-related emails reach a monitored address and that more than one person can see them. Hosting renewals and payment failures are easy to miss when they land in a single person's inbox during a vacation or after a role change.
Keep a short change log beneath the record. Each time access is granted or removed, add a line with the date, the person, the change, and the reason. Over a year, this log becomes the most useful part of the document, because it shows the reasoning behind decisions that otherwise exist only in someone's memory.
Questions to Ask Before You Trust an Inherited Setup
If you take over a site from someone else, start with the questions that reveal ownership. Who is the registered account holder? Which email receives account and billing notices? Are there any users on the account you cannot identify? Is there a documented recovery method, and does it point to an address you control? If you cannot answer these within a few hours of looking, treat the setup as a risk to resolve before making other changes.
Then ask about the plan itself. Does the current plan match how the site is used, or was it chosen for a previous project? Are there separate environments for testing and production, or is everything changed live? Are there scheduled tasks or cron jobs whose owner is unclear? Each unknown item is a candidate for the access record, and each should get a name and a purpose before anyone removes it.
A Short Checklist for Small Teams
Use this as a working list rather than a formal audit. First, confirm the account owner and the billing contact, and make sure both point to addresses that more than one person monitors. Second, list every active admin, file, database, and DNS user, including automated tokens, and match each one to a current person or purpose. Third, verify recovery methods: the reset email, the phone number, and the location of backup codes. Fourth, check that renewal and payment notifications reach a shared inbox. Fifth, remove or disable access that cannot be justified, and log the change. Sixth, schedule the next review on the calendar before closing the document.
The goal is not perfect security documentation. It is a record that a capable person who was not involved in the original setup could read and act on. If your team can answer who controls the account, how access is recovered, and when it was last reviewed, you have the basic ownership picture that most outages and handover problems lack.