The contractor left and took the keys with them

Signals to watch

• offboarding has no single checklist owner
• devices are written off before they are searched
• access revocation relies on manual memory

Composite industry case. This page describes a reusable operating problem and decision method. It does not represent a named customer, real conversation, contract, revenue result or testimonial.

The person left but their device never did

A contractor finishes their last engagement on Friday. By Monday the badge is deactivated, the email mailbox is converted to shared, and the ERP login shows a 403. Standard checklist, clean, right?

Then the finance team runs a quarterly audit. They find a contractor-owned laptop that still has a VPN client certificate valid for another three months. The device was never reported as missing because IT did not know it existed — it was provisioned outside the official hardware catalogue by a project manager who needed “someone fast.” The contractor, now working for a competitor, still has network-level access to a build pipeline that pulls proprietary source code.

This is not a breach of policy. It is a failure of closure: no single document ever asked who gave the contractor a device, what accounts were created outside the HR system, which shared drives held local copies, or who was supposed to approve the final return. The organization had an offboarding process for employees. Contractors fell into the procedural gap between IT, Procurement, and the project lead who hired them.

Every team that has hired external contractors for more than twelve months has a version of this story. It does not require a malicious actor. It only requires that person, device, accounts, keys, data copies, and the approving manager were never assembled on the same checklist at the same time.

Why teams misread the offboarding gap

Workplace IT leads tend to treat contractor offboarding as a simplified version of employee offboarding. Strip the pension, skip the exit interview, deactivate the accounts — done. The assumption is that the same automation that flags an inactive employee after seven days will catch a contractor.

It will not, for three structural reasons.

First, contractors are often onboarded outside the central IT catalogue. A project lead buys a laptop with a department card, a team lead spins up a cloud VM with their own subscription, or an engineering manager provisions a pair of SSH keys during a late-night deployment. IT discovers these assets when the contractor’s access is already stale — or when an incident is reported.

Second, the concept of “data copy” has no owner in the offboarding workflow. Employee data can be preserved to a network drive and handed to a successor. Contractor data lives on devices that leave the premises: a personal laptop, a phone used for two-factor, a USB drive that was “just for the presentation.” Nobody has asked whose responsibility it is to confirm that those copies have been returned or wiped.

Third, closure has no accountable reviewer. Employee offboarding typically ends with a signed clearance from HR. Contractor offboarding ends when the ticket is closed — which may mean nothing more than “accounts disabled.” The question of whether every account was discovered, every device was returned, and every key was revoked goes unanswered because there is no person whose job it is to answer it.

The Evidence Review Framework

The fix is not a larger automation scope. It is a review-backed closure checklist that surfaces evidence, assigns ownership, and enforces a decision window. You can build it today with a spreadsheet and three columns.

Evidence column. For every contractor engagement, predefine what counts as proof of closure. Device return: a signed receipt or a remote-wipe confirmation. Account deactivation: a screenshot or an API query result from each system where the contractor had access. Data removal: a declaration from the contractor’s direct lead that shared files have been migrated and local copies are not required. Key revocation: a confirmation that API tokens, SSH keys, and VPN certificates have been rotated — not just disabled, but rotated, because a disabled key still exists in the key store and can be re-enabled by mistake.

Owner column. Each piece of evidence needs a named person who produces it. Not “IT” — “Jane Chen, IT operations.” Not “project lead” — “Marco Ruiz, senior product manager.” When a name is attached, the evidence has someone to chase.

Decision-window column. Every checklist item gets a due date and a follow-up interval. Fourteen days for device return. Seven days for account verification. Twenty-four hours for key rotation. If the deadline passes without evidence, the item escalates to a pre-designated reviewer who decides: accept a compensating control, extend the window, or flag the engagement for security review.

This framework is useful without any software. A Workplace IT lead can implement it for the next five contractor offboardings as a pilot, using a shared document and calendar reminders. The act of naming owners and setting deadlines already eliminates the two most common failure modes: nobody’s problem and no time to fix it.

What automation cannot replace

A checklist with evidence, owners, and deadlines surfaces what needs human judgment. The reviewer must still look at the evidence and decide. Is a remote-wipe confirmation from a device that never connected to the corporate network sufficient, or does it require physical inspection? Does a manager’s declaration that “no data is at risk” count as closure, or does it trigger deeper verification? These decisions depend on context, risk appetite, and the reviewer’s knowledge of the engagement.

Automation can continuously discover which accounts are active, which devices have not checked in, and which credentials are still valid. It can organize that evidence into a per-contractor profile and flag items that the checklist has not closed. It can enforce the decision window by escalating overdue items. But the final signature — “this contractor’s access is fully revoked” — belongs to a human who has examined the evidence and is accountable for the decision.

A signal-discovery layer that watches identity providers, device management consoles, and cloud infrastructure means the checklist is never out of date. An evidence-organization layer means the reviewer does not waste time collecting logs from five consoles. A human review workflow that routes the right evidence to the right owner at the right deadline means the decision window is real, not aspirational. Each layer amplifies the other. None replaces the reviewer who signs the closure.

Frequently asked questions

What is the single most overlooked item in contractor offboarding?

Data copies on personal devices, local browser profiles, and saved network shares outside the managed environment.

Who should own the closure checklist?

A named human reviewer — not a system, not a ticket queue. IT operations, security, or the contractor's direct lead, depending on organization size.

Does automation replace the reviewer?

No. Automation surfaces evidence and enforces deadlines; only a human can evaluate context, approve exceptions, and sign the closure.