Your CMDB's owner field is wrong for a third of production systems - how do you fix triage?

## Why this is a leadership question rather than a tooling one Every enrichment lookup a SOC runs against asset data is a dependency on a system another organisation maintains for a different purpose. A configuration management database exists for change control, licensing and service management; nobody funds it so that a security analyst can find a human at 04:20. When its owner field decays - and it always decays, through reorganisations, leavers, team splits and acquisitions - the SOC feels the cost and has neither the mandate nor the budget to fix the cause. That asymmetry is the whole problem, and it is why the answer is part negotiation, part compensating design, and part accepting a residual. ## Measure it in their currency A security team saying *your data is bad* gets nothing. A security team saying *stale ownership adds a median of eleven minutes to every alert on a production database, sent 38 escalations to teams that no longer own the service last quarter, and in two cases delayed containment past an hour* gets a meeting. The metrics worth collecting are cheap because they fall out of case data you already keep: - Median and 90th-percentile minutes from alert open to a human confirming ownership. - Number of escalations routed to the wrong team, and the time they burned. - Alerts closed with ownership never established. - Coverage: share of production assets whose recorded owner resolves to a current employee in a current role. That last one is the number to publish per owning team, because it puts the cost on the group that can fix it and creates a comparison they care about more than any policy. ## Stop relying on a single declared source The deeper fix is architectural. **Declared data decays; observed data is regenerated continuously.** Ownership can be inferred from signals the estate emits anyway: who deployed to the system in the last ninety days, whose on-call rota covers the service, which repository's code owners build it, which team's service principals authenticate to it, what the cloud resource tags say, who has approved recent changes. None is authoritative alone; together they beat a two-year-old field. So model ownership as a resolution with precedence rather than a lookup: prefer a current on-call rota, then recent deploy or change actors, then code owners, then the CMDB, and surface the disagreement to the analyst instead of hiding it. An analyst who sees *CMDB says A. Mensah (no longer active); on-call rota says Payments Platform, primary reachable* makes a better and faster decision than one handed a single confident wrong answer. ## Use the leverage you actually have You will not get a data-quality programme funded on security's ask alone. What you can often get is a **gate at a moment when someone needs something from you**: production onboarding, telemetry onboarding, a change freeze exception, a compliance attestation. Requiring a resolvable owner before a system is accepted into production monitoring is defensible, cheap for the requesting team, and it fixes new drift at source. It must be agreed with the platform owners rather than announced, or it becomes a queue of exceptions that erodes in a quarter. In regulated environments there is a second lever worth using honestly: incident-notification obligations and audit findings put a clock on identifying affected systems and their owners. That argument moves executives when an operational one does not. Use it where it is true; inflating it burns the credibility you will need next time. ## Decide what you will not do - **Do not build a shadow CMDB.** A security-maintained copy of the whole estate is accurate for one quarter and then becomes a second wrong source with your name on it. Curate a small override table for the crown-jewel systems - the ones where a 04:20 call actually happens - and let the long tail be resolved by the observed signals. - **Do not let missing ownership close alerts.** Ownership is consequence enrichment; its absence says nothing about whether activity was malicious. An unowned asset arguably deserves more scrutiny, not less, because nobody is watching it. - **Do not gate detections on asset data.** Rules that only fire on assets with a valid criticality field create a blind spot exactly where the records are worst. ## Accept and state the residual After all of it, some systems will still resolve to nobody at 04:00. The honest position is to say so, to bound it - which tier of asset, what share, what the fallback path is - and to have the fallback rehearsed rather than improvised: platform escalation line, duty manager, the authority for the SOC to take a defined containment action on an unowned production system without an owner's sign-off. Getting that last authority agreed in advance, in daylight, is often worth more than any amount of data cleaning, because it converts the unresolvable case from a stall into a decision somebody has already approved. ## What an interviewer is listening for The weak answer is *raise it with the CMDB team and add it to the risk register*. The strong answer quantifies the cost, redesigns around declared data rather than waiting for it, finds a gate with real leverage, names what will not be built, and pre-agrees what the SOC may do when ownership simply cannot be established.