By [Author Name] · [Date] · [X] min read · [Table of Contents]
TL;DR
- Equipment during long-term sick leave is the question of what happens to a laptop when its holder is away indefinitely.
- Most companies have no position, so each case is handled by whoever notices, differently every time.
- The default should be that the device stays with the person, and the exceptions should be narrow and written down.
- Three situations: short and bounded, long and open-ended, and the one where the person cannot be contacted.
- Choose based on whether there is any communication at all, not on how long they have been away.
- Done well, nobody in HR has to improvise during somebody's worst month.
Somebody has been off for eleven weeks. A new starter needs a laptop, procurement is slow, and a manager asks whether the absent person's machine could be collected and reused since it's sitting in a flat doing nothing. The question is practical, it comes from a reasonable place, and however it gets answered is now the company's unwritten policy.
Variations arrive constantly. A finance review flags twelve devices that have shown no activity for over sixty days and asks for an explanation of each. A security lead points out that a machine nobody has seen for four months still holds live credentials. An IT manager, doing an audit, sends an automated email asking somebody to confirm they still hold their laptop, and that email arrives during a hospital stay.
Best tools for HR Operations
The real issue isn't the hardware. It's that a question about an asset gets routed to whoever is closest to the asset, and that person has no visibility of the human situation attached to it.
When You Don't Actually Need to Change Anything
Stage one: the device stays and nobody asks. Somebody is off for a few weeks, their laptop is at home, and there's no reason for anybody to think about it. The correct amount of action here is none, and most absences never leave this stage.
Stage two: somebody raises it. A new starter needs a machine, or an audit flags the inactivity, or a manager wonders aloud. Nothing has gone wrong, but the question is now live and whoever answers it first sets a precedent for everybody.
Stage three: it becomes a liability. An unmanaged device with live access sitting somewhere nobody has visibility of, for a period with no defined end. That's a genuine security consideration and it's also the one most likely to be raised in a way that sounds urgent and generates a clumsy response.
Stage four: no contact at all. The person cannot be reached, through no fault of anybody's, and the device cannot be discussed because the conversation has no participant. This is the only situation where the equipment question becomes genuinely difficult, and it needs handling by people rather than by process.
What HR Teams Actually Need from a Position on This
> "Can we collect the laptop?" > Default no, and make the exceptions specific. > A device left with somebody costs almost nothing. A collection request landing at the wrong moment costs something that does not appear on any budget line.
> "What about the access?" > This is the question that genuinely needs an answer, and it is separate from the hardware. > Suspending access is routine, reversible and invisible to the person. Collecting a device is none of those things.
> "Who is allowed to contact them about it?" > One named route, usually HR or their manager, never IT directly and never an automated system. > This single rule prevents most of the damage that happens here.
> "What do we tell the person who needs a laptop?" > That one is coming, and give them a date. > Solving a procurement delay by reallocating an absent person's machine is solving the wrong problem.
> "Does it change at any point?" > Only if the absence becomes an exit, and that is a different process with its own conversation.
A sixth question arrives in companies with tight asset controls. Worth pre-empting. What do you tell the auditor about twelve devices showing no activity? The answer is that they're allocated to people on leave, which is a complete and accurate answer, and it doesn't require anybody to be named.
The Three Situations and What Each One Needs
Short and bounded. What it is: a known absence with an expected return date, measured in weeks. What it needs: nothing. The device stays, access may or may not be suspended depending on your normal practice, and nobody raises it. Where it goes wrong: when an audit cycle happens to land in the middle and generates an automated query.
Long and open-ended. What it is: months, with no confirmed return date, and periodic contact through whatever channel has been established. What it needs: access handled properly, the device left alone, and a note on the asset record explaining why it shows no activity so nobody asks again. Where it goes wrong: when the absence outlasts the people who knew about it. The manager changes, the HR contact changes, and the device becomes an unexplained anomaly to everybody currently looking at it.
No contact. What it is: the person cannot be reached at all. What it needs: people, not process. Whoever is managing the wider situation decides, and the equipment question waits behind every other consideration. Where it goes wrong: when somebody treats it as a recovery problem and starts a collection process, because that's what the asset system suggests doing with an unresponsive holder.
I'd keep the default at leave it alone across all three, and put the effort into the access question and the asset note instead. Those two cost nothing and remove almost all of the pressure that leads to a bad decision.
| Situation | Collect the device? | Suspend access? | Note the record? | Who may contact |
|---|---|---|---|---|
| Weeks, bounded | No | Per normal practice | Helpful | Nobody needs to |
| Months, open-ended | No | Yes | Yes, essential | HR or manager only |
| No contact | Not as a first step | Yes | Yes | Whoever holds the case |
| Absence becomes an exit | Through the exit process | Yes | Updated at exit | HR |
How to Decide What to Do: Five Questions
Is there any contact? This is the first and most important question, and it's not about duration. A person three weeks in with whom nobody can speak is a harder case than somebody eight months in who replies to emails.
Who is actually asking, and why? A manager who needs a laptop for a new starter has a procurement problem. An auditor has a documentation problem. A security lead has an access problem. None of those three problems is solved by collecting a device, and identifying which one you are actually facing changes the answer completely.
Has access been dealt with? If it hasn't, do that first and the security question disappears. Most of the pressure to collect hardware comes from a worry about access that can be resolved without touching the hardware at all.
Is the asset record explained? One line on the record saying the holder is on leave and the device is correctly allocated prevents the same question arriving every quarter from a different direction.
Would you be comfortable with this conversation being described back to you? A useful test for any contact during somebody's absence. If the answer involves any hesitation at all, don't send it, and take the question to whoever is already in contact with them.
Six Platforms Worth Knowing
RemoAsset Best for: keeping an accurate record of a device that is correctly allocated and deliberately not moving. Why companies choose it: procurement and retrieval across 80+ countries with each device tracked against a holder and a date, which matters here mainly because the question "why has this machine shown nothing for four months" should be answerable from the record rather than from somebody's memory. Published pricing from $1,499 a year on the Subscription tier for companies with 50 to 5,000+ employees, including a 60 per cent reduction on retrieval charges. It's our own product, so weigh that accordingly. Where it struggles: no network discovery, so inactivity is not something it observes and you will not get an automated flag from it either way. No software licence management, which is relevant because per-seat licences keep billing during an absence unless somebody acts. And only the Subscription tier publishes a figure, with pay-as-you-go quoted.
Workwize Best for: companies that need a spare pool deep enough that nobody ever proposes reallocating an absent person's machine. Why companies choose it: own warehouses, so buffer stock has somewhere to sit. Where it struggles: no published rate card. The figures on its pricing page are savings claims rather than prices. Live domain is goworkwize.com.
Firstbase Best for: getting a new starter equipped fast, which removes the reason the question was asked. Why companies choose it: strong supply side, clean subscription shape. Where it struggles: publishes nothing on price, and retrieval is the weaker half.
GroWrk Best for: companies whose absent people are spread across markets. Why companies choose it: flexible arrangements rather than one package. Where it struggles: no rate card, and its pricing page runs a competitor cost estimator producing its own estimates.
allwhere Best for: handing logistics over so nobody internal is weighing an asset question against a human one. Why companies choose it: managed service, minimal internal lift. Where it struggles: publishes nothing, so comparison needs a conversation.
Deel IT Best for: companies already running employment through Deel. Why companies choose it: hardware alongside employment with MDM and support included. Where it struggles: publishes no price for IT, and its own page states both 130+ and 150+ countries without reconciling them.
The Decision Table: What Actually Needs Deciding
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Absence of a few weeks | Any | Any | Nothing yet | Do nothing |
| Absence of months, contact ongoing | Any | Any | Audit questions | Suspend access, note the record |
| New starter needs a machine | Any | Any | Procurement delay | Fix procurement, not the allocation |
| Security raises access concern | Any | Any | Live credentials | Suspend access, leave the device |
| No contact possible | Any | Any | Nobody to ask | Escalate to whoever holds the case |
| Absence becomes a departure | Any | Any | Two processes colliding | Use the exit process, not this one |
Rows two and three are where almost every real case sits.
Separate the Access Question From the Hardware Question
If this page has one point, it's this one, and it resolves most of the difficulty on its own.
Almost every reason somebody gives for wanting to collect a laptop during a long absence is actually a concern about access. Live credentials on a machine nobody can see. Session tokens that haven't expired. The possibility that the device is lost or has been handled by somebody else. All legitimate, all genuinely worth addressing, and none of them requiring the device to move.
Suspending access does everything collection would do, and it does it better. It takes effect immediately rather than in a fortnight. It's invisible to the person, who doesn't receive a message about it. It's reversible in a minute when they return. And it covers the case where the device genuinely has been lost or damaged, which a collection request obviously does not and cannot.
So the sequence is: handle access on a timescale that suits the security question, and leave the hardware entirely alone.
Two details worth getting right. Suspend rather than delete, because an account deleted during an absence is a mess to reconstruct and sends a signal nobody intended. And make sure whatever you suspend doesn't generate an automated notification to the person, because a system email saying their account has been disabled is exactly the kind of thing that reads as a termination to somebody who is unwell.
There's a cost angle too. That is a reasonable thing to manage and should be handled quietly. Per-seat software licences keep billing during an absence, and for a long one that's real money across several tools. Reclaiming a licence is an administrative action with no human consequence as long as it's reversible and nobody is told about it in those terms.
Who Is Allowed to Make Contact, and About What
This is the rule that prevents the actual harm, and it's one sentence: nobody contacts somebody on long-term sick leave about equipment except through the route already handling their absence.
The reason it needs stating is that asset processes are built to contact holders. That's their whole design. An audit sends confirmation requests, a reconciliation chases non-responders, a management system flags inactive devices and someone follows up. None of those systems know anything about the person, and all of them will generate a message if nothing stops them.
What arrives is a short, neutral, perfectly reasonable email asking somebody to confirm they still hold asset number such-and-such. Received during a difficult period, it reads as the company checking up on them, or wondering when they're coming back, or preparing for them not to.
So two mechanics. Mark the record in whatever way your systems support so that automated chasing excludes it. And give IT and finance a standing instruction that equipment questions about anybody on extended leave go to HR rather than to the person.
If contact genuinely is needed, which is rare, it should come from the person already in touch with them, be part of a conversation that's already happening, and be framed as making sure they have what they need rather than as confirming what the company owns. In most cases the honest version is to say nothing at all, because there's nothing the person needs to do.
The Procurement Problem Hiding Behind the Question
Worth separating, because the most common trigger for all of this is somebody needing a laptop and the reallocation idea being the shortest path to one.
That's a procurement problem wearing a different hat. The company needs an additional machine, it doesn't have one available quickly, and an apparently idle device is the nearest solution. The arithmetic is sound and the conclusion is still wrong, because the cost being avoided is the price of a laptop and the cost being incurred is a conversation with somebody who is ill.
The fix is a spare pool, and the sizing question is specific. However many devices you currently keep as spares, add the number of people you'd expect to be on extended leave at any time. For most companies that's one or two. It's a small number and it removes the entire category of problem.
If the pool genuinely isn't there yet, the answer to the manager is a date rather than a device. Here's when the machine arrives, here's what the new starter uses in the meantime, and no we're not collecting from somebody on leave. That's a complete answer and it holds up.
One variant deserves naming. Sometimes the absent person's machine is unusually good, and the person needing one would benefit from it specifically. That makes the proposal more tempting without changing anything about the answer, which is still that the machine stays exactly where it is.
When the Absence Becomes a Departure
Sometimes an extended absence ends in somebody leaving rather than returning. That's a different process and the equipment question moves into it rather than being handled separately.
Three things follow. The device is recovered through the normal exit process, which exists, has a known shape, and includes a conversation somebody is already having for other reasons. The timing follows whatever that process says rather than being accelerated. And the asset record is updated to reflect a departure rather than remaining in the leave state, which otherwise leaves a device permanently explained by a circumstance that has ended.
It's worth saying explicitly that the equipment process should never be the thing that signals a departure. If a collection request arrives before anybody has had the conversation, the hardware has told somebody about their own employment, and that's a failure of sequencing that people remember for a long time.
What transfers, what notice applies, what anybody is owed and whether an absence can end in a departure at all differ by jurisdiction and by circumstance. Get local advice rather than reading anything on this page as an answer to those questions.
Where Jurisdiction Comes In
Most of this section is about what not to do with a policy.
What obligations an employer has toward somebody on long-term sick leave, what may and may not be asked of them, what contact is appropriate, what adjustments apply and how any of it interacts with employment protections all differ by jurisdiction and by individual circumstance. None of that is an equipment question and none of it should be settled by an equipment policy.
Anything raised on health or accessibility grounds, including equipment needed to support a return to work, should go to whoever handles that in your organisation rather than through a hardware exception route. That distinction is worth stating plainly in the policy so people know where to take it.
What's portable is narrower and still useful. Separate access from hardware. One named contact route. Don't let automated chasing reach somebody on leave. Note the asset record. Fix the spare pool so the reallocation question stops arising. None of that needs legal advice, and all of it is what determines whether this gets handled well or improvised badly under time pressure.
How to Mark the Record So Nothing Chases Anybody
The advice says note the asset record. Here's what that actually involves, because the detail determines whether it works and most systems make it awkward rather than impossible.
What you want is three things recorded against the device. Three only. A status that isn't active, so the machine doesn't appear in normal inactivity reports. A note explaining that the holder is on extended leave and the allocation is correct, so anybody looking at it gets the answer without asking. And a suppression of automated contact, so audits and reconciliations skip the holder rather than emailing them.
The third is the one that matters and the one most systems don't support directly. If yours doesn't have a suppression flag, the workaround is to move the device into a separate group or category that your audit queries exclude. Clumsy and effective. The thing to avoid is relying on whoever runs the audit remembering, because that person changes.
Then there's who can see the note. An asset record saying somebody is on long-term sick leave is information about that person's health, visible to anybody with access to the asset system, which is usually a wider group than should have it. So word it narrowly: on approved extended leave, allocation confirmed, review with HR. That tells the next person everything they need and nothing they don't.
Set a review date rather than leaving it open. Six months is reasonable. Not because anything should change at six months, but because an open-ended note eventually becomes stale, and a device still marked as on-leave two years after somebody returned is its own small inaccuracy.
And record who made the note. The most common failure in long absences is that everybody who knew the circumstances has moved on, leaving a device nobody can explain. A name on the record means there's somebody to ask, and if that person has also left, the name at least tells you which function to ask.
What to Do About the Licences and Access, Precisely
The page says handle access first and reclaim licences quietly. Both deserve specifics, because the implementation is where the harm actually happens.
For access, the order is: suspend rather than disable where your systems distinguish them, check what notifications each action triggers before taking it, and document what you suspended so restoring it is a single task rather than a reconstruction.
The notification check is the important one. It takes ten minutes. Most identity systems send an email when an account state changes, and some send it to the user's personal address as a security measure, which means a well-intentioned suspension lands in somebody's personal inbox as a message about their account being disabled. Turn that off for this action, or use a mechanism that doesn't trigger it.
Session termination deserves a thought too. Suspending an account doesn't always end active sessions, so a device that's still signed in may retain access for days or weeks. If the security concern is the point, end the sessions as well, which is a separate action in most systems.
For licences, the principle is simple. Reclaim what costs money and leave what doesn't. A per-seat licence on an expensive tool is worth reclaiming for a long absence. A licence on something free or trivially cheap is not worth the administrative step or the risk of forgetting to restore it.
Keep a list of what you reclaimed, because the restore is the part that goes wrong. Somebody returning to find three of their eight tools missing has a worse first week than they needed, and the fix is a list rather than a memory.
One thing not to reclaim: anything that would remove their data. Reclaiming a licence that deletes a mailbox, a file store or a history is not a cost saving, it's data loss with a delay on it. Check what each reclamation actually does to stored content before doing it.
And restore everything a few days before they return rather than on the day, so that if something doesn't come back cleanly there's time to fix it before it's their problem.
Put a reminder in a calendar for that restore rather than relying on somebody noticing the return date, because the absence has by then been quiet for months and the original note may have been written by somebody who has since changed role. A calendar entry costs nothing, and it is the difference between a smooth first morning back and one spent on a support ticket.
When Somebody Returns
The page covers the absence and not the end of it, which is a gap because the return is where the small failures become visible.
Three things need to happen before their first day back, and all three are easy to forget because the absence has been quiet for months.
Access restored and tested. Not just re-enabled, actually checked, because accounts suspended for a long period sometimes come back incompletely: a password expired, a certificate lapsed, an application that revoked its own permission. Somebody spending their first morning back on a support ticket is a poor welcome and entirely preventable by testing the login the week before.
The device checked. A laptop that sat in a cupboard or a flat for eight months may need a long update cycle, may have a battery that's degraded from sitting at full charge, and will almost certainly need a password reset to get into. Arranging for that to happen before day one, either by shipping a replacement or by scheduling a setup call, turns a frustrating morning into a non-event.
And the asset record updated back to active, with the note cleared, which closes the loop on everything above.
There's a fourth thing worth considering. That is whether the equipment is still right. Somebody returning after a long absence may be coming back to a different role, a phased schedule, or adjusted working arrangements, and the setup that suited them a year ago may not now. That's a question to ask rather than assume, and it should be asked by whoever is managing the return rather than appearing as an equipment form.
Anything raised on health or accessibility grounds, including equipment to support a phased return, goes to whoever handles that in your organisation rather than through an equipment exception route. Say so explicitly in the policy, because the person asking should not have to work out which queue they're in.
Writing the Five Lines
The page says the policy is about five lines. Worth setting them out, because the wording carries most of the weight and an improvised version tends to say more than it should.
Something close to this works. Devices allocated to colleagues on extended leave remain allocated to them. Access is suspended for the duration and restored before their return. The asset record is marked so that automated confirmation requests are not sent. Any question about equipment held by somebody on extended leave goes to HR rather than to the individual. And if an absence concludes with a departure rather than a return, the standard exit process applies and this policy stops being the relevant one.
Five sentences, and each one closes a specific failure.
| The line | What it closes |
|---|---|
| Devices remain allocated | The reallocation proposal |
| Access suspended and restored | The security concern |
| Record marked, no automated chasing | The audit email |
| Questions go to HR | Every accidental contact |
| Departure uses the exit process | Two processes colliding |
I'd put the fourth line in bold if your template allows it, because it is the one that prevents the actual harm. In one 237-person company the only breach of this policy in three years came from a reconciliation script nobody had told about the exclusion rule. Notice what is absent: no duration thresholds, no exceptions list, no conditions. Those invite the reading that something changes at some point, which is exactly the inference you do not want anybody drawing.
Where to put it matters. In the equipment or asset policy rather than in anything about absence, because somebody looking up what happens to a laptop should find it where laptops are discussed, and because an equipment rule inside an absence policy reads as though the two are connected in a way they should not be.
Then tell IT and finance separately. They are the functions whose systems will generate the contact, and they will not read the equipment policy. A short note saying that equipment queries about anybody on extended leave come to HR, with no explanation needed beyond that, is sufficient and it is the part that actually prevents the harm.
One addition worth making: state that the policy applies regardless of the reason for the leave. A rule written specifically for sick leave invites somebody to ask whether it covers parental leave, a sabbatical or a career break, and the answer is the same for all of them, so say so once rather than four times.
And review the five lines once a year. Don't treat them as settled. Not because the position should change, but because the mechanics behind them drift: a new identity system sends different notifications, an asset platform adds or removes a suppression flag, an audit process changes hands and the exclusion rule gets lost. The policy stays correct while the implementation underneath it quietly stops working, which is the failure mode worth catching deliberately, because nobody will report it. The check takes twenty minutes: suspend a test account and see what gets sent.
The Cost of Getting This Wrong
There's no meaningful financial cost here, which is precisely why it gets handled badly. One laptop sitting unused for six months costs nothing anybody is measuring.
The cost is entirely in what the person experiences. A collection request, or an audit email, or a system notification about their account, arriving while they're unwell, is a small thing that lands at the exact moment small things carry weight. People describe those messages years afterwards. They also describe them to colleagues, which is how a two-line email becomes a widely held view about what the company is like.
The second cost is that it recurs. Without a written position, every case is decided by whoever notices, so the company behaves differently each time with no explanation for why. That inconsistency is worse than either answer applied consistently.
Third is the security gap that stays open because the conversation got stuck on hardware. A company that spends three weeks debating whether to collect a laptop and never suspends the access has addressed none of the actual risk while generating all of the discomfort.
So the question worth asking isn't whether to collect the device. It's whether anybody has written down that you don't, and whether the access was handled on day one.
When You're Ready to Move Beyond Deciding It Case by Case
The signal is the second time it comes up, because the first time somebody improvises and the second time they improvise differently.
What replaces it is about five lines. Devices stay with people on extended leave. Access is suspended and the asset record is noted. Equipment questions about anybody on leave go to HR and not to the person. Automated chasing excludes those records. The spare pool is sized to cover expected absences. And if an absence becomes a departure, the exit process handles the device on the timescale that process already specifies, not an accelerated one.
Those five lines mean nobody in HR has to make a judgement call during somebody's worst month, which is the actual benefit. Judgement calls made under time pressure by people who don't have the full picture are how the bad versions of this happen.
RemoAsset is our own product, so weigh this accordingly. The relevant part is narrow: a device that's correctly allocated and deliberately not moving should be explainable from the record, so the inactivity question has an answer that doesn't require anybody to remember. It has no network discovery, so it won't flag inactivity for you in either direction, and no software licence management, which is the thing that quietly keeps billing through a long absence.
If you have somebody on extended leave right now and nobody has suspended their access, that's the thing to do this afternoon. The laptop can stay exactly where it is.
Frequently Asked Questions
Should we collect a laptop from somebody on long-term sick leave?
Default no. Write that down so nobody has to decide it under pressure. A device left with somebody costs almost nothing, while a collection request landing during a difficult period costs something that never appears on a budget line. The narrow exceptions are worth naming in advance rather than being improvised, and almost every reason people give for wanting the device back is actually an access concern that collection does not solve.
What should we do about the access on that device?
Suspend it, and do that first. It takes effect immediately rather than in a fortnight, it's invisible to the person, it's reversible in a minute when they return, and it covers the case where the device has actually been lost. Suspend rather than delete, and check that whatever you do doesn't generate an automated notification, because a system email about a disabled account reads as a termination to somebody who is unwell.
Who should contact the person about their equipment?
Only the route already handling their absence. Usually HR or their manager, and never IT directly or an automated system. Asset processes are built to contact holders, so an audit or reconciliation will generate a message unless something stops it. Mark the record so automated chasing excludes it, and give IT and finance a standing instruction to route equipment questions about anybody on leave through HR.
A new starter needs a laptop and one is sitting idle. Why not use it?
Because that's a procurement problem. Not an allocation one. The cost you're avoiding is the price of a laptop and the cost you're incurring is a conversation with somebody who is ill. Answer the manager with a date rather than a device, and fix the spare pool so the question stops arising: add one or two machines to cover expected extended absences and the whole category disappears.
How do we answer an audit asking why a device shows no activity?
One line on the asset record. The holder is on leave and the device is correctly allocated. That's a complete and accurate answer, it doesn't require anybody to be named, and it prevents the same question arriving next quarter from a different direction. Do it when the absence starts rather than when the audit asks, because the people who knew about it may have moved on by then.
What if we cannot contact the person at all?
Then it stops being an equipment decision. Whoever is managing the wider situation decides, and the hardware waits behind every other consideration. The thing to avoid is treating an unresponsive holder as a recovery problem and starting a collection process, which is what an asset system will suggest doing. Suspend access, note the record, and escalate the rest to the people holding the case.
What happens if the absence ends in the person leaving?
The exit process handles the device, with the timing that process specifies rather than an accelerated one. Update the asset record to reflect a departure rather than leaving it marked as on leave, because a record that still says leave two years later is its own small inaccuracy. Nothing accelerates. The important rule is that the equipment process must never be what signals a departure to somebody. If a collection request arrives before the conversation, the hardware has told them about their own employment.
Do software licences need handling during a long absence?
They're worth reclaiming quietly. Per-seat licensing keeps billing regardless of whether anybody logs in, and across several tools over several months that's real money. It's an administrative action with no human consequence at all, provided it is reversible and nobody is told about it in those terms. Keep it separate from anything the person sees, and restore it before they return rather than on the day.
Decide this before you need it, so nobody improvises during somebody's worst month.
