How to Build an Offboarding Communication Plan for Every Exit

HR set the termination for Friday, and the team announcement went out that afternoon. IT got the ticket Monday morning, and the admin of your billing tool, who was on neither list, found out three weeks later when the former employee's login turned up in an access review.

Offboarding communication is the chain of messages that carries a departure from decision to closed account: who learns about it, in what order, and what each message asks them to do. The farewell email and the team announcement usually have templates. The notice to IT, the request to each app owner, and the confirmation that access is gone usually don't, and those are the messages that decide whether a former employee can still sign in.

This article covers that second set of messages, for IT and security teams that share offboarding with HR. It starts with the order of announcements for resignations, firings, layoffs, and contractor exits, then gives you templates for the HR-to-IT notice, the app owner removal request, and the closing confirmation. A message matrix ties them into an offboarding communication plan you can copy.

The two tracks of employee offboarding communication

Every departure sends two sets of messages, one to the people around the person leaving and one to the people who run the apps they could reach. Offboarding plans tend to write down only the first. The people track reaches the departing employee, their manager, the team, and the clients or vendors they served. The access track runs from HR to IT, from IT to app owners, from the person to their successor, and from IT back to HR and audit.

Employee offboarding communication usually means the first track, and the two tracks mostly reach different people. The admin of your data warehouse isn't on the marketing team's announcement, so a departed analyst's login there can sit untouched for weeks. The manager and the successor are among the few people on both tracks, which is why so much of the handoff falls to them.

The split follows ownership. HR or internal comms owns the people track, IT owns the access track, and the handoff between the two is itself a message somebody has to send. A missed message on the access track becomes a live account. That's the track this piece follows, bringing in the people track wherever it sets the clock.

Time the employee departure announcement to the access cutoff

Decide when access ends first, then build the announcement order around that time, because the right order depends on how the person is leaving. The table orders the messages for the four departure types you'll run most often, around the access clock your employee offboarding checklist sets for each.

‍

Order matters most in an involuntary exit. Access goes during the termination meeting, and the employee departure announcement goes to the team afterward, the same day. If the announcement or a calendar change lands first, the person learns it from the wrong source while their access still works. Executive exits raise the stakes, because how to offboard an employee with board portals, delegates, or signing authority depends on who hears first and when.

You can book that cutoff ahead of time. Lumos can schedule an offboarding to start at a set time, and the connected apps start their removals the minute the meeting begins. The apps that need a person are the ones to stage in advance.

Notice periods are the opposite problem. Someone who resigns with two weeks' notice keeps two weeks of access while everyone knows they're leaving, so narrow the risky parts the day notice is accepted: exports, admin consoles, bulk downloads, and customer lists. Leave the everyday tools alone until the last day, because pulling them early stalls the handover you need from them. In both cases, the cutoff is a time, not a date.

Contractors need their own trigger. Their end date often never reaches HR, so set it as the trigger the day they start, and have the vendor manager send the departure notice HR would otherwise send.

When should HR notify IT that an employee is leaving?

HR should notify IT the day it enters the termination, with the exact cutoff time on the notice, even when the last day is weeks away. It's the message the rest of IT offboarding depends on, and it tends to arrive late, half-filled, or at the wrong desk. That notice usually travels as a ticket or an email to whoever in IT the HR partner knows best. Either can stall without anyone noticing: the ticket sits in a queue, and the email leaves out the departure time or lands with someone on vacation.

Automating the notice fixes only part of this. In a December 2025 internal audit covering 6,900 departures between July 2023 and November 2024, Employment and Social Development Canada found that its departures module opened an IT ticket automatically, but on the day after the person left. Some of those tickets were still unresolved 60 days later, and the module sent no ticket at all to the security branch that handles physical access.

The automation fixed delivery, but it didn't fix the timing or the recipient list. Those two decide how long a departed employee keeps access.

NIST treats this notice as a security control in its own right. Control PS-4(2) in NIST SP 800-53 Rev. 5 calls for automated mechanisms that notify named people or roles of termination actions, disable access, or both.

The fix has two parts. The timing comes from the HRIS entry, and the recipient list comes from the apps the person can reach today. Getting the notice to IT before the last day belongs on any list of employee offboarding best practices, because every later step waits on it.

In Lumos, a status change in your HRIS starts automated offboarding, and each app follows the deprovisioning steps you set for it once. The list of who acts comes from the person's accounts, and nobody has to remember who to tell.

Employee offboarding email templates usually address the team. This one goes to IT, with the same fields whether a person or your HRIS sends it.

Departure notice template

• Who: name, employee ID, and work email
• Departure type: voluntary, involuntary, reduction in force, or contractor end
• Last working day and access cutoff: date and time, with time zone
• Manager and successor: who owns the person's work from here
• Flags: admin roles, customer-facing, contractor, legal hold (route through legal before anything is deleted)
• If anything changes: who to tell when the date or time moves

A notice without the cutoff time leaves IT guessing, so make that field required. IT can't narrow risky access during a notice period it hasn't heard about.

Who removes access in apps IT doesn't manage?

App owners remove access in the apps IT doesn't manage, and they're the audience most offboarding plans forget. They administer the tools outside SSO and SCIM, the apps with local accounts, and whatever a team lead bought on a company card. IT can't remove access it can't reach, so the message to an app owner is an assignment. Knowing which owners to message depends on reading accounts from the apps themselves, one of the first things to test in employee offboarding software.

The usual fix is a relay. IT learns about the departure, works out which apps the person used, and forwards the news to each owner by hand, which turns IT into a middleman and every forward into a delay. A busy month of departures means dozens of forwards to people who don't work for IT.

Intercom's IT team knows the middleman role from access requests. Before Lumos, its provisioning and deprovisioning were largely manual, and IT sat between employees and every request. With requests now governed by Lumos policies, IT "no longer plays middleman for every request," and access that took days arrives in minutes.

Removal requests can follow the same rule. An app with a working connector needs no human message at all. Only manual removals and failed ones should reach a person, which keeps an app owner's queue short enough to clear the same day. It’s the same pattern the best user access review software uses in access reviews, sending app owners only the exceptions that need their call.

Involuntary exits can't wait for a queue, because the cutoff is the meeting itself. For each app IT can't reach, IT either removes the account with admin rights it already holds or tells the app owner in confidence that morning, with the meeting's start as the deadline.

Write the request so the owner can close it without asking a follow-up question. Put the departure type first, so involuntary exits jump the queue.

App owner removal request template

• Departure type: involuntary or resignation
• Who left: name, work email, and access cutoff
• App and accounts: the app and every account found for the person
• Action: remove the account, or transfer what it owns to a named successor
• Due: the meeting's start for an involuntary exit, the end of the last day for a resignation
• How to confirm: mark it done with evidence, such as a screenshot or an export of the user list, and the time you removed it
• If it's late: IT takes it over, and security hears

The owner's confirmation, with its removal time, becomes a line in the closing message. Without it, a manual app is the one place that message has to take someone's word.

Run an ownership handover process before the last day

Run the handover before the last day, because some of what a person owned has to keep working after they leave, and each piece needs a successor who has said yes before the account closes. The handover covers shared drives and documents, chat channels they administer, distribution lists, recurring meetings they host, vendor contacts and renewals, and their mailbox.

The transfer message runs from the manager to a named successor and asks them to accept it in writing. If nobody accepts something critical by the cutoff, the manager keeps it by default, so the vendor's renewal notice and the weekly meeting series don't die with the account. In an involuntary exit, the manager sends these transfers the same day, after the meeting, because the person can't be asked to hand anything over.

The non-human half needs the same handover. Service accounts, personal tokens, OAuth grants, and AI agents a person set up keep running on their authority, and revoking them can break production. An automated non-human identity lifecycle hands those off on the same departure event. A personal token gets replaced by one the service owns, and an OAuth grant gets re-approved by its new owner.

Start the handover list the day notice arrives. A list built on the last afternoon misses whatever the person forgot they owned.

What to tell a departing employee about their access

A departing employee needs three messages about their access: when it ends, what they still owe the company, and where the practical details will come from. For a voluntary exit, give them the exact cutoff and what to finish before it, which means handing off open work and moving personal files out of work accounts where your policy allows. Something as plain as "Your access ends Friday at 5 p.m. Central, so hand off anything open before then" does the job.

The second message has a control behind it. PS-4(1), the post-employment requirements enhancement of the same NIST control, asks you to tell departing people about their legally binding obligations to protect company information and to get a signed acknowledgment. Send it at the termination meeting or on the last day, and keep the signed copy with the offboarding record.

Involuntary exits change the order, because the meeting should be the first place the person hears about it. A removal notice arriving mid-conversation can turn a planned meeting into a confrontation. Cut sign-in and the mailbox first, so any notice an app sends about a removed account lands in an inbox the person can no longer open. Then turn off any message your own offboarding workflow would send them.

Final pay, benefits, and equipment return belong to HR's own message, part of what HR owns in offboarding. Point the person to it, and keep logistics out of the access messages.

Build your offboarding communication plan as a message matrix

An offboarding communication plan is finished when every message in it has a trigger, a sender, a recipient, a fallback, a due time, and a record. The first four columns say who sends what, and when it starts. The last three are what keep a message from going missing.

‍

The fallback column catches a failure that's otherwise invisible. A manager field left blank in the HRIS or a successor who left last month will swallow a message whole, and nobody downstream knows it never arrived. Name a second recipient for every message, and route to it when the first is missing or the message sits past its due time.

A message that fails should show up as a failure. Lumos's offboarding workflows include a notification step that sends email, Slack, or Teams messages to the person leaving, their manager, or a group, and you set a fallback recipient for when no manager is on file. Lumos's Activity Log records whether each notification was delivered or failed.

The record column is what your auditor asks for. Every row should leave something you can point to later: a timestamped ticket, a task closed with evidence, or a signed acknowledgment.

Treat the due times as starting points. Set yours with HR and security, and measure every offboarding against them.

What should the offboarding confirmation tell HR?

The offboarding confirmation should tell HR what each app shows for the person after the cutoff, with security and the manager copied. A ticket that closed when the last task was ticked only proves someone ticked it.

For connected apps, the status comes from each app's own account data, read after the cutoff. For manual ones, the app owner's evidence from the removal request stands in, with the time they removed the account. Either way, each line names an app and a time, which is how HR can see the involuntary cut landed when the meeting began.

You shouldn't have to rebuild that list by hand. In Lumos, each offboarding tracks which app steps are done and which are still open, and every grant and revocation lands in the audit trail, so the closing message can come straight from the record.

Two things sit outside a single person's confirmation. The full evidence record auditors sample, and the company-wide sweep that catches accounts created under another name, both belong to your IT offboarding process.

Here's what the closing message should hold. Send it when the removal window closes even if items are still open, since those are the lines HR and security most need to see.

Closure confirmation template

• Person: name, departure type, and access cutoff
• Removed by connectors: each app, with its removal time
• Removed by app owners: each app, with the owner's evidence and removal time
• Still open: each item, with an owner and a due time
• Handed off: files, channels, service accounts, tokens, and agents, with who accepted each
• Record: where the full log lives

File it with the departure notice and the signed acknowledgment. Together they show when the offboarding started and what was still open when it ended.

Test your offboarding communication plan on the next departure

The goodbye email will always need a person. The notice to IT and the requests to app owners mostly don't, and each one relayed by hand is a place where access can outlast the job.

To test your plan before the next departure, hold your last involuntary exit against the matrix. Did IT hear the day HR entered the termination, and did every app owner IT couldn't reach get a request before the meeting started? Check whether anyone sent HR a closing message with a removal time for each app, then put each gap, and each message someone forwarded by hand, on your plan's to-do list.

That list gets short once no message depends on someone remembering to send it. In Lumos, the HRIS status change starts the offboarding, every app connected through its 300-plus integrations runs the deprovisioning steps you set once, and an involuntary exit can be scheduled to begin the minute the meeting does. Notifications carry a fallback recipient and a delivery record, and each offboarding shows which app steps are done and which are still open, with every revocation in the audit trail. Book a demo with your last leaver list, and we'll walk through how each of its messages would run in Lumos.