The access step is usually the rushed part of a delegation. A founder gets busy, shares a login over chat, or invites the new virtual assistant as a workspace admin "so nothing blocks them." That single shortcut creates the worst kind of risk, because the person with the widest access is also the newest to your systems.
Least privilege is not a security team ritual reserved for large companies. For a small team handing growth operations to one or two assistants, it is the difference between a mistake you can reverse in five minutes and a mistake that costs a week. This guide walks through a practical handoff you can run before the first task is assigned, using the tools most growth teams already own.
Name what the VA owns this week, not in general
Vague role descriptions produce vague access. Before you touch any permission screen, write down the three to five recurring tasks the VA will own in their first two weeks. Write the tool name next to each task and the exact action they perform. For example: build Apollo lists and export CSV, schedule LinkedIn posts from an approved queue, log activities in HubSpot, and pull a weekly GA4 report.
That list is your access plan. If a tool is not on the list, the VA does not need a seat yet. When someone asks for "full access," you can point to the task list and grant exactly the actions it requires. Adding a seat later is fast; removing access in a hurry is not.
Create a named seat instead of sharing a login
Shared logins feel simpler, but they destroy accountability. Every action looks like it came from you, MFA prompts land on your phone, and you cannot revoke one person without changing the password for everyone. Create a separate user account for the VA on each platform.
Use the VA's work email address controlled by the company, not a personal address. If the relationship ends, you disable one identity and you keep the account history intact. A named seat also makes onboarding faster, because you can build a reusable access checklist for the next assistant rather than reconstructing the login list from memory.
Grant the narrowest role that still completes the task
Every major platform ships with preset roles. Read them before choosing the highest one. In HubSpot, permissions control whether someone can view, edit, or delete records, and whether they can publish or only draft. In Klaviyo and Mailchimp, you can let someone build and schedule a campaign while withholding billing and account-level settings. In Google Ads and Meta Ads, you can grant access to a single ad account or page without giving control of the business portfolio.
Grant the role that matches the task list and nothing above it. If the preset roles are too blunt, use a custom role where the platform supports one. The point is that publishing, deleting, exporting contacts, and changing billing should be separate permissions you can hand out individually. Most risky actions in a growth stack are one of those four.
Platforms document these roles and change them over time. HubSpot's own permissions and roles documentation is the reference to check before you assign a preset, because the label on a role can hide a wide default.
Separate billing, publishing, and deletion from day one
Three permission classes deserve special handling even on a small team. Billing access should almost never go to the VA who runs campaigns. Publishing rights, the ability to send an email or push a live page, should be granted only after a review step exists. Deletion rights, especially for contacts and records, should stay with an owner who understands the retention implications.
If a workflow genuinely needs one of these, add a second check rather than widening the role. A campaign can sit in draft for approval before send. A page can be staged before publish. A contact list can be exported to a restricted folder instead of held in the VA's tool. These small gates preserve the VA's speed without putting irreversible actions one click away.
Keep credentials in a shared manager, not in chat
The cheapest durable habit is a small password manager with a shared vault. Store each tool's service account there, give the VA access to the vault items they need, and rotate the password when someone leaves. Never place a credential in a chat message, a task comment, or a spreadsheet, because those channels get copied, forwarded, and archived.
The password manager also solves the recovery problem. When the VA is out, a second person can reach the same credential through the vault without asking the founder to dig it up. Record which vault item maps to which tool in the access plan so the mapping survives beyond any one person's memory.
Require multi-factor authentication and own the recovery
Turn on multi-factor authentication for every seat that supports it. For tools that allow it, prefer an authenticator app or a hardware key over SMS. Require the VA to enroll their own second factor, so the account is not dependent on the founder's phone for every login.
Decide in advance who holds account recovery, and keep it with the company, not the individual. The recovery email and phone number should be a company-controlled mailbox you can reach during offboarding. If the VA owns recovery for a tool, a departure becomes an account recovery project instead of a five-minute deactivation.
Log the first two weeks and review the access you granted
Some platforms include an activity or audit log. During the first two weeks, review it for anything outside the agreed task list: exports, permission changes, or sends that bypassed the review gate. This is a calibration exercise, not surveillance. If the log shows the VA routinely needs a permission you withheld, grant the narrower version of it. If it shows access you forgot you gave, remove it.
Write the review into the routine. A fifteen-minute access review at the end of the second week catches drift early, when it is still a two-minute fix.
Prepare the offboarding reversal before you need it
The access plan should include an exit column: for each tool, the exact action that removes the VA's access. Disable the named seat, remove the vault item, revoke the ad account or page role, and reassign any queued drafts. Keep ownership of every asset with the company so nothing disappears with the person.
When you can reverse access in one sitting, you can also rotate people cleanly. A backup assistant can step into the same named seats, and the founder never has to remember which personal login was shared with whom.
Package the handoff as one page
Deliver the access plan as a single page with four columns: task, tool, role granted, and reversal action. Add the vault reference, the MFA owner, and the review date. Hand it to the VA with the first task assignment so both of you are working from the same list.
Access feels unglamorous until something goes wrong. Treating it as a deliberate, reversible step makes delegation safe enough to scale. If you would rather have a trained operator set up the tool access and own the recurring work inside it, see how our growth operations support works, or book a free consultation and bring your current tool list.
