Virtual Assistant Access Plan Generator (Free)

The objection nobody says out loud

Ask a founder why they have not hired an assistant yet and you will usually hear about budget, or about not having time to train someone. Sit with the question a little longer and a different answer tends to surface: they do not know how to let another person into the business without effectively handing over the keys. The inbox has customer contracts in it. The drive has payroll somewhere. The card details are saved in the browser. Delegating the work seems to require trusting a stranger with all of it at once, and since that feels reckless, the work stays where it is and the founder stays buried in it.

The premise is wrong, and it is worth taking apart properly. Access is not one switch. Every serious business tool built in the last decade ships a permission system precisely because a second person needs to do the work without holding the credential. Your email provider has a delegation feature. Your payment processor has six named roles. Your help desk has agent seats. Your social platforms have an entire business layer that exists so that an agency can post for you without ever seeing your personal login. The question is not whether to trust someone. It is which of about twenty specific grants the job actually requires, and whether you can withdraw them all in one afternoon.

That reframing matters commercially, not only technically. The businesses that delegate well are not the ones with more trusting owners. They are the ones where granting access takes fifteen minutes and withdrawing it takes ten, so the decision to hand off a task stops feeling like a leap of faith and starts feeling like a routine administrative act.

Delegate, do not share

One rule does most of the work here: use the tool's own delegation feature rather than sharing a password, on an account that belongs to one named person. It sounds obvious written down, and it is broken constantly, usually because the shortcut takes thirty seconds and the correct route takes three minutes.

Email is the clearest example. Google's delegation feature lets someone read, send and delete mail on your behalf from their own signed-in account, while explicitly preventing them from changing your password or using chat as you. Microsoft 365 offers the same shape through shared mailboxes and delegate access. Compare that with the common alternative of sending someone your password: every action in the mailbox is now indistinguishable from yours, your second factor has to be defeated or shared to make it work at all, and the day you change the password your assistant is locked out mid-shift with no warning. The delegation route is better on security, better on accountability and better on the ordinary operational question of what happens next week.

The pattern repeats everywhere. Meta's business layer assigns specific assets and tasks to a partner or employee whose access hangs off their own personal login, and your business portfolio keeps ownership of the page regardless of what happens to them. Stripe ships fixed roles including View Only, Analyst and Support Specialist, and a Support Specialist can view payment data and issue refunds without touching account settings or API keys, which happens to be the exact shape of a support assistant's job. Xero and QuickBooks both grade their user roles so that reconciliation work does not require payroll access. Shopify staff permissions are granular enough to enable products, orders and customer messages while leaving finances, apps and domains switched off.

Almost every time someone shares a password, a named grant existed and nobody looked for it.

What to grant, system by system

The generator above produces this for the systems you actually run. The short version, for the eight grants that come up most:

System	What to grant	The mechanism that produces it
Your inbox and calendar	Delegated access on their own account	Gmail delegation or a Microsoft 365 shared mailbox. They read, send and delete on your behalf and cannot change your password
Help desk	Agent seat in their own name	A named agent, so response and resolution times are attributable to a person rather than to a shared login
CRM	Standard user, scoped pipeline, export off	A non-admin role limited to the records they work. Your customer list is the most portable asset you own
Payment processor	View Only, or Support Specialist for refunds	Stripe's fixed roles. Support Specialist can view payments and refund charges without reaching settings or API keys
Accounting software	Read-only first, standard non-payments role later	Xero and QuickBooks both ship graded roles. Start narrow and widen deliberately once the work is proven
Business bank	View-only user, or nothing at all	Better still, keep the bank closed and put a bill-pay tool in front of it so they prepare and you approve
Social pages and ad accounts	Task-based access through the business layer	Meta Business Manager or LinkedIn page roles, tied to their own personal login. Your business keeps ownership of the assets
Website or CMS	Editor or Author, never Administrator	Publishing rights without plugin installs or user changes. Hosting, DNS and the registrar stay entirely separate

Two habits make this durable. First, grant late rather than early: give access when a task needs it, not when you imagine a task might need it one day. Second, write down what you granted and the date. That list is worth very little on the day you write it and becomes the most useful document you own on the day the engagement ends, because offboarding is simply the same list run backwards.

The seven things that never get shared

Some grants have no safe version, because they either defeat your other controls or cannot be withdrawn cleanly. Your personal passwords are first, including the ones on accounts you also use for work. Business banking credentials and the one-time codes that protect them are second, and that line does not move for anyone: if a bookkeeper needs to move money, put a bill-pay tool in front of the bank so that preparation and approval sit with different people.

Multi-factor recovery codes are third, and they are the one most people get wrong with the best intentions. Recovery codes exist to bypass the second factor, so sharing them hands over precisely the protection you just spent time enabling. Live payment API keys are fourth, and they are worse than a password in one specific way: removing a person does not invalidate a key they already copied, so the key has to be rotated separately. Domain registrar and DNS logins are fifth, because losing them means losing your website and your email in the same afternoon. The workspace super-admin account is sixth. Signing authority on contracts, and the ability to add or change a payment method, is seventh.

None of this is about doubting the person. An assistant who is entirely honest can still be phished, and the entire point of the list is that a single bad moment on their side should not be able to cost you the business. Verizon's 2025 breach report put credential abuse at 22% of breaches, the leading initial attack vector, ahead of exploited vulnerabilities at 20%. It also recorded third-party involvement in breaches doubling to 30% and ransomware present in 44% of all breaches. Those numbers describe how credentials are handled, not where the person holding them happens to live.

Multi-factor first, then everything else

Turn on multi-factor authentication on the assistant's named account before you grant a single system. Doing it afterwards means running a window, however short, where a password alone is enough.

CISA's guidance separates the options honestly. FIDO and WebAuthn security keys and PKI-based authentication are the phishing-resistant forms, because the credential is bound to the site and cannot be relayed to an attacker who has built a convincing copy of your login page. App-based one-time codes and mobile push with number matching are weaker but are reasonable interim mitigations, and number matching in particular defends against the push-fatigue attack where someone taps approve on the tenth prompt just to make it stop. For a small team hiring their first assistant, an authenticator app on both sides is a sensible floor, and a hardware key on whichever account holds the most is a genuinely good investment.

Password rules worth keeping, and ones worth dropping

NIST rewrote its authentication guidance in 2025, and the fourth revision of SP 800-63B is unusually direct about which traditional rules to abandon. Passwords used as a single factor must be at least 15 characters. Systems should permit at least 64. Composition rules that force a mixture of character types must not be imposed. Most notably, verifiers must not require users to change passwords periodically, and should force a change only where there is evidence the credential has been compromised.

For a founder and an assistant, that translates into something practical. Stop running the quarterly password change ritual, which mostly produces the same password with an incremented digit and a sticky note. Use long generated passwords from a manager, which nobody has to remember or type. Change a credential when something has actually happened: a shared password held by someone who has left, a device lost, a phishing email that was clicked. The password manager is what makes that policy workable, and it is the one grant worth making generously, because a shared vault is the only mechanism that removes a credential from someone's device the instant you withdraw it.

The offboarding half everyone loses

Access plans usually get written once, at the start, by someone who is excited about the new hire. The half that gets skipped is the one that matters most, because an open account belonging to nobody carries all the risk of an active account and none of the benefit. Engagements end for ordinary reasons all the time, and the day someone leaves on good terms is exactly the day nobody feels any urgency to revoke anything.

Run it in this order, on the last day, regardless of how the engagement ended.

Step	Action	Why this order
1	Suspend the password manager seat	Pulls back every shared credential on every device at the same moment
2	Suspend the named work account	Cascades to everything behind single sign-on in one action
3	Remove mailbox and calendar delegation explicitly	Delegation is a separate setting and does not always die with the account
4	Rotate shared passwords and live API keys	A key or password copied once keeps working until it is changed, no matter who was removed
5	Remove them from tools that keep their own user list	Accounting, payment and store admin tools rarely follow your identity provider
6	Reassign tickets, tasks, records and file ownership	Doing this after deactivation orphans the work and hides it from every view
7	Check for scheduled payments, campaigns, automations and posts	Things they queued keep running on their own after the person is gone

The sequencing is not fussiness. Reassigning work before deactivating rather than after is the difference between a clean handover and a set of orphaned tickets nobody can find. Rotating keys after removing the person is the step that closes the gap a removal alone leaves open. And checking for scheduled items catches the campaign, the automation or the queued payment that keeps running quietly on its own long after the person who set it up has gone.

Put it in the agreement, and know which law applies

An access plan that lives only in your head is a preference. Written into the agreement, it becomes an obligation you can point at. The clause the generator produces covers the parts that matter: access is for the agreed scope only and can be withdrawn at any time, credentials live only in the provided password manager and are never copied or passed on, work happens on a password-protected and updated device, company data stays off personal cloud accounts, suspected compromise is reported immediately and reporting in good faith is never held against them, and everything ends and all data is returned or deleted on the last day.

That last clause about reporting deserves more attention than it usually gets. An assistant who fears blame for clicking a bad link will delay telling you, and the delay is almost always more expensive than the click. Say plainly, in writing and again out loud on the first call, that reporting a mistake fast is the behaviour you want.

There may also be a legal requirement sitting underneath the clause. If your assistant handles personal information about South African customers, section 21 of the Protection of Personal Information Act requires a written contract with the party processing that information on your behalf, obliging them to maintain the same security safeguards you are held to and to notify you where there are reasonable grounds to believe personal information has been accessed by an unauthorised person. The Philippines has its own comparable regime under the Data Privacy Act, and if you serve customers in the EU or the UK a processor agreement is standard practice. Our guide to whether your offshore assistant is a contractor or an employee covers the surrounding paperwork in more depth, and the contract template generator builds the agreement this clause belongs in.

Where this fits in the hiring sequence

Access sits between signing and starting, and it works best when the steps on either side line up with it. Scope the role first with the job description generator so you know which systems the work actually touches, screen with the interview questions generator, and put the terms in writing with the contract template generator. Once the plan above is granted, the onboarding checklist generator sequences the first ninety days, the SOP generator turns each process into something the next person can follow, and the performance scorecard generator measures whether the hire is working. If you are still sizing the decision, the cost calculator and the ROI calculator put numbers on it, and the time zone overlap calculator shows how many hours you would actually share. Browse the roles we source, the industries we support, and common use cases to see how other teams scoped the work first.

One last thing worth saying to anyone hesitating over an offshore hire specifically. The location is not the security variable. An assistant in Cape Town or Manila working from a named account with scoped permissions and a shared vault is easier to secure, audit and offboard than a colleague in the next room using a login four people know. Build the model properly once and it holds for every hire after this one.

Sources

The breach statistics come from Verizon's 2025 Data Breach Investigations Report, the authentication guidance from CISA and NIST, and the permission details from each vendor's own documentation. The grant levels in the generator are our own recommendations, drawn from the roles we place, and they are meant to be adjusted to fit your business.

FAQ

Virtual assistant access questions, answered

How do I safely give a virtual assistant access to my accounts?

Grant access through each tool's own delegation feature, on an account in their own name, at the lowest permission level that lets the work happen. That means Gmail delegation or a Microsoft 365 shared mailbox instead of your email password, a named agent seat in your help desk instead of a shared login, Meta Business Manager task access instead of your personal Facebook password, and Stripe's View Only or Support Specialist role instead of Administrator. Put anything that genuinely has to be shared in a password manager vault scoped to the role, and write down what you granted on the day you granted it. The tool above builds the full list for the role and systems you pick.

Should I share my passwords with a virtual assistant?

Almost never, and far less often than people assume. Most business tools now ship a delegation or role feature specifically so a second person can do the work without holding the credential. Where a shared credential is genuinely unavoidable, it belongs in a shared password manager vault rather than in chat, email or a spreadsheet, because a vault can be withdrawn in one click while a message can be forwarded forever. Seven things stay off the list regardless: your personal passwords, banking credentials, multi-factor recovery codes, live payment API keys, domain and DNS logins, the workspace super-admin account, and signing authority.

What access does a virtual assistant actually need on day one?

Less than most people grant. A named work account with multi-factor authentication turned on, a password manager seat, the specific shared folders they will work in, the project tool and team chat, and the one or two role systems they were hired to run. Everything else can wait until a task actually requires it, and the thirty-day review is where you remove whatever turned out to be unnecessary. Granting broadly on day one feels efficient and is the single most common way businesses end up unable to say who could see what.

How do I offboard a virtual assistant securely?

Run your grant list in reverse on the same day, starting with the broadest revocation. Suspend the password manager seat first, because that pulls back every shared credential at once. Then suspend the named work account, remove mailbox and calendar delegation explicitly, rotate any shared password and any live API key they could see, and remove them from the tools that keep their own separate user list. Reassign tickets, tasks, records and file ownership before deactivating rather than after, and check for scheduled payments, campaigns and automations they created. Do this even when someone leaves on excellent terms.

Is it risky to hire an offshore assistant from a security point of view?

The location is not the risk. The access model is. An assistant three time zones away working from a named account with scoped permissions and a password manager is measurably safer than a colleague down the hall using a shared login that nobody can withdraw. Verizon's 2025 breach report put credential abuse at 22% of breaches, the single leading initial attack vector, which is a statement about how credentials are handled rather than about where the person handling them sits. Fix the model and the geography stops being the interesting variable.

Do I need multi-factor authentication on my assistant's accounts?

Yes, and turn it on before you grant anything else. CISA's guidance treats FIDO and WebAuthn security keys and PKI-based authentication as the phishing-resistant options, with app-based one-time codes and push with number matching as reasonable interim steps when a hardware key is not practical. The trap is the recovery codes: they are designed to bypass the second factor, so sharing them hands over exactly the protection you just set up. Keep recovery codes in your own vault and never in the shared one.

What should the contract say about access and data?

That access is granted only for the agreed scope, at the lowest level that allows the work, through named accounts, and can be withdrawn at any time. That credentials live only in the password manager you provide and are never copied, exported or shared onward. That work happens on a password-protected device kept current with updates, and that company data is not stored on personal cloud accounts. That any suspected compromise is reported immediately and that reporting in good faith is never held against them. That everything ends and all data is returned or deleted on the last day. If your assistant handles personal data about South African customers, section 21 of POPIA requires a written contract with the party processing on your behalf, so the clause is a legal requirement and not only good practice.

Is this access plan generator free?

Yes. It is completely free and there is no email or sign-up required. Pick the role, tick the systems you run, and copy the plan into your onboarding doc. The clause it produces is a starting point for your own agreement and not legal advice, so have a lawyer check it against the law where you and your assistant are each based.

Hire someone who has worked inside client systems before

Tell us the role and the hours, and we will show you vetted candidates in your time zone within days. No upfront cost, and you pay nothing if you do not hire.

Request Candidates

Book a Meeting