Clinic Staff Offboarding Checklist for India: Access, Devices, and Unfinished Work

Begin with an authorised departure instruction. Record the staff member, their responsibilities, the coordinator and the date and time at which access should end.

“Leaving on Friday” is ambiguous if the clinic operates an evening shift, the employee finishes at lunchtime, or remote work continues after closing.

Distinguish three events:

• The employment or contract end date.
• The last period of authorised work.
• The time access should be removed from each relevant system.

The clinic owner and appropriate employment adviser should determine these arrangements. Administrators should act on that instruction rather than infer it from a resignation message.

CERT-In’s guidance for government entities calls for immediate submission of an access-deactivation request upon employment termination. This supports treating departure as an access-management event, but the document’s government scope should not be presented as a universal private-clinic legal deadline. CERT-In information-security guidance, section 5.

For a planned departure, prepare the handover before access ends. Where an immediate security concern exists, follow the clinic’s incident process rather than keeping access open to finish paperwork.

The clinic application is only one part of the inventory.

Ask which systems the departing person used, administered, recovered or received notifications from. Include external accounts created during ordinary work, not merely accounts listed in the clinic software.

A compact working inventory might look like this:

This is an inventory template, not a recommendation that every employee should have these permissions.

The UK NCSC recommends a joiner, mover and leaver process covering both internal and external users of software services. That principle is useful for clinic employees, visiting professionals and contractors alike. NCSC guidance on managing SaaS access.

An exported task list is not a completed handover.

For each unresolved item, identify what remains to be done, the responsible replacement, the relevant deadline or clinical instruction, and where the supporting record can be found.

Clinic examples include:

• A laboratory report expected but not yet received.
• A callback requested by a doctor.
• A patient-record request awaiting verification.
• A supplier return awaiting acknowledgement.
• A payment discrepancy awaiting review.
• An appointment that needs rescheduling.

Keep the handover list proportionate. Use record references and necessary context rather than copying complete clinical histories into a general staff document.

The receiving person should acknowledge responsibility and identify anything they cannot accept. “Sent to the new receptionist” does not establish that the new receptionist has access, understands the task or is authorised to perform it.

Keep clinical decisions with clinicians

Administrative reassignment must not turn an unsigned clinical draft into an approved record.

If a departing doctor has unresolved clinical work, the clinic’s responsible clinical leadership should determine the appropriate review and continuity arrangements. Do not ask a replacement clinician to sign under the departing doctor’s identity or make their work appear to have been performed earlier.

For the wider ownership problem, see the multi-doctor clinic workflow guide.

Before removing a departing administrator, establish how the clinic will continue controlling its own services.

A common operational weakness is an account technically belonging to the clinic but recoverable only through one person’s private email address or phone.

Where provider rules allow, arrange authorised ownership or recovery changes and verify them before the handover is considered complete. Do not record passwords, recovery codes or secret keys in the exit checklist.

NCSC guidance recommends knowing how to recover administrator accounts, protecting them with two-step verification and promptly revoking permissions that are no longer required. It also recommends separate, individually managed administrator accounts rather than dependence on one identity. NCSC administrator-account guidance.

Apply those principles according to the service’s actual capabilities. Do not assume a clinic application supports every administrator arrangement described in general security guidance.

A staff account has two different relationships with the system: permission to act now and attribution for work already performed.

Ending the first should not silently erase the second.

Before using a destructive “delete user” action, establish what happens to consultations, payments, stock adjustments, messages and audit history associated with that user.

Ask the vendor to distinguish suspension, deactivation, removal from an organisation and permanent deletion. Different products may use similar labels for different effects.

For historical records, the desired outcome is straightforward: authorised reviewers should still be able to identify who performed an earlier action.

Do not rename the departing employee’s account to the replacement employee’s name. Create or use the replacement’s own identity and assign appropriate permissions.

The CliniKite audit-log guide explains why attribution should remain understandable after staff changes. Record retention and deletion should follow their own approved process, not happen incidentally during an exit.

A checklist entry saying “password changed” is not sufficient evidence that every access route has ended.

Ask the administrator or provider what the chosen action does to existing browser sessions, mobile sessions, delegated access and connected applications.

NIST’s current digital-identity guidance explains that access and refresh tokens can remain valid after an authentication session ends. It also describes independently managed sessions across identity providers and applications. The operational implication is to verify the relevant access paths instead of assuming one sign-out affects every service. NIST SP 800-63B-4, session management.

Use supported revocation controls where applicable. For shared credentials the person knew, have the authorised administrator plan any necessary changes and check their impact on clinic services.

Avoid indiscriminately changing integration credentials during clinic hours. A credential may support a shared process rather than an individual login. Identify its purpose, arrange the change safely and verify that legitimate service continues.

Record the action and its confirmation—not the secret value.

For clinic-owned property, reconcile what was issued against what was returned.

Useful fields include the asset reference, item description, return date, receiver, condition and any unresolved issue. Keep physical return separate from the technical review.

A returned laptop may still need authorised assessment before it is reassigned. Conversely, collecting a device does not prove that access from other devices has ended.

Personal devices need a different process

Where staff used personal equipment, follow the agreed bring-your-own-device policy and obtain appropriate advice about the permitted scope.

Do not demand personal account passwords, inspect unrelated private content or wipe an entire personal phone as a routine exit step.

Use supported, authorised methods to remove clinic access and manage clinic information. If the clinic cannot establish what work information remains outside its systems, record that uncertainty and escalate it appropriately.

Do not claim that disabling an account retracts every document previously downloaded or every message already delivered.

Preserve evidence before disposal

If a device or account may be relevant to an incident, complaint or other preservation requirement, obtain appropriate guidance before clearing or reassigning it.

Routine offboarding and incident investigation should not become confused. A departure alone is not evidence of misconduct.

Review where patients, laboratories, suppliers and colleagues will send the next message.

A departing employee may be listed as the contact for appointment changes, laboratory queries, supplier returns or technical support. Replace those operational contacts through the relevant approved process.

Check future schedules and task assignments as well. Removing login access does not establish that a calendar has stopped offering appointments under that person’s name.

Where patient communication is necessary, provide the clinic’s approved arrangements without disclosing unnecessary employment details.

Avoid blanket forwarding of a personal mailbox or indiscriminate copying of correspondence. Use authorised service-specific delegation or contact changes, taking confidentiality and relevance into account.

For recurring patient communication, review the clinic WhatsApp consent and follow-up guide.

Fictional example: the evening receptionist leaves

A receptionist’s authorised access ends after Saturday’s final shift. They have a clinic phone, access to the clinic application and responsibility for tracking responses from an external laboratory.

Three callbacks remain open, and one supplier query is awaiting a reply.

The coordinator prepares the access inventory and identifies a complication: the laboratory portal’s recovery email belongs to the departing receptionist personally.

Before the final shift, the clinic arranges the provider-approved recovery change and verifies access through its authorised replacement. The callbacks and supplier query are assigned individually, with supporting references.

At the agreed time, the administrator removes the departing person’s relevant access and confirms the provider-specific session controls. The phone is returned and recorded for technical review.

On the next working day, the replacement checks the outstanding work. One callback needs a doctor’s decision, so it is escalated rather than marked complete.

The coordinator can now explain both sides of the exit: which access ended and who owns each unresolved responsibility.

This is a fictional rehearsal, not a customer result. Its purpose is to expose dependencies before a real departure.

A good exit record distinguishes a request from a completed action.

Use statuses such as “requested,” “confirmed,” “not applicable” and “exception awaiting resolution.” Attach or reference appropriate administrative confirmation without copying patient content unnecessarily.

For each relevant system, ask:

• Was the account or permission change completed?
• Were the applicable session and delegated-access controls addressed?
• Does another authorised person retain necessary administrative access?
• Are historical records still attributable?
• Has outstanding work been accepted by its new owner?
• Are any devices, contacts or external permissions unresolved?

Use provider administration tools and an authorised verification process. Do not log into the former employee’s personal accounts or collect their password to prove access has ended.

Where practical, rehearse the technical behaviour beforehand using synthetic accounts. That is safer than discovering how deactivation works during a real departure.

Locums, contractors and short-term staff can be overlooked because nobody describes their departure as an employee exit.

Give temporary access a defined purpose and review or end point. When the engagement changes, reassess what remains necessary.

A returning staff member should not automatically regain every former permission. Confirm their current responsibilities and follow the product’s supported account process.

Similarly, a role transfer may require removal of old access even though the person still works at the clinic.

The role-based access guide covers permission design. Offboarding applies that design to a specific change in responsibility rather than waiting for the next periodic review.

CliniKite’s current public features describe owner, doctor, receptionist, nurse and pharmacist roles, alongside staff administration and connected clinic workflows. These provide relevant foundations for discussing a departure. CliniKite features.

They do not establish that CliniKite automatically offboards staff across every external service, retracts downloaded documents or transfers all unfinished clinical work.

Bring the fictional receptionist scenario to a demonstration and ask:

1. Who can deactivate or otherwise remove a staff member’s access?
2. What happens to an already-open session?
3. Do historical entries retain the original user’s attribution?
4. How can authorised staff find outstanding work associated with that person?
5. What must be handled separately in email, laboratory portals and other services?
6. Can a replacement perform the required work using their own account?
7. What evidence of the access change is available?

Confirm the answers for the actual deployment and release your clinic will use. Where the process remains manual, document its owner rather than describing it as automated.

Clinic staff offboarding is complete when unnecessary access has ended, clinic-controlled information remains available and unresolved responsibilities have an accepted owner.

Start with a clear access end time. Inventory the systems beyond the clinic application, preserve historical authorship, address sessions and devices, and verify the handover.

A short checklist supported by evidence is more useful than a long form with every box marked “done.”