Who should get admin access? Roles for staff, freelancers and agencies

Ask a small business owner who can log into their website as an administrator and the honest answer is often "I am not sure". Over the years an agency, a freelance designer, a cousin who helped with the logo and two former employees have all been given admin access, and nobody wrote it down. This article is about the decision itself: who genuinely needs the top level of access, what to give outside helpers instead, and how to take access back when the work ends.

The aim is not suspicion. It is being able to answer, at any moment, exactly who can change your website and why.

The one account you must own yourself

Before anything else, make sure the business controls the root of everything: the domain registrar account, the hosting account, and the primary administrator login on the website. Register these under a company email address that you control, such as one on your own domain, and never under a developer's personal account.

This matters most when a relationship ends badly or simply goes quiet. If the domain sits in an agency's account, moving your site elsewhere can turn into weeks of chasing. If a freelancer registered the hosting on their card, renewal notices go to them. Ownership of these three things is the difference between an inconvenience and a hostage situation.

Keep the recovery email and phone number on those accounts current, and make sure at least one other trusted person in the business can get in if the owner is unavailable.

Staff: give the job, not the keyring

For employees, the question to ask is what they will do on the site this month. A content writer needs to write and submit posts. A sales executive needs enquiries. Neither needs to change payment settings or install plugins.

• Every person gets their own named account, never a shared one.
• Match the account level to the daily task, not to seniority. A manager who never touches the site does not need a login at all.
• Reserve full administrator rights for one or two people who genuinely manage the site.
• Turn on two-factor authentication for anyone above basic content access.
• When someone changes department, change their account level the same week.

If somebody needs higher rights for one specific job, raise their level, note it, and lower it again when the job is done. Temporary is fine; permanent by accident is the problem.

Freelancers and agencies: scoped and time-bound

Outside help usually does need real access to do real work. The goal is to make that access specific and temporary rather than open-ended.

Agree the scope before sharing a login

Write down, even in a short email, what the person will work on, what access that requires, when the engagement ends and what happens to the account on that date. This avoids the awkward conversation later and gives you a record.

Practical ways to limit exposure

• Create a separate account in the freelancer's own name or email. Never share your own credentials.
• Where the platform allows it, give the narrowest role that covers the work, and raise it only if they hit a genuine block.
• Let developers work on a staging copy of the site rather than the live one for anything substantial.
• For server work, create a separate hosting user or SSH key for them instead of handing over the main password, and remove the key afterwards.
• For payment gateways, analytics or ad accounts, add them as users on those platforms rather than sharing your password.
• Avoid giving access to your business email account; if they need to configure email, do it together on a call.
• Set a calendar reminder for the end date so review happens even if the project slips.

Agencies often ask for a single shared login for their whole team. Push back politely and ask for named accounts per person, or at minimum a written list of who will use it. If someone leaves that agency, you want to know.

Data access deserves a separate decision

Editing the site and reading customer data are different things. A designer adjusting a layout rarely needs to browse thousands of customer phone numbers, addresses and order histories.

Where your system allows it, keep customer data out of roles that do not need it, and use masked or sample data on staging copies. If personal data must be shared with an outside party, include a clause in the contract about confidentiality, permitted use and deletion at the end. India's Digital Personal Data Protection Act, 2023 places responsibility on the business that collects the data, and your obligations do not transfer to a vendor just because they hold the login. For specifics that affect your business, confirm with a qualified professional.

Closing access without breaking the site

When an engagement ends, work through a short sequence rather than just deleting an account in a hurry.

1. Collect the deliverables first: source files, design assets, documentation and any accounts created on your behalf.
2. Deactivate or delete their website account, and reassign any content that would otherwise be orphaned.
3. Remove their SSH keys, hosting users, database users and any API tokens they created.
4. Change shared passwords they knew, including the hosting control panel and any email account used for testing.
5. Remove them from third-party platforms: registrar, CDN, payment gateway, analytics, ad accounts, code repository.
6. Check the login and activity logs a week later for attempts from their old account.
7. Update your written access list so it matches reality again.

Do this even when the parting is friendly. It is housekeeping, not an accusation, and most professionals expect it.

Build your access list this week

Open a simple sheet and write one row per person or company with access: name, what they can reach, why, who approved it and a review date. Most owners find at least two entries they had forgotten. Remove those, then keep the sheet current whenever someone joins or leaves.

If you are taking over a site and cannot tell who holds what, our team can help you audit and reset access safely; see our website development and maintenance services or start with a support request.

Frequently asked questions

Should I give my web developer the domain registrar password?

Usually no. Most registrars let you add a separate user or delegate specific tasks. If that is not possible, make the change together rather than handing over the main account.

What if an agency refuses to hand over access after a project?

Keep written proof of ownership and payment, and check that the domain and hosting are in your name, since those give you real leverage. Raise it in writing first; for anything beyond that, take legal advice.

Is it safe to give a freelancer access to the live website?

For small edits it is usually fine with a limited account and backups in place. For redesigns, migrations or plugin changes, a staging copy is safer for both sides.

How often should I check who has access?

Once a quarter is enough for most businesses, plus immediately whenever someone leaves or a project finishes. The check takes a few minutes once your list exists.