The Patch Task Assigned To An Owner Who Had Left

Vulnerability management found the issue on schedule. It flagged software that moved critical large data files between locations, running on servers with a known vulnerability, and assigned the patch task to the configuration item's listed owner. That owner had left the company months earlier. The servers stayed unpatched until a malicious actor found the same vulnerability and used it to get onto the network.

Key Takeaways

• A patch task was routed to the listed owner of a configuration item who had left the company months earlier, so the servers stayed unpatched until a malicious actor used the same vulnerability to get onto the network.
• Vulnerability scanning and patch task creation both worked. The process broke at the point where a task needs an owner who can act on it.
• A stale owner is harder to find than an empty one. A report grouping configuration items by owner shows no gap, so it takes a cross-reference against the HR database to see that the name belongs to nobody currently employed.
• The fix had four parts: an off-boarding process with certification tasks that escalate to the manager, a full audit of owners against HR records, a six-month clean-up of ownership data, and a weekly cross-check of open patch tasks against the active employee list.
• The escalation path is what stops a repeat. A one-off clean-up only fixes today's snapshot.
• If you couldn't say how many patch tasks currently sit with a departed owner without running a special audit, you have the same blind spot this client had.

The post-mortem, after the breach, is where this came to light. Vulnerability management had done its job. Configuration management had not, and the reason was structural rather than careless, which is worth understanding against what a CMDB is supposed to track about who owns what in the first place.

Why the ownership stopped updating

Technical services in this estate carried ownership information, and that ownership cascaded down to the underpinning infrastructure. In principle, whoever owned the service also owned the servers beneath it, which is a reasonable design.

The design assumed ownership data would be kept current. There was no off-boarding process that checked configuration item ownership against who still worked at the company. When someone left, their name stayed attached to whatever they'd owned, including critical infrastructure, until something forced a review. Nothing did, for months.

This is a different failure from the more familiar "nobody was ever assigned an owner" problem. Here, someone was assigned. The CMDB had a name against every relevant configuration item. The name just wasn't attached to anyone who could act on it anymore.

That distinction matters operationally, not just semantically. An empty owner field is visible. Any report grouping configuration items by owner will show a gap, and most CMDB health checks already look for it. A stale owner field is invisible by exactly the same check, because the field isn't empty. It takes a cross-reference against a system outside the CMDB, in this case the HR database, to notice the name belongs to nobody currently employed, which is the same blind spot behind why unknown CI owners drive up IT spend and, on the departure side specifically, what happens when CI owners leave.

How the gap turned into a breach

Vulnerability management identified a vulnerability in the file-transfer software and raised a patch task, routed automatically to the configuration item's listed owner. The task landed with someone no longer at the company, so nobody picked it up. There was no secondary check that would have noticed the assignee didn't exist in the active employee list.

The servers stayed exposed. A malicious actor found the same vulnerability, compromised a server and gained network access. Data was stolen. The breach reached national media, with the reputational and brand damage that follows from a story like that becoming public.

What makes this worth setting out in detail is where the process actually broke. Not at vulnerability scanning, which worked. Not at patch task creation, which worked. It broke at the single point where a task needs an owner who can act on it, and that point had no check against reality.

The timeline is what made the eventual breach avoidable rather than simply unlucky. The vulnerability had been flagged and the patch task created months before the breach occurred. That's months during which the task sat assigned to nobody, visible in whatever reporting the client had, but not flagged as a problem because the task existed and had an owner listed against it. A report counting open patch tasks by age would have shown this one ageing normally. A report checking whether the listed owner was still active would have shown it immediately. The client had the first kind of report. It didn't have the second.

What the post-mortem changed about how the breach was understood

The instinct after a breach like this is often to focus on the vulnerability itself, and on whether patching could have been faster. That framing misses what actually happened here. The vulnerability was identified promptly, and a patch task was created promptly. The failure sat entirely in whether that task could reach someone able to act on it, which is a configuration management and governance question, not a scanning cadence question.

Reframing it that way changed where the client focused its remediation effort. Rather than tuning scan frequency or patch service levels, the work went into ownership data and the off-boarding process feeding it, because that's where the actual point of failure sat.

What closing the gap actually involved

Apex worked with the client on four connected pieces of work, because fixing the historical data without fixing the process would have left the same gap open for the next person who left.

• A new off-boarding process, with certification built in. When someone leaves, their owned configuration items are identified and certification tasks are created for reassignment. If a certification task isn't addressed within a set window, it escalates to the departing owner's manager, so an unowned critical CI can't sit unassigned indefinitely.
• A full audit against the HR database. Apex compared every configuration item's recorded owner against current employment records, across the whole estate, not just the systems involved in the breach. That surfaced the full scale of stale ownership, not just the one instance that had already caused harm.
• A six-month clean-up of missing and incorrect ownership data. The audit found the gap; the clean-up closed it, correcting ownership across the estate rather than patching the specific configuration items connected to the breach.

The certification escalation is the part that keeps this from recurring. A one-off data clean-up fixes today's snapshot. An escalation path that fires when a certification task goes unanswered keeps the snapshot current as people join, move and leave.

A fourth, smaller piece closes the loop for vulnerability management specifically. Apex added a weekly cross-check between open patch tasks and the active employee list, run independently of the off-boarding process itself. The off-boarding process handles ownership at the point someone leaves. The weekly cross-check catches anything that slips through it for other reasons too, such as a contractor whose end date was never recorded correctly. Vulnerability management tasks are time-sensitive in a way most CMDB records aren't, so this client chose not to rely on the off-boarding process alone, however well it worked.

What this means for your own patch process

A patch task routed to a named owner looks like a process working correctly, right up until you check whether that owner is still there to receive it. If your off-boarding process doesn't touch configuration item ownership, a vulnerability finding can sit assigned to someone who can't act on it, and nothing in a standard patch workflow will flag that on its own.

Check whether your organisation would even know how many patch tasks are currently sitting with a departed owner, without running a special audit to find out. If the answer is no, that's the same blind spot this client had before the breach, and the same cross-reference against the HR database that closed it here will surface it in your own estate.

How Apex helps

We run a CMDB health baseline over two weeks that scores which configuration items are trustworthy and which are guesses, ownership included. The output is a report you can take to your change advisory board, showing exactly where ownership data has drifted from reality before it becomes a patch task nobody can complete.

Book a CMDB diagnostic call to talk through your own off-boarding process, or go straight to booking a meeting.

Frequently asked questions

How common is stale CI ownership after someone leaves a company?

It's one of the most common gaps we find, because most off-boarding processes cover access removal and equipment return but not a check against configuration item ownership in the CMDB. Without a deliberate step for it, ownership data only gets corrected when someone notices, which is often after an incident.

Why didn't vulnerability management catch that the owner had left?

Vulnerability management tools work from the CMDB's ownership field and route tasks accordingly. They have no independent way to check whether the named owner is still an active employee unless that check is built into the workflow, which it wasn't here.

What does a certification escalation path actually look like?

A recurring task asks the named owner to confirm they still own a configuration item. If it isn't actioned within a set window, usually a matter of weeks, it escalates automatically to that person's manager, so an unowned or wrongly-owned critical configuration item can't sit unresolved indefinitely.

Does this only matter for security-critical infrastructure?

No, though the consequences are more visible there. Stale ownership affects change approval, incident routing and patch assignment across the estate. Security infrastructure just tends to be where a gap like this gets discovered, because the cost of missing it is higher and faster to surface.

Written by Kinga Staniszewska, Apex Configuration Group.

Book a free call to discuss how Apex can help you on your journey to a better CMDB