What Happens to a Laptop During Six Months of Leave

TL;DR

• A device held by somebody on long leave sits in a state no process covers. It is neither issued-and-in-use nor returned, and most registers have no value for it.
• The variable that decides what to do is not the reason for the leave. It is how predictable the return date is.
• You can close the data obligation without moving the hardware. A device encrypted at deployment can be cleared remotely, which separates the data question from the logistics question entirely.
• Leaving company access live for nine months is the most common arrangement and the hardest one to defend if anybody asks.
• Add one register status for this population, or your quarterly reconciliation will read every one of these rows as a stale assignment and somebody will chase a person on medical leave.
• Plan the return, not just the departure. Somebody who has not signed in for nine months frequently cannot, and that is a first-morning problem you can prevent in advance.

The Laptop Nobody Had a Status For

A company of 240 people ran a reconciliation of its asset register against its device management console and found nine machines that had not checked in for more than four months.

Seven were straightforward: two in a storeroom, five with people who had left. The other two belonged to employees on long leave, one on parental leave with a return date eleven weeks out and one on medical leave with no date at all. Both machines were at home, switched off, holding company data, with company access still live.

Nobody had made a decision about either device, because there was no point in the process at which a decision was required. The leaver process fires on a leaving date. The joiner process fires on a start date. A period of leave has neither, so the device fell between two processes that were both working correctly.

Recommended Tools

Best tools for Device Management

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

The reconciliation report listed both as assignments to chase, which is how the IT coordinator ended up drafting an equipment-recovery message to somebody signed off sick. The message was caught before it was sent. That is the actual risk in this area, and it is a data-modelling problem rather than a judgement problem.

The Variable That Decides It

Not the reason for the leave. The predictability of the return.

Four shapes of long absence, and they divide cleanly into two groups on that one question.

A known return date. Parental leave with a planned return, a sabbatical, a fixed secondment. You know roughly when the person comes back and you can plan against it. Recovering the device is usually unnecessary friction, because you would be shipping it out again on a date you already have in a calendar.

An unknown return date. Medical leave, extended compassionate leave, any absence that may end next month or next year. The device's remaining useful life is being consumed against a date nobody can name, and the decision has to be made on the information you have rather than deferred until you have better information, because better information may never arrive.

So the policy should branch on that, and only on that. Branching on the reason for the absence puts the HR team in the position of making equipment decisions that read as commentary on somebody's circumstances, which is a conversation nobody wants and which a date-based rule avoids entirely.

What an employer may or may not do with equipment during a period of leave, and what notice or consent is involved, differs by jurisdiction and by circumstance. Take local advice on your own position rather than relying on this article or on how another company handles it. What follows is about the systems and the sequence.

When You Should Do Nothing

When the absence is short

Under about six weeks, leave the device where it is and change nothing. The round trip costs more than it returns, the person is coming back, and recovering a laptop for a five-week absence sends a signal you do not intend. Most companies get this right by default.

When the return date is firm and close

A known return date inside a quarter is usually a reason to leave the hardware alone and address only the access question. The device is not going to be reissued to anybody else in that window, so recovering it gains you a machine you will not use and a shipment you will pay for twice.

When there is no data on it worth worrying about

Rare, and worth checking rather than assuming. A device used only through a browser with no local storage, on a managed profile that keeps nothing on disk, is a different proposition from a laptop with four years of local files. The honest version of this test is whether you could say what is on it, and for most machines the answer is no.

The edge case that forces a decision

A refresh cycle that will pass during the absence, or a device already at the end of its warranty. In both cases the machine will be obsolete or unsupported by the time the person returns, which means you are planning a replacement anyway and the sensible moment to recover it is now rather than on their first morning back.

Five Questions People Ask First

"Can we just ask for it back?" You can ask, and the question is whether you should and how it is framed. A request that reads as procedural and applies to everybody in the same situation is very different from one that arrives individually during somebody's leave. If you are going to do this, the rule needs to exist in writing beforehand and apply by return-date certainty rather than by circumstance, which is the whole argument for having a policy at all.

"Should we revoke their access?" Access and hardware are separate decisions and treating them as one is the most common error here. There is a strong case for suspending access during an extended absence, and essentially no case for leaving an unused account live for nine months. Suspension is also reversible in a way that recovering a laptop is not.

"What about the data on it?" This is the question with the best answer, because you can close it without touching the hardware. See the section below. A device encrypted from deployment can be cleared remotely in seconds, which means the data obligation and the hardware logistics stop being the same problem.

"Does it come out of our device count?" It should not, and this is where registers mislead people. The machine still exists, is still assigned, and is still your asset. What it needs is a status that says so without implying it is in daily use, because a count of active devices that includes it overstates your fleet and a count that excludes it loses the row entirely.

"What if they do not come back?" Then the absence becomes a leaving date and the normal process applies, with the one difference that the recovery conversation happens at a distance and often through a third party. The practical preparation is to have a current delivery address and a phone number, which is the same preparation every other recovery needs and is the thing most registers lack.

The Three Options

The middle row is the one most companies have not considered, and it dominates the other two for the majority of cases. It closes the exposure, costs almost nothing, does not require anybody to post a laptop, and leaves the hardware in place for a return you have not had to predict.

What it does require is that encryption was enforced at deployment rather than considered at the end of a device's life, which is the single decision that makes this whole area cheap.

Closing the Data Obligation Without Moving the Hardware

This is the part worth taking away even if you change nothing else.

Two separate obligations hang off a device in somebody's home. One is that the company data on it is accounted for. The other is that the hardware is where your register says it is. Companies treat these as one thing because a recovery addresses both at once, and that coupling is exactly what makes every option feel expensive.

For a device encrypted from its first day, destroying the encryption key renders the contents unreadable in seconds, at any distance, regardless of drive size. The machine remains physically where it is. The data is gone, and you can record the date, the method and the person who did it against the asset row. The obligation is closed and nothing was shipped.

Three practical conditions.

Encryption has to have been enforced at deployment. A device that was never encrypted needs a full overwrite, which is slow on a large drive and unreliable on solid-state media because wear levelling can leave blocks the overwrite never reaches. If your fleet is not encrypted from deployment, fixing that is worth more than any policy in this article.

The device has to check in. A machine switched off since February will not receive the instruction until somebody powers it on, so the command sits queued and the obligation stays open in the meantime. Record it as pending rather than closed, because a queued action is not an outcome.

The person should know. Clearing a device somebody is holding without telling them is the kind of surprise that turns a procedural matter into a grievance. One sentence, sent in advance, as part of the same message that confirms their access is being suspended.

And do not confuse this with a lock. Locking a device during an absence achieves very little and creates a machine the holder cannot use and may not be able to return easily, which is the same mistake as locking a laptop at the start of a notice period.

The Register Status Nobody Has

Most registers have three states that matter: in use, in storage, and disposed of. A device held by somebody on long leave is none of them, so it gets recorded as in use and then shows up in every report as something it is not.

Add a fourth. One value, something like assigned and dormant, with two fields beside it.

An expected review date. Not a return date, which you may not have, but a date on which somebody looks at the row again. Ninety days is a reasonable default. This is what prevents a device drifting for two years without a decision, and it is the difference between a deliberate arrangement and an oversight.

The data state, with its date and method. Open, cleared, or pending. The whole point of the previous section is that this field can say cleared while the hardware is still in somebody's flat, and a register that cannot express that forces you to choose between a false status and a recovery you do not need.

Two reports fall out of this for free. Every dormant device whose review date has passed, which is your action list. And every dormant device with an open data state, which is your exposure list. Because both of those are currently invisible in most companies, the absence of the status is not a tidiness problem, it is the reason nobody can answer the question.

How to Choose: Five Questions Before You Decide

Is the return date known? The only question that should drive the hardware decision. Known and inside two quarters, leave the device. Unknown, decide now on the information you have rather than deferring, because deferring is itself a decision and it is the one that costs the most residual value.

Is the device encrypted, and can you evidence it? If yes, the data question is solved remotely and cheaply and you should do it as a default rather than a judgement call. If no, you have a different and larger problem than this article, and the fix applies to every device you will ever retire.

Will a refresh or warranty expiry fall inside the absence? If so, you are planning a replacement anyway. That changes the calculus completely, because recovering now and issuing a current machine on their return is better for them and cheaper for you than shipping an obsolete laptop twice.

Do you have a current address and phone number? Check rather than assume. For somebody hired remotely three years ago the address in your records may be the one used for the original delivery, and confirming it now is a single question you can ask while they are still in contact with you rather than after an absence has made contact awkward.

Is the rule written down and does it apply to everybody? If the answer is no, do not start with the individual case. Write the rule first, branch it on return-date certainty, and apply it from a date forward. A decision made individually during somebody's leave is the version of this that generates a complaint, however reasonable the decision.

The Options in Practice

Worth being clear that very little of this is a software purchase. The capability you need is in your device management console and your register, and the gap is almost always a missing status and a missing rule rather than a missing product.

Your existing device management console

Does nearly all of the work. Remote wipe, encryption enforcement, check-in dates, and in most products a way to mark a device as excluded from compliance reporting so a dormant machine does not sit permanently red on a dashboard.

Where it struggles: it has no concept of why a device is dormant, so a machine on long-term leave looks identical to one in a drawer. That distinction has to live in the register, which is the point of the status above.

Your asset register

Where the status, the review date and the data state belong. Any register will hold them, including a spreadsheet, and the work is deciding the values rather than buying a tool.

Where it struggles: nothing populates these fields automatically, so somebody has to set them when an absence starts. That means the HR system has to tell somebody the absence has started, which is an integration question and usually a manual one at this size.

Your HR platform

The trigger. A long absence is recorded here first and almost never flows anywhere else, which is why the device decision never gets made. If your HR platform can fire a notification when an absence exceeds a threshold, that single automation closes most of the gap in this article.

Where it struggles: absence data is sensitive and the people who can see it are deliberately few, so the notification needs to carry the fact of a long absence without carrying the reason. That is a design decision worth making explicitly rather than discovering during implementation.

Lifecycle platforms

Where recovery is the chosen route and the person is in another country, a platform that handles collection from a residential address does real work, since a cross-border collection from a home is the case a courier account handles worst.

Workwize, Deel IT, Firstbase, GroWrk and allwhere all operate in this space, and none publishes a price. Disclosure: RemoAsset is owned by the same people who publish HROpsLab. It is relevant here only because it holds the serial and the delivery address from the original order, which is what a recovery depends on and the thing most registers lack for exactly this population. It publishes no price and requires a demo, it is much weaker for hardware it did not supply, and it is not a certified disposal vendor.

The Comparison

The third row is the recommendation for most absences over three months. It is the only option that closes the exposure without a shipment or a difficult conversation, and the reason it is not the default everywhere is that it depends on a deployment decision about encryption made years earlier.

The Decision Table

Planning the Return, Not Just the Departure

Every policy in this area addresses the start of an absence and almost none addresses the end of one, which is where the avoidable first-morning failure lives.

Somebody returning after nine months faces a specific set of problems that have nothing to do with the hardware decision you made.

They cannot sign in. A password expired months ago, and the reset flow sends a code to a second factor enrolled on a phone they have since replaced. This is the single most common return-to-work IT failure and it is entirely preventable with one check a week beforehand.

The device is far behind. Nine months of operating system and application updates arrive on their first morning, which can consume most of a day and several restarts. Running those before the return date, if the machine can be woken and reached, converts a lost day into a background task.

Their access is suspended and nobody re-enabled it. The suspension was deliberate and the restoration was not scheduled, because the trigger for it is a return date in a system the IT team does not watch.

The applications have changed. The company moved to a different tool in month four. Nobody told them, and nobody would, because the announcement went to people who were working.

So the fix is a short checklist that runs a week before the return date, owned by whoever owns onboarding rather than by the manager.

That checklist is five lines and it is the difference between somebody returning to work and somebody spending their first day in a password reset loop.

Wiring the Trigger Without Leaking the Reason

Everything above depends on somebody learning that a long absence has started, and that is the step with no owner. The absence is recorded in the HR platform by people who can see why, and the device decision belongs to people who should not. So the integration has a privacy constraint built into it, and getting that constraint right is what makes the automation acceptable rather than a problem of its own.

Three things have to cross the boundary and nothing else.

The person's name or employee identifier. Enough to find their assigned devices and their account.

The date the absence started and, if known, the expected return date. Nothing about the category of absence, nothing about duration beyond the dates themselves.

A flag that it crossed the threshold. Not the threshold logic, just the fact. Whoever receives it needs to know an action is due, not how the system decided that.

That is the whole payload. Notably absent: the reason, any medical or family detail, any free-text note from the absence record, and any indication of whether the absence is paid. Because absence records routinely carry all of that in adjacent fields, an integration built by exporting the absence row and filtering afterwards will leak it the first time somebody adds a field, which is the failure mode to design against rather than to catch in review.

Four ways to build it, in increasing order of effort.

A monthly report, run by somebody who already has access. Whoever administers the HR platform runs one filtered list each month, every absence over 90 days with no recorded return, and sends the three fields to whoever owns the register. This takes about ten minutes, needs no engineering, and is where most companies at under 300 people should start. Its weakness is that it is monthly, so a device can sit for up to 30 days before anybody looks.

A scheduled report the platform sends itself. Same output, no human in the loop, and most HR platforms will do this with a saved filter and a delivery schedule. Restrict the columns in the saved view itself rather than in the recipient's head, because a saved view with three columns cannot leak a fourth.

A webhook or integration on an absence-threshold event. Where the platform supports it, this is clean and immediate, and it is the point at which the field restriction matters most. Specify the payload explicitly, test it with a record that has every optional field populated, and read what actually arrives rather than what the documentation says will.

A derived trigger from your own device data. No HR integration at all: flag any assigned device that has not checked in for 90 days and ask the assignment holder's manager whether the person is working. This is the route for companies that cannot get HR data out, and it is weaker in one specific way, which is that it cannot distinguish a dormant device from one in a drawer. That distinction is the thing this whole article is about, so treat it as a fallback rather than a design.

Then set the threshold deliberately. Thirty days is too short and produces noise from ordinary holidays. Ninety days is the figure that matches the decision rule, since it is roughly where the access suspension argument becomes strong and where a device's idle time starts costing real residual value. A company with 240 people and typical absence patterns will trigger this perhaps 3 or 4 times a year, which is small enough that a monthly report is genuinely adequate and large enough that nobody will remember to check without one.

And log what the trigger did. One line per event: the date, the device, the action taken and who took it. Twelve months later that log is the only evidence that the arrangement is being applied consistently to everybody rather than case by case, which is the thing that makes a rule defensible.

What Getting This Wrong Costs

The visible cost is the device, and it is the smallest of three. A laptop idle for nine months has lost most of a year of its useful life, and at a company with a handful of long absences at any time that is a real number nobody reports.

The second cost is the exposure you cannot describe. A machine with company data on it, not checking in, with somebody who is not working, and an account still live. Each of those is individually defensible and the combination is the one that reads badly in a security questionnaire, particularly because the honest answer to how many such devices you have is usually that nobody knows.

And the third is the one that actually hurts, which is the message that should never have been sent. A reconciliation report that cannot distinguish a dormant assignment from a stale one will eventually produce an equipment-recovery request to somebody on medical leave, and the fact that it was generated by a process rather than a person is not a defence anybody accepts. That is a data-modelling failure with a human consequence, and the fix is one status field.

The reframing question: if somebody asked you today how many company devices are held by people who are not currently working, and whether the data on each has been cleared, how long would the answer take and would you be confident in it?

When You're Ready to Write This Down

The honest position is that most companies do not need a policy here so much as a decision rule, and the rule is short enough to fit in a paragraph.

The trigger worth acting on is not a headcount or a number of absences. It is the first time your reconciliation produces a row you have to manually exclude because the person is on leave, because that tells you the register cannot express the situation and somebody is holding the knowledge in their head instead.

The sequence costs nothing and does not start with a tool. Add the dormant status and its three fields to whatever register you have now, and backfill it for the absences you currently know about. Set the rule to branch on return-date certainty rather than on the reason for the absence, so nobody in HR is making equipment judgements about somebody's circumstances. Decide your access suspension threshold and automate it, because three months of an unused live account is the easiest thing on this list to fix.

Then write the five-line return checklist and give it to whoever owns onboarding. Of everything in this article, that is the part the returning person will actually notice, and it is the part that costs the least.

Here is the rule in the paragraph it should fit in, as something you can adapt rather than draft from nothing. Where an absence is expected to exceed 90 days, company access is suspended and the data on any assigned device is cleared remotely, with the date and method recorded; the person is told in one sentence before either happens. The hardware stays with them where a return date is known and falls inside two quarters. Where no return date is known, or where a refresh or warranty expiry falls inside the absence, the device is recovered and a current machine is issued on return. The assignment is marked dormant with a review date 90 days out and a named owner, and access is restored on a scheduled task a week before any confirmed return date.

That is six sentences, it branches only on dates, and it never requires anybody to make an equipment judgement about why somebody is away. Adapt the thresholds to your own refresh cycle and take local advice on anything touching notice or consent, then publish it where the rest of your equipment policy lives rather than keeping it in the IT team's head.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements, which is why the owner's own product is named above with its three limitations rather than its three best features.