How to Give a Virtual Assistant Access to Accounts Without Handing Over the Whole Business

Before you work out how to give a virtual assistant access to accounts, picture this. Your assistant needs to update one spreadsheet. But the folder it sits in also contains your tax records and confidential client proposals.

Sharing the whole folder would take ten seconds. Separating the work feels like another job, and you hired help precisely to avoid more jobs.

That shortcut can quietly give someone far more access than either of you intended.

This isn't about whether your VA seems trustworthy. A wrong click, a hacked account or a misunderstood instruction can use whatever permissions you've granted. The safest access is the access that doesn't exist.

This guide shows you how to give a virtual assistant access to accounts in a way that matches the actual job, keeps ownership and recovery firmly with you, and lets you withdraw access cleanly without losing your files or locking yourself out.

Here, a virtual assistant (VA) is an independent freelancer or agency. The goal is giving them enough to deliver the agreed service, not control of everything around it.

List the actions before you look for a role called "assistant"

Write down what your VA actually needs to do. Be specific:

• Read customer enquiries.
• Draft replies.
• Send replies.
• Delete messages.

Software might bundle those together. Your service brief shouldn't.

For each task, note:

• the information needed,
• what happens if a mistake is made.

Preparing a draft product description needs source notes and an editable document. Publishing it changes what customers are promised. Changing billing details is a whole different level of risk.

Mark each action:

• needed now,
• possibly needed later,
• outside the service.

Start with the first group only. If a new task needs more, review that permission separately. Don't treat your first "yes" as permission for everything that follows.

If the service itself is still vague, our what to delegate first guide helps. Access design can't fix an assignment that never says what the VA is meant to deliver.

Keep ownership and the "get back in" keys with your business

Before inviting anyone, check who owns each important account:

• Can you sign in?
• Can you reach the recovery email or phone?
• Who's the billing owner?

If an old contractor owns the only admin login, adding a new VA doesn't fix that. It just adds another person on top of a fragile setup.

Never let your VA replace your recovery email with theirs, even because "they're better at handling account emails." They can help you navigate settings. That's different from being the only person who can recover the account.

Have a backup administrator where it makes sense, with their own account. Not a copy of an undocumented master password shared over chat.

Check file ownership too. A report created in your VA's personal Google account might be shared with you without belonging to your business. Agree where business files are created, and how they stay accessible when the service ends.

This isn't an accusation of misconduct. People get ill, lose phones, close accounts. A well-designed service survives an ordinary departure without the former VA staying on call to rescue your property. Our offboarding checklist covers what happens at the end.

Use named access, and read what the permission actually allows

Use an individual account, collaborator invitation or delegated role wherever the platform supports it. That way you can see who did what, and remove one person without changing a shared password used by several.

Don't assume role names mean the same thing everywhere. In some tools, an "Editor" can share files and change important settings. In others, they can only edit content in one area. Read the current permissions before inviting anyone.

Google Drive separates viewer, commenter and editor access. Its sharing guidance also explains a crucial detail: folder access is inherited. You generally can't give someone lower access to an individual file than they already have to its parent folder. So your folder structure is your security design.

Gmail delegation, according to Google, lets a delegate read, send and delete email, but not change your password. That's better than sharing your main password. But it's not a draft-only permission, and it can't hide selected emails within the same mailbox.

For work or school Gmail accounts, Google restricts delegates to people or groups in the same organisation, and an administrator must enable delegation. Your VA's personal address might not work. Ask your administrator whether a business-managed account can be supplied. Don't share your owner password to get around it.

If the available role is too broad, change the workflow. Your VA can draft from a reduced set of information in a separate document. Or you can use a separate service inbox. Don't describe a written "please don't send" instruction as if the software technically prevents sending.

Build a work area that doesn't inherit your secrets

Create a dedicated folder for the service, rather than sharing the nearest convenient parent folder. Put in it:

• approved instructions,
• source material,
• outputs.

Keep financial, legal and unrelated customer records outside it, unless a task genuinely needs them.

When a task only needs part of a document, prepare a reduced version. Removing unnecessary columns is much safer than writing "please ignore the sensitive columns." And a hidden tab or collapsed section is not an access boundary.

Check the new folder's sharing:

• Prefer named accounts over public links.
• Check inherited access and group membership.
• Watch out when moving files in. A file's old sharing settings might not reflect its new exposure.

Ask your VA to open the folder from their own account and tell you what they can see. Use harmless test content first. You're checking that real permissions match what you intended, not just that the invite arrived.

Add a short note explaining the layout. If "Working files" and "Approved files" mean different things, say which holds the current customer-facing version. Good organisation reduces the temptation to widen access just to find something.

Use two-step login, but never share the second step

Multi-factor authentication (MFA) means needing more than a password to sign in, like a code from your phone. Turn it on for both your accounts and your VA's, wherever supported, with recovery methods that work if a phone gets lost.

Don't make "send me the login code" a normal routine. If your VA keeps needing codes from you, you're probably sharing the wrong kind of account. It also makes a suspicious code request look perfectly ordinary.

• For their own accounts: agree security standards, but don't collect their private recovery codes.
• For business accounts: keep recovery arrangements with your business administrator.

If a shared password is genuinely unavoidable, and the platform allows it:

• use a proper password manager,
• share only that one item, not your whole vault,
• record who has access,
• know what must be changed when access ends.

But remember: a password manager doesn't create narrow permissions inside a service that only has one all-powerful login. Access to a shared login is access to everything that login can do. Decide if the task really justifies that.

Map personal data before someone opens it from overseas

Customer names, messages, order history and appointment details are all personal information, even when the work feels like simple admin.

List:

• what data the service needs,
• who'll receive it,
• where they work,
• which systems they'll use.

A confidentiality agreement helps, but it isn't a full privacy arrangement.

Under UK data protection rules, a controller decides why and how personal data is used, and a processor handles it on the controller's behalf. Where that relationship applies, the ICO's contracts guidance describes required terms covering instructions, security, sub-processors and more. The guidance is under review following legislative changes, so check the current version when finalising terms.

Overseas access needs its own check. The ICO's guidance on restricted transfers explains that letting a separate organisation overseas access personal data can count, even if your server is in the UK. A UK storage location doesn't automatically clear it.

Those sources are about UK rules. Get proper advice for your situation and sector, and don't enable access to real data while an important privacy question is unresolved.

For practice tasks, use invented data. If you redact real material, check it can't still identify someone. Renaming a customer doesn't remove an identifying address or a distinctive order history.

Agree devices, downloads and helpers upfront

Ask how your VA will protect work on their side. Keep it about the service, not an intrusive tour of their home:

• device updates and screen locks,
• local downloads,
• whether others can see or hear customer information.

Say where work may be stored. A downloaded file stays on someone's laptop long after you remove folder access. Decide if local copies are needed, how they're protected, and what happens to them afterwards.

Cover extra tools explicitly. Permission to draft a reply doesn't mean permission to paste the customer's message into an AI tool, transcription site or browser extension. Agree approved tools and uses first.

Helpers and substitutes. An independent VA might use a helper or substitute under a properly agreed arrangement. Don't treat that as automatically banned or automatically fine. Agree approval, confidentiality and data terms first, then give authorised helpers their own access.

If your business needs a specific managed device or special environment, discuss cost and feasibility before starting. A requirement discovered after the deal is agreed creates pressure to work around it.

Keep an access register you can actually act on

Create a private register, one row per account or shared resource:

Field	Example
Resource	Service working folder
Account identity	VA's named account
Permission	Editor on this folder only
Purpose	Prepare weekly report
Business owner	Business administrator
Date granted
Review date	At scope change or service end
Removal method	Remove invite, check inherited and group access

Never put passwords or recovery codes in the register. It tells you where access exists and how to manage it. It shouldn't become another list of secrets.

Add hidden routes. Your VA might reach a folder through a group, an app through single sign-on, or a system through a connected integration. Removing a direct invitation won't remove those. Record the actual route you tested.

Link the register to your offboarding checklist. Another authorised person should be able to follow it without asking the departing VA which accounts they used.

Test the allowed job and the forbidden action separately

A successful login proves almost nothing.

Test two things:

1. Can your VA complete the intended work from their own account?
2. Do they have powers you meant to keep?

For the second, use harmless checks, not risky live changes. Inspect settings rather than asking them to try a destructive action.

For a document task: confirm they can open the source, edit the draft and leave a handover note. Then check unrelated folders aren't visible through the same sharing path.

If a platform bundles a needed permission with a dangerous one, write that down. Decide whether a separate account, a different tool or an approval step makes it acceptable. A rule in a procedure is a behaviour control, not a technical restriction.

Recheck after changes: adding a group, moving a folder, expanding a role. Permissions can change indirectly, so last month's screenshot might not reflect reality.

If you don't know what a permission does, stop there. Ask the platform's support or an administrator, using your task requirements. Don't solve uncertainty by picking the highest role.

Passing this test verifies the access design for one workflow. Device security, incident response, backups and legal obligations still matter.

A worked example: a reporting service, done properly

Here's a hypothetical example.

A VA prepares a weekly sales summary. The owner's first instinct is to share the whole business drive and the main accounting login, because the right data is somewhere in there.

The task map shows the VA actually needs:

• an approved sales export,
• a report template.

They don't need payment-release authority, tax correspondence or every customer's support history.

So the owner:

• creates a restricted reporting folder,
• supplies only the fields needed,
• gives the VA edit access to the working report,
• keeps the source export in a separate location with view-only access, outside any folder the VA can edit,
• keeps account recovery and accounting-system permissions with the business.

A missing field gets requested through the task record, not "solved" by granting the whole accounting account.

The rehearsal finds a problem: the VA can open the template but not the source file, which was accidentally left in a private folder. The owner fixes that specific sharing error. They don't make the parent folder public to remove the obstacle.

Later, a new request: correct an invoice. That's outside the tested reporting service. The owner reviews the new action, authority and permissions before deciding. Familiarity with the VA doesn't make a new financial permission risk-free.

At the end of the service, the register shows the working folder and any shared credentials. The business keeps its reports, removes access and handles local copies under the agreed data process. The service ends without surrendering the accounting account or losing any work.

Make reporting a mistake easier than hiding one

Tell your VA what to do if they:

• click a suspicious link,
• send information to the wrong person,
• lose a device,
• notice unexpected account activity.

Give a named contact and an alternative route, in case the usual messaging account is compromised.

Ask for known facts quickly: what happened, which account or data might be involved, and when they noticed. Don't require a full explanation before they report. Waiting to understand everything delays containment.

Make sure someone in your business can:

• revoke access,
• contact the platform,
• preserve useful evidence.

Never ask your VA to delete logs or messages to tidy up an incident. Legal notification and evidence decisions might need specialist advice.

Review access whenever the service changes, and when it's no longer needed. Remove unused permissions rather than leaving them "in case." Confirm removal in the actual system, including sessions, integrations and shared passwords.

Good access setup lets your VA deliver the service without depending on your main password or controlling your recovery options. And you can always explain, from a current record, what they can reach and how that access ends. That's a far stronger basis for trust than handing over everything and hoping nobody makes a mistake.

Your secure access checklist

VA SECURE ACCESS SETUP

Actions needed now:
Actions possibly later (review separately):
Outside the service:

Ownership check:
  I can sign in? / I control recovery? / Billing owner?
  Backup administrator:

For each system:
  Named account / collaborator / delegation:
  Permission level and what it ACTUALLY allows:
  Inherited or group access checked:

Work folder:
  Dedicated folder? Sensitive files outside? Reduced copies?
  VA tested from their own account? Result:

MFA on (mine / theirs):
Shared credentials (password manager, single items only):

Personal data map:
  Data / recipient / location / systems
  Overseas access reviewed? Advice obtained?

Devices / downloads / extra tools / AI tools / helpers:

Access register location:
Incident contact + alternative route:
Next access review date:

Related: how to delegate to a virtual assistant and the VA onboarding checklist.

Frequently asked questions

Should I share my password with my virtual assistant?

No. Use named accounts, delegation or collaborator features wherever possible. If a shared credential is genuinely unavoidable and allowed, use a password manager and share only that one item.

What is least privilege access?

Giving someone only the permissions needed for their specific task, rather than broad access "just in case." It limits the damage from mistakes or a hacked account.

Why can my VA see files I didn't share with them?

Often because of folder inheritance. In Google Drive, access to a folder applies to everything inside it, and you generally can't give someone lower access to a file than they have to its parent folder.

Do I need multi-factor authentication for my VA?

Where supported, yes, on your accounts and theirs. Don't make sending login codes through chat a routine; that usually means the wrong kind of account is being shared.

Is it safe for an overseas VA to access customer data?

It can be, with the right arrangements. Under UK rules, letting a separate overseas organisation access personal data can count as a restricted transfer even if the server's in the UK. Get advice before enabling access to real data.

If the assignment involves customer records, use the CRM cleanup handover guide to separate investigation, proposed corrections and live editing permission.