Vendor Access Checklist: Before You Give Someone Website Admin Rights

Developers, agencies, hosting support teams and security providers often need access to fix problems or improve a website. Giving access is normal. Giving broad, permanent access without a plan is where risk begins.

This checklist helps business owners share the right access for the right amount of time, while keeping ownership and accountability with the business.

Define the job before sharing access

Access should match the task. A designer updating images may not need hosting access. A developer fixing a form may need code and logs but not domain transfer rights. A security reviewer may need read-only records before requesting higher access for cleanup.

Write the task in one or two sentences before creating accounts. Include the system involved, deadline, expected deliverable and who approves changes.

NIST's small business quick-start guides are written as a starting point for small, under-resourced organisations. Vendor access is a good place to apply that thinking: decide the risk, choose the control and record the owner.

Use named accounts and roles

A named account tells you who made changes. A shared admin account hides that history. Create individual accounts for vendors where the platform supports it, and choose the least role that allows the work.

For WordPress, that may mean an editor account, a full administrator or temporary support access depending on the task; the roles and capabilities reference lists what each role can do. For hosting, it may mean collaborator access instead of handing over the main account password. For DNS, it may mean specific record changes performed by the business after vendor instruction.

Ask the vendor whether they support MFA and how they manage staff access on their side. Our MFA and password guide sets out what good looks like.

Keep domain and billing ownership with the business

Vendors can help manage technical settings, but domain ownership and billing recovery should remain under a business-controlled account. If an agency relationship ends, you should still be able to renew the domain, update DNS and access hosting invoices.

The NCSC's supply chain security principles follow the same shape: understand the risk a supplier brings, establish control over what they can reach, and check the arrangement again over time. Ask those questions of agencies and contractors, not only of software suppliers.

If a vendor registered the domain for you years ago, move it into a business-owned account before there is a dispute or emergency. The domain and DNS security basics guide covers the steps.

Share secrets through a safer channel

Do not send passwords, API keys, database exports or private customer data through ordinary email or a public quote form. Use temporary credentials, password-manager sharing, provider collaborator features or another agreed secure process.

Rotate credentials after emergency work. Remove temporary access after the task is complete. Review whether any keys were copied into code, tickets, screenshots or chat messages.

For sensitive systems, ask whether logs show when the access was used.

Record what changed

Every vendor task should end with a short note: what was changed, where it was changed, which accounts were used, what still needs attention and whether access can be removed. This does not need to be formal; it needs to be findable later.

For security work, ask for a clearer cleanup or hardening summary. If malware was removed, the business should know what symptoms were found, what files or settings changed and what follow-up monitoring is recommended.

That record helps future developers avoid undoing important work.

Remove access when the work is done

Access removal is part of the project, not a someday task. Set a calendar reminder when access is created. Review vendor accounts monthly or quarterly, especially after staff changes, website relaunches and emergency incidents.

If the vendor still needs ongoing access, confirm why, who owns it and whether it remains protected with MFA.

Vendor access checklist

• The task and systems involved are clearly described.
• The vendor receives the minimum access needed for the work.
• Named accounts are used instead of shared admin credentials.
• MFA is enabled wherever supported.
• Domain, billing and recovery ownership stay with the business.
• Secrets are shared through an agreed secure channel.
• Changes are documented before the task is closed.
• Temporary access is removed or reviewed after completion.

Before the next vendor engagement, write the one-paragraph task description and decide which named account the vendor will receive; the rest of the checklist follows from that. A written scope of this kind is also what we ask for before a security assessment, and the first message never needs to contain a password.

Editorial note: this article was prepared with AI assistance and checked against NIST, NCSC and WordPress.org guidance. It is general guidance and should be adapted to your contracts, platform and compliance obligations.