Dental Employee IT Onboarding and Offboarding Checklist

A dental employee IT onboarding checklist helps a new team member start with the right access and equipment. An offboarding checklist helps the practice remove access at the authorized time while preserving the business information it still needs. Both depend on coordination between the practice manager, IT and application owners.

This guide covers routine staff changes: joining, changing roles and leaving. It is separate from switching IT providers or integrating an acquired practice. The objective is a repeatable request and completion process that does not depend on someone remembering every account from memory.

Start with one authorized staff-change request

An employee’s access should begin with a request from an authorized practice manager or other designated approver. Include the person’s identity through the approved channel, role, location, start or change date, effective time and required systems. Identify the person who can resolve questions about the request.

Do not ask IT to “copy everything from the last employee” without reviewing what the new role actually needs. A former employee may have accumulated permissions over several years. Reusing that access pattern can quietly grant more authority than the new role requires.

Separate approval from implementation

The manager knows the business responsibility. IT knows how to apply supported controls. The PMS or another vendor may own a separate account system. Document that split so an IT completion message does not get mistaken for proof that every application owner has finished its work.

For ongoing service responsibilities, review the Managed IT Services page. Confirm which account and device changes are covered by the practice’s actual agreement and which require another vendor or internal administrator.

Maintain a role-to-system access list

Create a simple list of systems each role may need and who approves access to each one. Examples include the workstation login, email, PMS, imaging, approved communications tools and selected vendor portals. Access should follow the actual responsibilities of the individual, not only the job title.

Record the account owner and request route for every system. Some systems use a central identity service; others have separate credentials or permissions. Removing a central account may not automatically remove an independently managed application account. The list makes that distinction visible.

Keep the list free of passwords and recovery codes. It is a map of responsibility, not a credential store. The existing password-management guide covers credential practices; this checklist focuses on when access changes and who confirms the work.

Prepare a new employee before the first working session

Submit the approved request with enough notice for the responsible teams to coordinate. The required lead time depends on the systems, equipment and vendors involved. Do not invent a universal onboarding deadline; agree one with the people who perform the work.

Confirm that the assigned device is ready for its intended role, that required applications are available and that the person has an individual account. An available computer is not automatically an appropriate clinical workstation. If equipment needs assessment, the workstations and servers service page explains that separate infrastructure scope.

Validate the role, not just the login

A new employee should be able to perform the authorized tasks for the role and should not receive unrelated administrative access. Use an approved orientation or test workflow. Do not share another staff member’s credentials because the new account is not ready.

Explain how to request help, report a suspected account problem and reach the appropriate practice contact. Complete any required authentication enrollment through the approved process. The employee should understand how to use the account without receiving unnecessary access to system administration or shared secrets.

Treat role changes as access changes

A person moving from reception to management may need different permissions. A person moving between locations may need access removed at one office and added at another. The change request should name what is added, what is retained and what is removed.

Without that review, permissions tend to accumulate. The person may retain access to old mailboxes, vendor portals or administrative functions simply because nobody owns the removal step. Make the outgoing role part of the request, even when the employee remains with the practice.

Review temporary assignments explicitly

Temporary coverage, a short-term employee or an outside billing arrangement may need a defined access period and a named supervisor. Set the review or end point when the access is approved. If the assignment extends, review the need instead of letting the original temporary request become permanent by default.

Multi-location practices should coordinate this process with group policy. The DSO IT support guide addresses shared standards and central versus local responsibilities. A single practice manager should not independently broaden access across the group without the proper approval.

Plan departures around an authorized effective time

The practice’s authorized management or HR process determines the employment decision and timing. IT implements the access actions it is instructed and authorized to perform. Provide the effective time, location, scope and the approver who can confirm last-minute changes.

For a planned departure, prepare the account list, device-return arrangements and business-information ownership in advance. For an urgent departure, contact the established technical escalation route and coordinate the immediate access actions. Do not rely on a casual message to someone who may not be monitoring the request channel.

Block access without assuming deletion is the first step

Account access, active sessions, devices, shared resources and data ownership may require separate actions. Microsoft’s former-employee guidance for Microsoft 365 separates access blocking and data-handling steps. Other applications have their own supported procedures, so the responsible administrator should use the relevant guidance.

Before deleting accounts or removing licenses, confirm retention, legal-hold and business-continuity needs with the appropriate practice authority. This checklist does not set a universal retention period. The technical team needs clear instructions about what must remain available and who may access it.

Work through offboarding system by system

Use the same inventory that supported onboarding. Include systems controlled by vendors or practice administrators, not only the central email account. Ask each owner to confirm completion and record exceptions that need follow-up.

If a shared secret was known to the departing person, the responsible administrator should assess what needs rotation and who else is affected. Do not paste shared credentials into the offboarding ticket. Record the action without recording the secret itself.

An unreturned device needs its own follow-up. Confirm ownership and the approved management procedure rather than assuming a personal device can be treated like practice-owned equipment. Any remote action should follow the organization’s authorization and established device-management policy.

Verify completion instead of accepting a blanket done message

A meaningful closure record identifies the systems checked, the effective time, the person performing the work and any unresolved items. Verification should follow the platform’s supported administrative methods. Do not ask another employee to sign in as the departing person to test whether access remains.

Check whether independent vendor accounts, delegated mailbox permissions or other access paths were included. If one application owner has not responded, keep that exception visible with an owner. A partially completed workflow should not look like a fully completed departure.

Review the inventory after each change

Update device assignments, account ownership and the role-to-system list where appropriate. A staff change often reveals an application that was missing from the inventory. Add the responsible owner so the next request does not repeat the same discovery problem.

Schedule periodic access reviews through the practice’s established process. A review can help find stale accounts or mismatched roles, but it does not replace timely changes when someone joins or leaves. Legend’s HIPAA support page covers the broader safeguards context without treating a completed checklist as a compliance certification.

Keep staff changes separate from provider transitions

Employee offboarding concerns an individual’s working access. Switching IT providers involves administrative ownership, tooling, documentation, backup responsibilities and a wider technical handoff. Combining the two can leave important responsibilities hidden.

If the practice is changing its provider, use the dedicated dental IT provider transition checklist. Keep staff-access requests in the normal queue while the transition team coordinates the wider change. The provider handoff should establish who will own that queue after cutover.

For the broad operating model, see the Managed IT pillar. The staff-change process is one recurring responsibility within that model, with its own authorization and verification steps.

Give your team one repeatable process

Keep the request route, approver and role-to-system list accessible to authorized managers. Explain what must be provided for a joiner, a role change and a leaver. Keep employment details and sensitive account information in the appropriate systems, not in a broadly shared checklist.

If the practice currently relies on informal messages and memory, start by documenting one recent change without including personal details. Identify the missed handoffs, then agree who will own them next time. You can ask Legend to review the workflow using that process description rather than sending employee records with the enquiry.