Write a first-week access checklist for a new assistant

List the systems the first lane actually needs

Start with the first task lane, not the full job description, and list every system that lane touches. A typical lane might need the shared inbox, the calendar, the document drive, the task board, and one reporting export. Write the exact permission level beside each system, such as view, comment, edit, or administer. If you cannot name the level, the request is not ready for provisioning.

Separate tools the assistant will use daily from tools that are only needed for a single handoff. Daily tools need a named account and a review date, while one-off tools can be handled through a supervised session. Include the client-facing name the assistant will use in email and chat. That detail prevents a new hire from improvising an identity that confuses customers.

Walk the lane yourself before the start date and note every login prompt, shared folder, and approval screen. A tool that appears in the job description but not in the actual workflow should be removed from the request. A tool that appears only when an exception occurs should be documented as an exception path. The list should match the work, not the org chart.

Separate named accounts from shared logins

Every person should sign in with a named account, even when the team shares a mailbox or a calendar. Named accounts make it possible to see who changed a record, who exported a file, and who approved a request. Shared credentials erase that evidence and make removal impossible without disrupting everyone else. If a tool truly cannot support individual users, document the exception and the compensating review.

Multi-factor authentication belongs on every account that supports it, including email, file storage, and the task board. Give the assistant a recovery method that does not depend on the manager's personal phone. Record the device and the backup code location in the access register. A login that only works when one supervisor is awake is not a reliable first-week setup.

Stage permissions by task risk

Grant the smallest permission that lets the assistant complete the first reviewed task, then add rights after evidence. A new assistant can usually draft replies before sending them, prepare calendar changes before applying them, and stage files before moving them into client folders. Keep export, delete, billing, and user administration rights with a limited owner group. The staged approach gives the reviewer a chance to catch a misunderstanding before it reaches a client.

Write the promotion rule in advance, for example two weeks of clean samples and one reviewer sign-off. Without a written rule, access expands through convenience and nobody remembers who approved it. Put the rule in the same register as the grant so the next reviewer can see the expected date. Review every temporary grant on its stated expiry rather than waiting for an incident.

Match the permission to the consequence of a mistake, not to the seniority of the person. A wrong draft is easy to correct, while a wrong export or deletion can be permanent. If a task needs a high-risk permission, add a second reviewer or a shorter review interval. The extra step is cheaper than a client incident.

Give the assistant a way to report a permission that is too broad without fearing blame for the request. A short weekly note asking what access felt unnecessary will surface rights that were granted by habit. Record the answer in the register and act on it during the review. The person doing the work often sees the excess before the manager does.

Record the approver for every grant

The access register should show the system, account name, permission level, requester, approver, grant date, and review date. Add a field for the business reason so a later reviewer understands why the right exists. Link the register to the role brief instead of storing it in a chat message. A grant without an approver is an orphan, even if the tool shows the account as active.

Ask the client to approve any access to client-owned systems in writing. Keep that approval with the contract or the onboarding record, not only in email. If the client delegates approval to the provider, name the individual who holds that authority. Clear approval ownership shortens the removal conversation later and gives the client a record it can audit.

Schedule the first access review

Book a review at the end of week one and again at the end of the first month. The first review checks whether the assistant can actually do the work with the rights granted, and the second checks whether the rights still match the lane. Invite the assistant to report missing access and unnecessary access in the same conversation. A review that only asks whether the work was completed will miss both problems.

Compare the register with the tool's own user list rather than trusting the register alone. Remove anything that cannot be tied to a current task, a current client, or a legal retention duty. Record the removal date and the person who performed it. If a tool has no exportable user list, take a dated screenshot and store it with the review.

Keep the review notes in the same system as the grant so the next reviewer does not have to reconstruct the history. A screenshot folder on a laptop is not a shared record. If the tool supports comments, attach the review note to the account entry. A review that cannot be found later has limited value.

Plan removal before day one ends

Write the removal steps on the first day, while the account is still easy to trace. Name the owner for each system, the order of removal, and the evidence that proves the account is disabled. Include the mailbox delegation, calendar sharing, password manager entry, and any forwarding rule the assistant created. A removal plan written after a departure is usually incomplete.

Test one removal in a safe account before the first live grant. The test should show that the account loses access, the manager retains the data, and the client receives a confirmation. Store the test result with the access register. That small rehearsal turns offboarding from a scramble into a checklist the team has already run.