When staff leave: closing their access to the PMS, email, channels and extranets on the same day

A leaver sheet is one list of every system a person can sign in to, with an owner and a closing action for each. On the last working day, before the person leaves the building, each account is disabled rather than deleted, shared passwords are changed, and devices and keys are collected and recorded. This is the hotel staff leaver access checklist that makes the process routine.

The resignation is agreed on a Tuesday and the last shift is three weeks away. In that window the person can still sign in to the PMS, the channel manager, three extranets and the hotel's social account, and nobody has written down which. After reading this you will have a one-page sheet, a division of labour for the last day, and a quarterly check that catches whatever the last day missed.

Why does leaver day matter more than joiner day?#

Because a joiner's mistake shows up as a blocked screen the same morning, and a leaver's mistake stays invisible until somebody uses it.

Joiner day has a witness. The new person cannot work until access is granted, so every gap surfaces within hours and gets fixed by lunch. Leaver day has no witness: nothing fails when an account stays open, so nothing prompts anyone to close it.

The number of places a hotel person can sign in grows quietly. Beyond the PMS there is the restaurant till, the channel manager, the travel agency extranets, the review platforms, the social accounts, the reservations mailbox, the door-lock encoder, the Wi-Fi and the phone. A leaver takes knowledge as well as credentials: which shared passwords exist, which extranet the agency actually uses, which card opens the back office at night.

The risk window is the notice period, not the last day. A resignation accepted today is an access event today. Seasonal hotels run this for many people at once at the end of the season, which is exactly when the front office has the least spare time.

What belongs on the leaver sheet?#

One row per system, with the person who owns it and a plain description of what closing it means.

Build the sheet from the access map you already keep for outages. If you do not have one, the leaver sheet is the reason to make it: start with the hotel IT inventory and network map the leaver sheet is built from. Group rows by the person who owns the system, not by department, so the sheet can be handed out in four or five pieces on the day.

Include the things that have no login: the master key, the safe, the fuel card, the corporate card, the parking barrier remote. Include the person's own accounts used for work, such as a personal mailbox that receives reservation mail or a personal phone that receives one-time codes. Mark each row as disable, change password, or collect, so nobody has to interpret it at 18:00.

Test the sheet with one question: could an IT person who has never met this employee close every row from the sheet alone, without asking anyone?

Should you disable or delete a departed employee's account?#

Disable it. Deleting the account removes the name from records the hotel may be asked to explain later.

The PMS record answers who did what: who checked in the guest, who voided a charge, who approved a rate change, who reviewed an e-invoice before it was sent. A deleted user turns those entries into an orphan line. A disabled user keeps the name and the leaving date attached to the history, which matters when you are reading the PMS audit log each month to see who changed what.

Disable means three things together: sign-in blocked, role removed, account marked with the leaving date. Blocking the sign-in alone leaves the permissions waiting. Never recycle a username for the next hire, even in a small team; a new person gets a new account, so the record stays readable.

The mailbox is a separate decision from the account. Keep the address alive for a stated period under a named owner, with an automatic reply naming the new contact, so agencies and guests are not writing into a void. How long you keep a disabled account's personal data, and what you tell the person about it, is a question for your legal adviser. Write the decision down in the sheet, or the next administrator will tidy the disabled accounts away and undo the history.

What do you do with the shared logins the person knew?#

Change them the same day, in a planned window, and tell the staff before you do.

Shared logins are the real exposure, because they are the ones nobody can attribute: the extranet, the Wi-Fi password, the social account, the generic reservations mailbox, the channel manager. Changing them disrupts work, which is why the change gets postponed week after week. A planned twenty-minute window with a warning to the shift is the workable compromise, and it belongs inside a routine for shared passwords in hotels: extranets, Wi-Fi and social accounts.

Prioritise by what the credential can do: move money, change rates, cancel bookings, post publicly, open a door. Those go first. Record the new credential in the hotel's password record in the same hour, or the next shift will put the old one back to keep working.

Remove the leaver's phone number from every account that sends one-time codes before you change the password, or the change locks out the wrong people. Rotate the shared password even if you believe the leaver never used it. Belief is not a control.

What must be collected before the person leaves the building?#

Everything that opens something: devices, cards, keys, and the numbers that receive sign-in codes.

A returned card is not a removed card. If a master key card is missing, whether locks are re-keyed is a decision for the lock vendor and the insurer, not something to settle at the front desk on the last afternoon. The one-time-code number is the item most often missed: if codes go to the person's mobile, every account that sends them still belongs to that person, however well the password was changed. For more on the hardware side, see key cards, encoders and how the door lock connects to the PMS.

Use a signed return form with one line per item, and file it with the leaver ticket. A form with a single signature and no list proves nothing. Hand the collected items to a named person, not to the department in general, so the next question has an answer.

For a dismissal, the order changes: disable and collect first, then hold the conversation, then do the paperwork.

Who does what on the last day?#

HR owns the trigger, the department head owns the scope, IT owns the execution, and the leaver confirms the handover.

HR opens the leaver ticket the day the exit is agreed, fixes the last working day, and tells IT the date in writing rather than in a corridor. The department head lists what the person actually does, because the job description is usually a year out of date, and signs off that the handover is complete.

IT works the sheet row by row and records the time and the person for each row, then confirms that the sheet is closed. The leaver writes the handover list and names the shared passwords they know; they know the systems better than the manager does, and a handover framed as help is usually given freely.

The general manager should see the closed sheet, not the process: one line per leaver in the monthly management report. Nobody should be able to close a row without a name against it, including the general manager.

How do you check that closed accounts stay closed?#

Once a quarter, compare every system's user list with the active payroll list, and treat the differences as findings.

Export the user list from each system on the sheet, and ask HR for the active list dated the same day. Two lists from two different dates prove nothing. The first finding is accounts that match no active employee. The second is active employees with no account of their own, who are working through a colleague's login. The third is accounts nobody has signed in to for a long time, where the system shows a last sign-in date.

Look for generic accounts with no named owner; a shared account is a finding even when it is convenient. Read the record of who changed what since the last check, because a permission added quietly is as interesting as an account left open. Fix each finding in the same ticket and date it, so the next check starts where this one ended. Run it before the season ends, not after, when the seasonal accounts are still open and still needed.

What to do next#

Open the leaver sheet before anyone resigns. List every system a person can sign in to, name an owner per row, and mark each row disable, change password or collect. The sections fit together as one loop: the sheet defines what closes, disable-not-delete protects the record, the shared passwords and the collected devices close the physical side, and the quarterly comparison catches whatever the last leaver day missed.