Giving an Assistant Access to Your Business: A Security and Compliance Guide for Employers

There is a specific moment where first-time employers stall. They have run the numbers, they have accepted that the hours are real, they have even picked a candidate. Then they sit down to write the welcome email and realise that making this work means handing a person they have never met in a country they have never visited the keys to their inbox, their customer list, their invoicing, and quite possibly their bank statements. And they close the laptop.

The stall is rational. What is not rational is how the question usually gets framed. "Can I trust someone overseas?" is unanswerable and, more to the point, it is the wrong question, because it is not the question you would ask about a local hire either. You do not trust a new employee in your own city with unsupervised access to everything on day one. You give them what the job needs, you keep a record of who did what, and you can take it back in five minutes. Distance changes almost nothing about that logic. What distance does change is the legal paperwork, the identity verification, and how quickly you notice when something is wrong.

This guide covers all three. It is written for the employer, not for the assistant. It assumes you are a founder or operator with a small team, no security department, and no appetite for building a compliance programme. If you have not yet worked out how much work you are actually holding, the virtual assistant hours calculator is the better first stop, because the access question is much simpler when you know whether you are handing over inbox triage or your entire finance function.

The short version

1. You stay legally responsible. Under South African, Philippine, European and US rules alike, delegating the processing does not delegate the accountability. What the law asks for is a written contract with specific clauses, not a background check.
2. Sharing a password is the actual failure. Almost every serious incident in a small business traces back to one shared login with no second factor and no audit trail. Every major tool you use already has a way to avoid this, and it is usually free.
3. Identity verification is a real problem and it is not xenophobia. The FBI has publicly documented organised schemes that place fraudulent remote workers inside Western companies using stolen identities and AI-generated documents. This is an argument for a verified hiring pipeline, not against offshore hiring.
4. Access should ratchet up, not start at the top. A tiered ladder over the first ninety days costs you nothing and removes most of the risk from the period where you know the person least.
5. The hole most businesses leave open is offboarding. Access that outlives the relationship is the most common finding in any small-business review, and it is entirely preventable with a one-hour checklist.
6. Mistakes are more likely than malice. Design for the assistant who sends the wrong attachment to the wrong client at 4pm on a Friday, because that is the incident you will actually have.

Three risks that get conflated into one worry

"Is it safe?" bundles together three problems with completely different shapes and completely different fixes.

The first is deliberate harm. Someone takes your customer list to a competitor, diverts a payment, or sells credentials. This is the risk everyone pictures and the least common of the three. It is also the one that contracts, references, and a real employment relationship address most directly, because a person with a name, a verified address, a signed agreement and a job they want to keep is in a very different position from an anonymous freelancer paid in crypto.

The second is error. The assistant replies to all. Sends the pricing sheet meant for one client to a list. Deletes the wrong folder. Falls for a phishing email that appears to come from you and pays an invoice to a changed bank account. This is by far the most likely thing to happen, it happens to in-house staff at the same rate, and no amount of trust prevents it. Only design does: limited permissions, dual approval on money, and a habit of writing things down.

The third is legal exposure. You handle personal data belonging to your customers. The moment someone else processes it on your behalf, a set of specific obligations attaches to you, and they attach whether or not you knew about them. This is the risk founders think about least and the one most likely to produce an expensive surprise, because it does not require anything to go wrong at all. A regulator can find you non-compliant on a day when nothing has been lost, leaked, or stolen.

Sort your worry into those three buckets before you do anything else. They need different answers, and treating all three as a single vibe called "trust" is why the decision stalls.

What the law actually asks of you

Here is the thing that surprises people: none of the major data protection regimes prohibit sending personal data offshore to a contractor. What they do is make you responsible for the arrangement, and they tell you in some detail what the paperwork has to say. The obligations are remarkably consistent across jurisdictions, which is good news, because it means one well-built agreement satisfies most of them at once.

If your assistant is in South Africa

South Africa's Protection of Personal Information Act uses two terms. You are the responsible party, the one who decides why and how personal information gets processed. Your assistant, or the company supplying them, is the operator, processing it on your behalf.

Section 20 requires the operator to process only with your knowledge or authorisation and to treat the information as confidential, without disclosing it unless the law requires or the proper performance of their duties demands it. Section 21 is the one that lands on you rather than on them. Its text is short enough to quote in full:

"A responsible party must, in terms of a written contract between the responsible party and the operator, ensure that the operator which processes personal information for the responsible party establishes and maintains the security measures referred to in section 19."

Read that carefully. The duty is yours. If there is no written contract, you are the one out of compliance, not your assistant. Section 19 sets out what those security measures have to achieve: identifying reasonably foreseeable internal and external risks, establishing and maintaining appropriate safeguards, verifying that they are effectively implemented, and updating them in response to new risks. Section 21(2) adds a notification duty running toward you: the operator must tell you immediately where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person.

If your assistant is in the Philippines

The Data Privacy Act of 2012 and its implementing rules and regulations use the language of personal information controller and personal information processor, and Rule X governs outsourcing and subcontracting. The required contents of the agreement are more prescriptive than most founders expect. It must set out the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data and the categories of data subjects, your obligations and rights as controller, and the geographic location of the processing.

The processor's duties, in turn, run to nine items: process only on your documented instructions, impose confidentiality obligations on anyone with access, apply appropriate security measures, refrain from engaging a subprocessor without your prior authorisation, assist you in responding to data subject requests, make itself available for audits and inspections, delete or return the data when the engagement ends unless a law requires storage, provide documentation proving compliance, and tell you if one of your instructions appears to break the law.

The National Privacy Commission also sets a hard clock on breaches. Under NPC Circular 16-03 on personal data breach management, both the Commission and affected data subjects must be notified within seventy-two hours of knowledge or reasonable belief that a breach has occurred, with a full report following within five days. That clock starts whether or not you were the one who noticed, which is precisely why your agreement needs to oblige your assistant to escalate to you immediately rather than quietly trying to fix it.

If you hold data about people in Europe or the UK

This catches more small businesses than they realise. It is not about where you are based. If you have European customers, subscribers, or job applicants, Article 28 of the GDPR applies to your arrangement with anyone processing that data for you. Article 28(3) lists eight mandatory contract terms, and they map almost exactly onto the Philippine list above: documented instructions only, personnel bound by confidentiality, Article 32 security measures, restrictions on engaging further processors, assistance with data subject rights, assistance with breach and impact assessment obligations, deletion or return at the end, and information plus audit rights sufficient to demonstrate compliance.

Two more points from Article 28 matter in practice. Under paragraph 2, a processor needs your written authorisation before engaging anyone else, which means an assistant cannot quietly subcontract your bookkeeping to a friend. Under paragraph 4, that sub-processor takes on the same obligations and the original processor remains fully liable for their failures. If you are working with an agency rather than an individual, this is the chain you are relying on.

If you are in healthcare, finance, or handle card payments

Three sector rules override everything above in their own domain.

Healthcare. If protected health information is in scope, a business associate agreement is mandatory and location is irrelevant to that requirement. The HHS guidance on business associate contracts lists the required provisions, including permitted uses and disclosures, appropriate safeguards, breach reporting, and a specific obligation to ensure that any subcontractor engaged agrees to the same restrictions and conditions. That subcontractor flow-down under 45 CFR 164.308(b) and 164.502(e) is the clause most often missing in small practices, and a missing agreement is a finding on its own, with no breach required.

Finance and finance-adjacent. The definition of a financial institution under the FTC Safeguards Rule is far broader than "bank", and it sweeps in mortgage brokers, tax preparers, auto dealers arranging financing, and various others. If it applies to you, the FTC's own summary is worth ten minutes of your time. Three requirements bear directly on hiring an assistant: select service providers with the skills to maintain appropriate safeguards and spell out your security expectations in the contract with a way to monitor the work and periodically reassess it, at 16 CFR 314.4(f); implement and periodically review access controls, reconsidering on a regular basis whether each person still has a legitimate business need, at 314.4(c)(1); and implement multi-factor authentication for anyone accessing customer information on your systems, at 314.4(c)(5). Note that last one. It is not optional, it is not for admins only, and it says anyone.

Card payments. The simplest and safest rule is that full card numbers should never appear on any human's screen, yours included. Every modern payment processor supports refunds, disputes, and customer service without exposing the primary account number. If your current process involves emailing card details to anyone, fix that before you hire, not after.

The common thread

Strip away the jurisdictions and every regime above asks for the same six things. A written agreement. Processing only on your documented instructions. A confidentiality obligation on the individual. Defined security measures. Immediate breach notification to you. Return or deletion of data when the engagement ends. If your paperwork covers those six, you are substantially compliant nearly everywhere, and the remaining work is sector-specific. The contract template generator builds a plain-language agreement with confidentiality, data handling, and IP clauses you can adapt, and it is a considerably better starting point than a generic freelance template that has none of them.

The identity question, and why it is not paranoia

There is a version of this concern that is simple prejudice and deserves no airtime. There is another version that is documented fact and deserves a plan.

The FBI has been publicly seeking victim information in an investigation into North Korean remote IT worker schemes, in which thousands of workers dispatched abroad have deceived companies into hiring them remotely in order to generate revenue for the regime. The methods described are worth knowing about because they generalise well beyond that one case: stolen identities, pseudonymous email and payment accounts, false websites, proxy computers, and third parties located inside the target country who receive the equipment and act as a front. Increasingly, AI is used to produce convincing resumes and identity documents and to assist during interviews.

The Bureau's own guidance for companies hiring remotely is refreshingly practical. Send equipment only to the address on the identification documents, and require additional verification if the worker asks for delivery somewhere else. If you are relying on virtual meetings, require video with an unobscured background, ask the person to point the camera out of a window, and ask questions about the location they claim to be in. And do not grant access to any system until the background check is complete.

Read that last instruction against the way most first-time employers actually hire an assistant: a marketplace profile, two written messages, a rate agreed, and inbox access the same afternoon. The gap is enormous, and it exists whether the candidate is in Manila, Johannesburg, or Manchester.

The practical conclusion is not to avoid offshore hiring. It is that the verification has to happen somewhere, by someone, before access is granted. Either you build that capability yourself, which for a single hire is a poor use of a founder's month, or you hire through a pipeline where identity verification, reference checks, and a real contractual relationship with a known person are already part of the process. That is the actual difference between a recruiter-led hire and a marketplace transaction, and it shows up precisely here rather than in the hourly rate. Our own screening runs before you ever see a profile, which is part of why matching takes about two weeks rather than two days. If you want to see how that sequence works end to end, how it works lays it out.

An access architecture that survives a bad day

Now the mechanics. The organising principle is one sentence: never share a password, always grant a role. Every tool below already supports this, and doing it properly takes about ninety minutes total. If you would rather work from a generated list than a written explanation, the access plan generator produces the same structure as a checklist for eighteen common systems, and the sections below are the reasoning behind it.

Email

Giving someone your email password is the single worst habit in this whole area, and it is astonishingly common. It hands over your identity, your password reset path for every other service, and your second factor. It also destroys any ability to tell your actions apart from theirs.

Use delegation instead. Gmail delegated access lets someone read, send, and delete mail on your behalf, with their own login and their own second factor. Sent messages show their address in the sender information, so the audit trail stays intact. Critically, a delegate cannot change your password, cannot access your Google Account settings, and cannot chat as you. Personal accounts support up to ten delegates and work accounts far more. Two operational notes: it can take up to twenty-four hours before a new delegate gets access, and an invitation expires after a week if unaccepted, so set this up before the start date rather than on the morning. Microsoft 365 has an equivalent in mailbox delegation and shared mailboxes.

If your assistant is handling a support or sales queue rather than your personal mail, do not delegate at all. Move the queue into a shared mailbox or a helpdesk tool where each agent has their own account. That is better for you regardless of who is doing the work.

Payments and money movement

Payment dashboards are where founders are most nervous and where the tooling is actually best. Stripe's role system is a good illustration of the granularity available. An assistant handling customer queries needs Support Specialist or Refund Analyst, which allows viewing and refunding payments and resolving disputes but not creating API keys, inviting team members, editing payout schedules, or touching bank account details. A bookkeeper needs Accountant or View Only, which can pull reports and reconcile but cannot move money. Almost nobody supporting you needs Administrator or Developer, and the Developer role in particular carries access to the secret key, which is close to full API access to the account.

One subtlety worth internalising: roles that can invite team members are an escalation path. Stripe's own documentation warns that if an attacker compromises a user with one of those roles, they can invite additional users under their control. The same principle applies in every SaaS tool you use. When you audit permissions, look first at who can grant permissions.

For banking, the rules are blunter. Read-only or view-only access for reconciliation, always. Payment initiation separated from payment approval, so that the person who prepares a batch is never the person who releases it. And never, under any circumstances, forward a one-time passcode to anyone. If your process requires that, your process is the vulnerability.

Credentials

Put every shared credential in a password manager with a vault dedicated to your assistant, and use the option to conceal the value so the password can be autofilled without ever being readable. Grant per-item, not per-vault, when the item is sensitive. This single change collapses your offboarding problem from an afternoon of frantic password resets into one revoked vault.

The things that should never happen: credentials in a spreadsheet, credentials in a chat message, credentials in the onboarding document, credentials in an email. All four are permanent, searchable, and outside your control the moment they are sent.

Second factors

Your assistant needs their own second factor on their own account. Not a shared authenticator, not codes relayed to them, not your phone. Where a legacy tool only supports a single login, most password managers can store the time-based code generator alongside the item so a delegated user can authenticate without ever holding your device. If neither approach is possible, that tool is a candidate for replacement, and you should treat the workaround as temporary rather than permanent.

Files and customer data

Work happens in a shared drive with folder-level permissions, never in your personal drive with everything visible. Grant view rather than edit where the job is reading. In a CRM or helpdesk, use the role system to limit what an assistant can export in bulk. Bulk export is the capability that turns a small mistake into a large incident, and it is very rarely needed by the person doing daily work. Mask identity and card fields wherever the tool allows it.

The ninety-day access ladder

You will not get permissions right on day one, and you should not try. Ratchet them up as the working relationship produces evidence. This costs nothing, it is not insulting when you explain it plainly at the start, and any professional assistant has seen it before.

The access plan generator will build a version of this ladder specific to the role you are hiring, listing the tools by stage so you can hand the plan to the assistant on day one. The performance scorecard generator covers the other half, which is deciding what "sustained performance" means before you are in the middle of judging it.

Offboarding, which is where the real hole is

Ask any small business to list everyone with access to their systems and the list will be wrong. It will be missing a former contractor, a bookkeeper from two years back, an agency that built the website. Access outlives relationships because revoking it is nobody's job and nothing breaks when you skip it.

Write the offboarding checklist on the day you onboard, while you still remember what you granted. It should take under an hour to execute and it runs in this order:

1. Email delegation off first. It is the account that can reset the others.
2. Revoke the shared vault, then rotate every credential it contained. Revocation alone is not enough if a password could have been read.
3. Remove SaaS seats individually, working from your written access inventory rather than memory. Check the tools that bill per seat first, because they are the ones you have a financial reason to remember.
4. Rotate any API key the person could have seen or created, and check for keys created during the engagement that you did not authorise.
5. Check for persistence mechanisms: mail forwarding rules, filters that auto-archive, calendar delegation, connected third-party apps, recovery email addresses and phone numbers on shared accounts. Attackers use these and so, occasionally, do departing staff who intend no harm and simply want to finish something.
6. Transfer file ownership out of their account before you disable it, or you will lose documents.
7. Confirm deletion or return of data in writing. This is not optional politeness. It is an explicit requirement under the Philippine rules, GDPR Article 28(3)(g), and a business associate agreement.
8. Update the access inventory so the next round is easier.

Do this even when the parting is entirely amicable, and do it the same day. If you are working through a managed provider, ask who owns each of these steps before you sign, because a replacement mid-engagement should trigger the same checklist and it is much easier when someone else is running it.

Noticing, without becoming a security team

Monitoring in a small business is not a dashboard. It is four or five alerts that you actually read.

• Login alerts on your email and payment accounts, sent to you, not to a shared address.
• Admin action alerts where available: new user invited, role changed, API key created, security setting modified. These are rare enough that each one deserves a glance.
• Bulk export alerts in your CRM and helpdesk. A legitimate export happens occasionally and has a reason you will know about.
• A monthly access review. Ten minutes, once a month, going down the list of tools and asking whether each person still needs what they have. This is the FTC's 314.4(c)(1) requirement in miniature and it is good practice whether or not it applies to you.
• Mail rule checks. Look at forwarding rules and filters on delegated accounts quarterly. A rule that quietly archives messages from your bank is the classic signature of invoice fraud, and the person who set it may not be your assistant at all.

Notice what is absent from that list: monitoring software on the assistant's machine, keystroke logging, screenshot capture. These tools are widely sold into this market and they are mostly a substitute for management rather than a form of security. They generate enormous amounts of data nobody reviews, they damage the working relationship, and in several jurisdictions, including under POPIA and the Philippine Data Privacy Act, they create their own compliance obligations toward the person being monitored. If you cannot tell whether the work is being done, the fix is a clearer scope and a scorecard, not a camera.

What to do this week

1. Write down every system that holds customer personal data, and mark which ones the assistant will genuinely need. Most first drafts of this list are twice as long as they need to be.
2. Fix your own account first. Second factor on email and payments, a password manager in place, and no credentials living in documents or chat. Doing this after the hire is much harder.
3. Get the agreement right before the start date. Six clauses: written scope, documented instructions only, confidentiality, security measures, immediate breach notice to you, and return or deletion at the end. Use the contract template generator as a base and have a local advisor review it if you are in a regulated sector.
4. Build the ladder, not the pile. Use the access plan generator to produce the staged tool list, and share it with the assistant on day one so the sequence is a plan rather than a suspicion.
5. Write the offboarding checklist now and save it next to the access inventory. Ten minutes today, an hour saved and a real risk closed later.

None of this requires a security budget and none of it requires trusting a stranger further than you are comfortable. It requires deciding once, writing it down, and following your own sequence.

If the part you are stuck on is the person rather than the plumbing, that is the part we handle. You can request candidates and see verified profiles with references already checked, or book a meeting and walk a recruiter through exactly which systems the role would touch, so the access ladder is built before anyone is hired rather than improvised afterwards. If you are still deciding where to hire from, the Philippines versus South Africa comparison covers the practical trade-offs, and the contractor or employee guide deals with the classification question that sits right beside this one.

The founders who handle this well are not the ones who worried hardest. They are the ones who accepted that the answer to "can I trust this person?" is always partly no, for everyone, everywhere, and built something that works anyway.

Sources

• POPIA section 19, section 20 and section 21, Protection of Personal Information Act, South Africa.
• Implementing Rules and Regulations of Republic Act No. 10173, Rule X on outsourcing and subcontracting agreements, and National Privacy Commission Circular 16-03 on personal data breach management, Philippines.
• Article 28, General Data Protection Regulation, on processors and required contract terms.
• Business Associate Contracts, US Department of Health and Human Services, on required provisions and subcontractor flow-down.
• FTC Safeguards Rule: What Your Business Needs to Know, US Federal Trade Commission, on service providers, access controls and multi-factor authentication.
• Seeking Victim Information in North Korean Remote IT Worker Investigation, Federal Bureau of Investigation, on fraudulent remote worker schemes and hiring verification guidance.
• Delegate and collaborate on email, Google Workspace Help, on what a mail delegate can and cannot do.
• User roles, Stripe documentation, on role scope and permission escalation.