Wizard.Business Support

Operations

How to Securely Share Business Access With a Virtual Assistant

A practical small-business guide to granting a virtual assistant the access they need—without handing over your master passwords or leaving old permissions behind.

When a virtual assistant needs to update orders, schedule posts, or manage your inbox, the easiest option can seem to be sharing your own login. Resist that shortcut. To securely share business access with a virtual assistant, give them an individual identity, only the permissions needed for agreed work, and a clear process for changes and removal. These steps make access easier to review and reduce avoidable exposure without promising that any setup is risk-free.

Start with the task, not the password

Before inviting anyone into a system, write down the specific task they will perform, the information it touches, and the actions they must take. For example, an assistant who drafts customer replies may need access to a shared support queue but not the ability to export the customer list, change billing settings, or delete the account. A task-based description turns a vague request for “admin access” into a concrete permission decision.

Use a simple decision rule: if the work can be completed with viewing or drafting permissions, do not begin with editing or ownership privileges. If the platform cannot separate the needed action from broader powers, pause and look for an alternate workflow, such as having the assistant prepare a change for your approval. Document the limitation so neither person is tempted to improvise with a personal login later.

  1. Name the task and the system involved.
  2. Identify the minimum actions and data needed.
  3. Mark actions that require owner review, such as payments, user deletion, or security changes.

Create a named account for each person

Where a service supports multiple users, invite the assistant using an individual account rather than sharing the owner’s username and password. A named account makes it clearer who performed an action, lets you change one person’s access without disrupting everyone, and avoids exposing the owner’s recovery details. Use a work email identity where appropriate, and confirm the invitation is going to the intended person before granting privileges.

Avoid generic shared logins such as “assistant1” if the platform offers individual users. If a system truly supports only one login, do not assume that makes credential sharing safe. Check whether an approved password manager offers a controlled sharing feature, whether a separate staff profile or delegated role exists, or whether the work can be done through another service. Keep any exception limited, documented, and reviewed.

Apply least privilege and narrow the scope

Least privilege means granting only the access needed for a defined job, and only for as long as that job requires it. Choose the narrowest role available: for instance, a store assistant might need to prepare product descriptions and manage draft listings, while price changes, refunds, payouts, and user administration stay with the owner. In email or file storage, share a specific folder or mailbox rather than an entire drive when the narrower option works.

Consider both permission level and reach. Read-only access may still expose sensitive records; edit access may allow accidental changes; administrator access can affect other users or account recovery. If you are uncertain what a role permits, review the service’s permission description or test in a low-risk area first. Keep a short record of who has access, to which system, for what purpose, and who approved it.

  1. Prefer a limited role over administrator access.
  2. Share selected folders, projects, or queues instead of a whole workspace.
  3. Keep high-impact actions owner-controlled unless the task truly requires delegation.

Use an approved password manager for exceptions

A password manager can help create and store unique credentials and, where supported, share a specific login without sending it in plain text through chat or email. Use a tool your business has approved, understand how its sharing and recovery features work, and protect the manager account itself with a strong unique password and available multifactor authentication. Do not copy secrets into documents, task boards, or message threads just because they are convenient.

A password manager is not a reason to share your personal account indiscriminately. Prefer a platform’s named-user invitation whenever possible, since individual access can often be revoked without changing the owner’s credentials. When a shared credential is unavoidable, limit who can retrieve it, record the reason, rotate it when access ends or exposure is suspected, and check whether the service provides a safer delegated option later.

Turn on MFA and protect recovery routes

Enable multifactor authentication (MFA) wherever the service offers it, especially for email, password managers, finance-adjacent tools, ecommerce administration, and identity accounts that can reset other passwords. MFA adds a verification step beyond the password, but it does not make phishing or account misuse impossible. Each person should use their own supported factor rather than sharing a one-time code or forwarding authentication prompts to someone else.

Decide in advance how account recovery will work. Keep recovery email addresses and phone numbers under the owner’s control where practical, store backup codes securely, and do not ask an assistant to use your personal inbox or device to approve sign-ins. If a system requires an owner to approve a login, agree on a prompt, verified channel for approval and a backup contact method. Never approve a sign-in you did not initiate or cannot identify.

  1. Use MFA on the account that controls access to other systems.
  2. Keep backup codes out of shared work documents.
  3. Treat unexpected login approvals or recovery messages as a reason to stop and verify.

Agree on boundaries and escalation before work begins

Access is safer when the assistant knows what not to do. Write down which actions they may complete independently, which require approval, and what to do if the requested task falls outside the agreed scope. Examples of escalation triggers include a request to change payout details, an unfamiliar request for a customer export, a suspected phishing message, or a system asking for permissions beyond the role you expected.

Use a known contact route to verify unusual requests, particularly those involving credentials, payments, account ownership, or urgent access changes. Make clear that the assistant should pause rather than bypass a control to meet a deadline. Likewise, the owner should not ask the assistant to transmit passwords or codes through an unapproved channel. A short written procedure is useful even for a small team because it prevents ambiguity when someone is busy.

  1. List actions that always need owner approval.
  2. Specify how to report suspicious requests and possible mistakes.
  3. Agree that unexpected access prompts are a stop-and-check moment.

Review permissions as the work changes

Access that was sensible for an initial assignment may become excessive when responsibilities shift. Set a regular review point—such as when a project ends, a tool changes, or duties are reassigned—and compare actual permissions with current tasks. Remove unused invitations, old shared links, and access to folders or systems no longer needed. For a small operation, a basic inventory in a restricted internal document can be enough to make the review repeatable.

When a platform offers sign-in history, session management, or access logs, use them as a practical review aid, not as proof that every action is visible. Check for unfamiliar users, stale sessions, or permissions that no longer match the role. If you find something unexpected, disable the relevant access while you investigate, preserve useful details, and follow the platform’s account-recovery or support guidance as appropriate.

Offboard access deliberately and promptly

When a working relationship or assignment ends, treat access removal as a task, not an assumption. Revoke the person’s named accounts and invitations, remove shared-folder and password-manager access, end active sessions where possible, and disable any links or tokens created for the work. If a shared password was used, change it and update any approved storage location. Also check connected apps and delegated inboxes: access can remain through an integration even after a primary invitation is removed.

A concise offboarding checklist helps cover systems that are easy to forget. Confirm what work must be handed back, transfer ownership of business files or records, and ensure the account owner retains recovery control. If access may have been exposed or an account shows unfamiliar activity, prioritize securing the affected account and related recovery routes. The exact steps vary by service, so consult its current instructions rather than relying on a one-size-fits-all checklist.

  1. Revoke accounts, invitations, sessions, and shared links.
  2. Rotate credentials that were shared, and review connected applications.
  3. Confirm ownership of business files and account recovery details.

Make secure access part of the onboarding

A good handoff combines instructions with boundaries. Share a short access map listing each tool, its purpose, the assistant’s role, and the person who approves exceptions. Provide access through the service’s invitation workflow, then ask the assistant to confirm they can complete the intended task without requesting broader permissions. Keep the map current rather than saving sensitive credentials inside it.

If your business needs help with administrative, technical, ecommerce, or customer-support work, match the access plan to the actual responsibilities before work starts. Wizard Business Support describes services including administrative and executive support, technical and IT management, ecommerce assistance, digital marketing, and customer success support. You can review the company’s services, see pricing, or contact the team to discuss scope. For specialized security, legal, or regulatory questions, check relevant local requirements or consult a qualified professional.

  1. Before the first task: define scope, invite a named user, and enable available MFA.
  2. During the work: review permissions when duties change and escalate unusual requests.
  3. At the end: remove access, rotate shared credentials, and verify ownership and recovery routes.