Virtual Assistant Data Security and Access Planner

The risk is not the person. It is the shape of the credential.

Almost every conversation about remote assistants and security starts in the wrong place. The question people ask is "can I trust this person", and the honest answer is that you can trust them roughly as much as you can trust the last three people you hired locally, which is to say quite a lot and never completely. That is why nobody runs a business on trust alone. They run it on controls that make trust cheaper: separated duties, audit trails, spending limits, and the ability to switch someone off.

The better question is what shape the access takes. A named user seat in your CRM with a restricted role is a completely different object from your CRM password pasted into a chat window, even though both let the same person do the same job today. The first one logs every action against a name, can be narrowed, and dies the moment you click suspend. The second one is a copy that now exists in two message histories, cannot be attributed, and outlives the engagement until you remember to change it.

The breach data points the same way. In the 2025 Verizon Data Breach Investigations Report, which analysed more than 22,000 incidents and 12,195 confirmed breaches, credential abuse was the single leading initial attack vector at 22 percent, and the share of breaches involving a third party doubled to 30 percent. The 2026 edition reports the top entry point moving to software vulnerabilities at 31 percent, with ransomware present in 48 percent of breaches. Read those two together and the lesson for a small employer is not that outside help is dangerous. It is that loose credentials and unpatched systems are dangerous, and that a person is simply the thing a loose credential is usually attached to. Fix the shape of the access and the question of who you hired becomes an ordinary hiring question again, which is what the background check planner is for.

Delegate. Do not share.

If you take one thing from this page, take this. Every serious business platform already has a feature for letting a second person work in your account without becoming you. Using it takes about ninety seconds and removes the entire category of risk that people worry about.

Mail is the clearest example, because the inbox is the thing owners are most nervous about and also the thing an assistant most needs. Gmail delegation lets a delegate read, send and delete mail in your account, and messages they send show their own address alongside yours. What a delegate explicitly cannot do is change your password or reach your Google Account settings. Compare that to giving them the password: now they can reset it, they hold the recovery route into every service that mails a reset link to that address, and nothing in the sent folder tells you who wrote what. Microsoft 365 offers the same separation through shared mailboxes and Send As permissions granted by an administrator.

The same pattern repeats everywhere. Calendars have sharing permissions. Xero and QuickBooks have per user roles with an audit trail attached to each name. Shopify has staff accounts with individual permission checkboxes. Meta and LinkedIn have page and business roles that sit on top of a personal login rather than replacing it. Banks issue secondary users with their own entitlements. Wherever a native seat exists, use it. A shared password should be the fallback for the one legacy tool that has no concept of a second user, and even then it belongs in a shared vault rather than in a message.

The three phase access ladder

Least privilege is often explained as a philosophy, which makes it sound like an argument for never granting anything. In practice it is a schedule. A system gets granted at the point the work genuinely cannot continue without it, and not one week earlier. The staging below is the one the planner applies, and it maps to how a competent employer would onboard anyone.

Two things make this work rather than becoming a bureaucratic drag. The first is that you tell the assistant the schedule on day one. Phased access announced in advance reads as professional. Phased access discovered by someone hitting a permission error reads as suspicion. The second is that you actually move through the phases. A schedule nobody advances becomes a permanent handicap on someone you are paying to be useful, and the most common failure of access control in small companies is not over granting, it is granting nothing and then complaining that the hire needs too much hand holding.

Pair the ladder with a written task list so the phases have a reason to exist. The task delegation planner and the onboarding plan generator produce the other half of the picture: which tasks move across in which week, which is what should be driving the access schedule in the first place.

The four foundations, and why they are weighted

The readiness score in the planner is built on four controls. They are weighted by how much each one contains a credential once it has left your hands, which is a different question from how much security theatre each one provides.

While you are enforcing multi factor authentication, fix your password rules at the same time, because most small companies are still running advice that the standards bodies abandoned years ago. The current NIST SP 800-63B digital identity guidelines require a minimum of 15 characters where a password is the only authenticator, allow shorter passwords of at least eight characters only where they form part of a multi factor process, and tell verifiers they should permit at least 64 characters. On the rules people actually argue about, the guidance is blunt: verifiers shall not impose composition rules such as mixtures of character types, and shall not require periodic password changes, forcing a change only where there is evidence of compromise. What they should do instead is check new passwords against a blocklist of known compromised and commonly used values.

Read that against the usual small business setup and the picture is uncomfortable. A nine character password with a capital letter and an exclamation mark, rotated every ninety days into a predictable variant, shared over chat and protected by no second factor, fails on every count. A long passphrase held in a shared vault, never rotated on a calendar, and backed by an authenticator app satisfies all of it and is less work for everyone.

When your data is regulated

The paperwork section of the planner changes depending on what you tick, because different data types carry different contractual obligations that attach before the first login, not after the first month. None of these are exotic. They are standard documents that any experienced remote professional has signed before.

Health information. If the work touches protected health information on behalf of a covered entity, the assistant is a business associate and you need a business associate agreement under 45 CFR 164.502(e) and 45 CFR 164.308(b), containing the elements listed at 45 CFR 164.504(e). The test is the function performed, not the country the person sits in. Sign it first, then issue the practice management seat, and keep any trial period on de identified or sample records.

Financial services. Mortgage brokers, insurance agencies, accountants and lenders sit under the FTC Safeguards Rule, and 16 CFR 314.4 is unusually specific. Paragraph (c)(1) requires access controls that limit users to what they need. Paragraph (c)(3) requires encryption of customer information in transit and at rest. Paragraph (c)(5) requires multi factor authentication for any individual accessing any information system, unless a qualified individual approves equivalent controls in writing. Paragraph (f) requires you to select service providers capable of maintaining appropriate safeguards, to require those safeguards by contract, and to reassess them periodically. That paragraph is the one people miss, and it applies squarely to a contracted assistant.

Card data. The cheapest position under PCI DSS is the one where the assistant never sees a card number at all. Handle refunds and disputes through the gateway back office, which works from tokens and the last four digits. Where card data genuinely is in scope, requirement 12.8 covers written agreements with third party service providers and requirement 8.4.2 has required multi factor authentication for all non console access into the cardholder data environment since 31 March 2025.

European personal data. If the assistant processes personal data on your behalf, Article 28 of the General Data Protection Regulation sets out the mandatory processor terms. Because South Africa does not appear on the European Commission's list of adequacy decisions, a transfer out of the European Economic Area needs a Chapter V transfer mechanism, which in practice means the standard contractual clauses and a transfer risk assessment. This is paperwork rather than an obstacle, and it is the same paperwork any European company signs with a supplier outside the bloc.

South African personal information. The Protection of Personal Information Act 4 of 2013 works on a responsible party and operator model that will feel familiar to anyone who has met the GDPR. Section 19 sets the security safeguards, section 20 governs processing by an operator, and section 21 requires a written contract obliging the operator to establish and maintain those safeguards and to notify you where personal information has been accessed by an unauthorised person. Section 22 sets the breach notification duty and section 72 governs transfers of personal information out of the Republic.

Money deserves its own rule: separate the duties

Everything above is about access. Financial controls are about something slightly different, which is making sure no single person can complete a harmful transaction alone. This matters more than any password policy for the specific failure small businesses actually suffer, which is rarely a dramatic hack and usually a change of supplier bank details that nobody questioned.

Three splits do most of the work. Whoever prepares a payment must not be the person who releases it, which is what a bank payment preparer entitlement plus dual authorisation gives you. Whoever reconciles the ledger must not be the person who can change a supplier bank detail, because reconciliation is the control that would otherwise catch the change. And whoever can create a supplier must not be able to approve the first invoice from that supplier. None of these three require expensive software. They require you to hold one half of each pair yourself.

Add a standing verification rule while you are at it: any change to bank details, from any party, is confirmed by a voice call to a number you already held, never to a number supplied in the message requesting the change. Write that rule into the assistant's standard operating procedure on their first day and it stops being a judgement call under pressure.

The last day: revoke in ten minutes, not over two weeks

Most engagements end perfectly amicably. That is precisely why offboarding gets done badly: there is no urgency, so accounts sit live for months, and the risk you carry is not the person who left but the dormant credential nobody is watching. The fix is unglamorous. You write the revocation list on day one, at the same moment you grant the first credential, and you keep it in the same document as the access plan.

The ordering matters more than people expect. Suspend the central identity account first, so that single sign on sessions drop everywhere at once. Then revoke mail and calendar delegation explicitly, because delegation is a separate grant that frequently survives the suspension of the delegate account. Then remove shared vault membership and rotate every credential that was in it, whether or not you believe it was used, because rotation is cheap and certainty is not. Then work through API keys, personal access tokens and app passwords, which are the ones everyone forgets because they were issued once and never appeared in a user list. Then named seats in each tool, transferring record ownership before deleting anything. Then bank entitlements, cancelled through the bank rather than assumed. Then the device. Finally, export the audit log for the period and file it with the contract.

The offboarding checklist generator covers the handover side of the same conversation, which is the other half of a clean exit: documentation, work in progress, and who now owns each recurring task.

What good looks like in the first two weeks

Pulled together, a competent first fortnight looks like this. Before day one you sign the confidentiality agreement, the acceptable use and device policy, and whichever regulated agreement your data type requires. You enable multi factor authentication across your own accounts, because you cannot ask a new hire to meet a standard you do not keep. You create the shared vault and put into it only the credentials that have no native seat.

On day one you create named seats for the phase one systems, share the calendar, add them to one document folder, and walk them through the access schedule so they know what arrives when. You tell them the bank details verification rule out loud. In week two you add mail delegation once you have seen how they write, and you review the audit logs once, not because you expect to find anything but because a control you never check is not a control.

None of this is specific to hiring in South Africa, and none of it is specific to hiring remotely. It is the access hygiene that a small business should have anyway, and the useful side effect of hiring a remote assistant is that it forces the conversation. Owners who work through this list once usually discover that their real exposure was never the new hire. It was the four ex contractors still holding logins, the admin password in a shared note, and the ad account owned by an agency they stopped using in 2023.

Questions employers ask

Sources

• Verizon, 2025 Data Breach Investigations Report announcement
• Verizon, 2026 Data Breach Investigations Report
• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management
• 16 CFR 314.4, FTC Standards for Safeguarding Customer Information
• US Department of Health and Human Services, Business Associates guidance
• PCI Security Standards Council document library
• Regulation (EU) 2016/679, General Data Protection Regulation
• European Commission, adequacy decisions
• Protection of Personal Information Act 4 of 2013 (South Africa)
• Google, delegate and collaborate on email

This page is a planning aid rather than legal advice. A regulated business should have counsel review its contracts and access arrangements against its own obligations.