Remote support should receive access to the systems needed for assigned tasks, for the period the work requires, under accounts the client can review and revoke. Shared owner credentials make that control harder because activity and responsibility become difficult to separate.
The client owns the access policy and system configuration. A service provider can follow the approved controls, but it should not invent permissions or decide the organization's risk tolerance.
Build an access inventory by task
List each recurring task and the systems it touches. For every system, record the account owner, requested role, data involved, approval authority, authentication method, review date, and removal process.
Do not start from an employee's existing account and copy all of its permissions. Start from the task. An assistant scheduling approved meetings may need calendar availability and event creation without needing mailbox settings, billing administration, or organization-wide user management.
NIST defines least privilege as limiting privileges to the minimum necessary for assigned tasks. Apply that principle through the roles and controls available in each platform.
| Task | Possible access boundary | Review evidence |
|---|---|---|
| CRM updates | Assigned records and required fields | Named account activity and sample review |
| Inbox triage | Defined mailbox or queue, approved actions | Message references and escalation log |
| Calendar support | Named calendars and event permissions | Event history and exception report |
| File organization | Approved folders, no account administration | File activity and folder-owner review |
The table does not prescribe exact permissions. Platform capabilities and the client's security requirements determine the final configuration.
Use individual accounts
Create a named account for each authorized person where the system supports it. Avoid a shared administrator or business-owner login. Individual accounts allow role changes, activity review, and offboarding without rotating a credential used by several people.
Keep account provisioning with an authorized client administrator. Record the business owner for each account and its expiration or review date. Temporary project access should not become permanent because nobody scheduled removal.
If a system lacks suitable roles, document the constraint before work starts. The client may choose a compensating workflow, a different tool, or a narrower task. The assistant should not work around the gap through exported data or an unapproved personal account.
Require appropriate authentication
CISA advises businesses to require multifactor authentication. Enable it through the client's approved method wherever the platform and policy require it. Do not route second-factor prompts through an informal shared channel.
Use the organization's approved credential-management process. Do not place passwords, recovery codes, API keys, private certificates, or session tokens in an SOP, general chat, spreadsheet, or quote request.
Recovery ownership also matters. The client should retain an authorized method to recover or disable the account without depending on the assistant's personal email address or phone number.
Separate production, test, and approval authority
When a workflow allows it, practice with approved test or sample records before using live data. Confirm what the assistant may create, edit, export, send, delete, or approve.
Administrative support often prepares work for someone else to authorize. A draft response, reconciled queue, or updated record can be complete as an administrative task while still waiting for client approval. Keep those states distinct.
High-consequence actions deserve explicit restrictions. Examples include changing payment instructions, approving financial adjustments, altering security settings, signing contracts, making clinical decisions, or issuing legal advice. Route those actions to authorized client personnel.
Define approved data locations
State where source records, working files, exports, and reports may be stored. Avoid copying sensitive data into personal downloads or an unapproved collaboration tool. Define how local temporary files are handled if the workflow needs them.
For healthcare, legal, financial, government, or other sensitive information, the client must identify applicable contractual, privacy, security, and regulatory requirements. Confirm the approved system and responsible reviewer before any protected information is processed. General administrative documentation is not a compliance assurance.
Review access and activity
Set a review cadence based on the system and task risk. The review can compare active accounts, roles, assigned tasks, last needed date, unresolved exceptions, and activity evidence available from the platform.
Look for access that no longer matches the work. A person may have moved to a different queue, a project may have ended, or a temporary export permission may still be active. Remove or reduce access when the reason for it ends.
Activity review should follow client policy and applicable law. Tell authorized users what monitoring applies. Preserve only the records the organization needs under its retention rules.
Prepare offboarding before onboarding
The access register should already say how to disable accounts, revoke sessions and tokens where applicable, transfer owned files, reassign scheduled work, preserve required records, and verify removal. Name the client administrator responsible for the final check.
Offboarding also needs an operational handoff. Record open items, deadlines, unresolved exceptions, and the location of current procedures. Do not keep access active merely to answer a question later.
Brownsofts' Dedicated Virtual Assistants service operates within a client-defined workflow, tools, and brand. The client should approve the accounts, permissions, systems, monitoring, and removal plan before live work begins.
A reviewer should be able to use the register to see who has access, why, what they may do, when access was reviewed, and how it will end.