Succession on configuration item (CI) ownership means that when an owner leaves or changes role, every CI and service they were accountable for passes to a named successor on the day it happens. Without it, the configuration management database (CMDB) keeps pointing at someone who's gone. Approvals wait for them, certification tasks sit in their queue, and remediation work is assigned to an account nobody reads. The fix is a joined-up off-boarding process, regular certification with escalation, and a periodic check of ownership against the people who actually work for you.
How a departed owner becomes a security incident
On one estate of several million CIs, the belief was that technical services held the right ownership, and that ownership cascaded correctly to the infrastructure beneath them.
There was no off-boarding step for CI ownership. People who had left the organisation were still recorded as technical service owners, and therefore as owners of the underlying infrastructure.
Vulnerability management identified a vulnerability in software used to move large, critical data files between locations. The task to patch the affected servers was assigned to an individual who had left months earlier. The servers weren't patched.
A malicious actor compromised one of those servers, gained access to the network and stole data. The ownership gap only came to light in the post-incident review, and the organisation suffered serious reputational damage.
Why cascaded ownership makes succession urgent
Inheriting ownership from the service is good practice. It keeps infrastructure ownership consistent and reduces manual effort.
It also means one stale owner on a service becomes a stale owner on every CI beneath it. A single missed off-boarding can orphan hundreds of servers at once, and every task routed by ownership goes to the same empty inbox.
| Work routed by CI ownership | What happens when the owner has left |
|---|---|
| Vulnerability remediation | Tasks sit unworked, and the exposure stays open |
| Change approval | Changes stall, or someone approves without the right knowledge |
| Certification | Records go unconfirmed and drift |
| Incident escalation | Escalations go to nobody during an outage |
Building succession into off-boarding
Add CI ownership to the leaver process. When a leaver or role change is raised, check whether the person owns any services or CIs. If they do, the process can't complete until a successor is named.
Default to the manager, then reassign. If no successor is named by the leaving date, transfer ownership to the leaver's manager automatically. That's better than an inactive account, and it puts the decision with someone who can make it.
Transfer open work, too. Reassign open remediation tasks, approvals and certifications at the same time as ownership. Otherwise the new owner inherits the records without the work.
Record a deputy. For critical services, hold a named deputy alongside the owner, so there's always a second person during absence or transition.
Catching what off-boarding misses
No process catches everything. Two controls find the rest.
Certification with escalation. Ask owners to confirm their critical ownership data on a regular cycle. If a certification task isn't completed, escalate it to their manager. An owner who has left will never answer, so escalation turns the silence into a finding.
Reconciliation with the people directory. Compare every owner in the CMDB with your human resources records. Report owners who are inactive, have left, or have moved to a role that no longer fits the service.
For the estate above, we designed a new off-boarding process and put certification in place for critical ownership data, with escalation to managers. We then audited ownership against the human resources database, and ran a six-month clean-up of missing and incorrect ownership.
Measuring ownership health
Track key performance indicators (KPIs) that show whether succession is working:
- CIs and services owned by inactive accounts, which should be zero
- open remediation tasks assigned to inactive accounts
- certification completion rate, and the number escalated
- critical services without a named deputy
Review them monthly, alongside vulnerability ageing. Name the owner of the leaver integration and of the directory reconciliation in the RACI (responsible, accountable, consulted, informed) for configuration management.
For the cost side of missing ownership, see our article on unknown CI owners. For how ownership roles differ, see CI data owner vs process owner.
How Apex helps
Our data quality assessment measures your CMDB against weighted critical success factors, key performance indicators and metrics, including ownership accuracy against your people directory. It shows which services and CIs are owned by people who've left, and what remediation work is stuck behind them. We scope it with you at an initial consultation.
For a wider view, our two-week CMDB health baseline scores which CIs are trustworthy and which are guesses, in a report you can take to your change advisory board.
Book a CMDB diagnostic call or arrange a meeting with a consultant.
Frequently asked questions
Should ownership sit with a person or a group?
Accountability needs a named person. Support work can sit with a group. Record both.
What if nobody will accept ownership of a service?
Escalate to the business owner of the application or the head of the platform. An unowned critical service is a risk someone senior needs to accept or resolve.
How often should ownership be certified?
Critical services at least quarterly, others less often. Base the cycle on criticality.
Can the reconciliation with the people directory be automated?
Yes. A scheduled comparison between owner records and active user accounts can raise tasks automatically for every mismatch
.
Written by Iain Moone, Apex Configuration Group.
Unknown CI Owners Are Driving Up IT Spend
IT Cost Optimization Strategies To Reduce Total Cost Of Ownership
