A new offshore coordinator needs to update customer records. Someone sends the owner's login because creating another account seems slow. Soon, the coordinator can export every contact, change billing settings and invite more users, although none of those actions belongs to the role.
Secure onboarding starts by matching access to the work. A trained assistant should be able to complete agreed tasks independently, while system administration and unrelated information remain with their designated owners.
Use the following proposed checklist whenever someone joins, changes responsibilities or leaves. Apply the same process to Australian and offshore colleagues; location is not a substitute for assessing the actual access required.
Start with a task and access brief
Before creating accounts, identify the first workflow, its records and the actions the person may perform. “Needs CRM access” is too broad. “May update contact details and book approved appointments for assigned enquiries” gives the system owner something to configure and test.
ASD's ACSC recommends access limited to the person's role and individual accounts instead of shared logins. Its small-business guidance also makes security training part of induction. ACSC: small business cyber security guide.
Create one access register containing the person's name, system, permitted actions, data scope, approver, activation date and next review. Record the business owner of each system and a backup contact. Keep passwords and recovery secrets out of this register.
If the role itself is unclear, first use our VA role-design guide. A permission list cannot settle an unresolved responsibility.
Give every person an identifiable account
Invite the colleague through the approved account setup process. They should use their own assigned identity, not the manager's credentials or a predecessor's account. A team inbox can have several authorised users without everyone sharing one password.
Distinguish permission to do work from permission to administer the tool. Adding an appointment is different from changing security settings. Creating a document is different from changing who can see the entire document library.
Where someone genuinely needs administrative duties, separate their routine account from their administrative access. This follows the separation principle in ACSC's secure-administration guidance; your IT provider should adapt it to the systems involved. ACSC: secure administration.
Do not solve an access error by forwarding a password. Record the blocked task and let the system owner establish whether a narrower permission or different workflow will solve it.
Set up MFA and a recovery owner
Enable multi-factor authentication for the accounts being introduced. ACSC recommends phishing-resistant MFA and explains that methods differ in strength. Ask your IT provider which supported option is appropriate; an unexpected authentication request should be reported, not approved to make it disappear. ACSC: implementing multi-factor authentication.
Write down who manages recovery when a phone is lost, a security key fails or a colleague cannot sign in. The authorised recovery owner and backup need a documented process that the business can operate during agreed coverage hours. That does not mean collecting everyone's authentication codes in a spreadsheet.
Keep recovery material in an approved, restricted location. Test the recovery procedure with IT before relying on it. Never include passwords, recovery codes or authenticator setup secrets in onboarding recordings.
Requests to reset credentials or replace MFA need identity checks through an established trusted route. ACSC specifically warns that account-change requests can be help-desk attacks. ACSC: personnel security guidance.
Test permissions against the actual work
Consider fictional coordinator Sam, whose job is to manage assigned enquiries and appointments. This is an example access plan, not a claim about the settings available in every product.
| Work Sam needs to do | Proposed access | Kept outside the role |
|---|---|---|
| Update assigned enquiries | Edit the relevant customer records | Exporting the whole customer database |
| Arrange appointments | Book within the agreed team calendar | Managing other users or billing |
| Prepare handover notes | Edit the assigned handover folder | Viewing payroll or unrelated client folders |
| Answer routine questions | Use approved shared-inbox permissions | Changing security or forwarding rules |
| Report a system problem | Raise an issue with the system owner | Installing unapproved integrations |
In a practice session, Sam can update a record but cannot attach the handover document. The manager confirms the document belongs to Sam's workflow. The system owner grants access to that folder, records the change and repeats the test. Nobody needs to make Sam an administrator.
If the tool cannot enforce the proposed limits, redesign the handover or choose a more suitable configuration with IT. Do not describe a written instruction as a technical restriction.
Teach approved storage, device requirements and the route for suspicious messages. Check both that ordinary work succeeds and that actions outside the role are blocked where intended.
Review access when responsibilities change
A promotion, new client queue or temporary cover arrangement should trigger an access review. Add the permissions the new work needs and remove those tied to duties that have ended. Temporary cover needs an end date and an owner who checks removal.
In Sam's example, moving from enquiries to handover quality checks may require a different folder and queue. It does not automatically justify keeping every previous permission.
Review the register with the manager and system owner after initial onboarding, then on a cadence appropriate to the business. Ask what the colleague actually uses, what they cannot complete and which permissions have no current purpose. Record the decision, not just that a meeting happened.
Use our solar administrator onboarding guide for the separate question of training readiness as responsibilities expand.
Close access as carefully as you opened it
Plan the final handover and exact access end time. ACSC's system-access guidance calls for removing or suspending access the same day its legitimate business need ends. Use that as a security reference when designing your process. ACSC: system access guidance.
The manager assigns unfinished work and confirms document ownership. The system owner checks every registered application, removes delegated access and handles active sessions and connected services through the relevant controls. Preserve business records according to the business's retention process; removing access does not require deleting the work.
Record who completed each removal and verify the result. An account disappearing from the team chat does not establish that CRM, document and inbox access have also ended.
Talk to Nexus about offshore onboarding with a defined workflow, system owner and access plan so your new colleague can start useful work with clear boundaries.
