Getting an owner to acknowledge an asset they did not know they had

A certificate appeared in an external scan. The subject field named an application team that had been dissolved two years earlier. The subdomain was still resolving. Traffic was still hitting it. Nobody in the current org chart had ever heard of it.

That discovery is not unusual — but the conversation it opens should be. The instinct is to hunt for a historical owner: who built this, whose team was dissolved, who left the org. That instinct is largely wasted effort. The more productive frame is forward-looking: what is this asset, should it exist, who is going to be accountable for its disposition, and has anything gone wrong during the period it was unmonitored? This article starts at the moment you need a person to take responsibility for an asset — not to assign blame for how it got there.

Why this situation should be the exception

Before describing how to conduct an ownership conversation, it is worth naming the structural failure that makes the conversation necessary in the first place.

Ownership of an asset should attach at provisioning, to a durable organisational entity, and be enforced at the control plane — not suggested by policy and hoped to persist through personnel changes. When a team dissolves, or a key person leaves, those are change management events. They have defined inputs and required outputs, one of which is asset handoff. A team that dissolves without its assets being transferred to an accountable successor is an organisational failure, in the same category as manually deprovisioning individual accounts for a leaver and hoping you catch them all rather than automating the process.

The hunt described in this article — working backward through DNS records, billing data, and access logs to find someone who might accept accountability — is what happens when lifecycle controls are absent or immature. It should be the exception path, not the standard operating procedure. Acquisitions and mergers make this more complex still: assets arrive with different naming conventions, cost structures, and no clean mapping to the acquiring organisation's ownership model. In those cases, the blameless engineering posture is the only workable one — it does not matter how the asset got there or whose fault it is that ownership lapsed; the question is what needs to happen next and who will drive each part of that work.

A parent-level article on mature asset lifecycle governance — covering provisioning controls, change management triggers, and acquisition integration patterns — is the appropriate context for this guidance. This article addresses the escalation path after an orphan has been confirmed.

Before ownership: ask what the asset is

An ownership conversation is premature if you have not first established what the asset is and whether it should exist. The questions to answer before making any contact:

These questions shape the conversation significantly. A candidate owner who is told "we believe this asset is actively serving traffic and needs continued management" has a different discussion than one who is told "this asset appears dormant and the question is whether to transfer it or retire it." Answering them first also prevents a common failure mode: successfully assigning ownership of an asset that should have been decommissioned, creating ongoing maintenance burden for a team that had no prior relationship with it.

Why the first reply is usually "That is not mine"

Denial is not obstruction. It is usually accurate. When an external asset predates a team's formation, reflects a discontinued product line, or carries a subdomain from an acquisition, the person you contact genuinely may have no relationship with it. The refusal is informational — it tells you the routing rule fired at the wrong target.

The consequence of accepting that refusal without challenge is that the asset stays unowned, which in ASM terms means it stays unreduced. An externally reachable endpoint with no accountable team has no patch schedule, no certificate renewal owner, and no decommission authority.

The decision at this stage: distinguish a wrong-target refusal from an I-do-not-want-this refusal. Wrong-target means your routing logic misfired — fix the evidence chain and re-route. I-do-not-want-this means the correct contact has been reached and is declining — that triggers a different escalation path covered in "What To Do With A Refusal."

What evidence establishes an accountability chain

The goal is not to prove historical ownership or assign blame. It is to establish the shortest accountability chain between the asset and a current, reachable person or team — and to do that by presenting data, not making accusations.

An effective first contact looks like this: "This domain was provisioned under your cost centre. We show two IAM identities from your team's group authenticating to it in the last 14 days. We see no external traffic to it since [date]. We'd like to discuss disposition — whether this continues under your team's ownership, transfers to another team, or is retired."

That framing does not require establishing who is historically at fault. It presents observable facts and opens a conversation about what happens next.

One critical distinction: access patterns establish dependency, not ownership. If your network layer records show a team hitting an asset consistently, that tells you there is a process that team uses which involves the asset. It may help you locate the right contact, but it does not establish that the team owns the asset. Confusing dependency with ownership is a common error — and one that points back to the higher-order problem that related assets in the same class may be handled inconsistently across the organisation.

Ownership evidence table

No single evidence type closes the case. Pairing two corroborating sources from different provenance — billing records and provisioning records, for example — substantially narrows the space for credible dispute. Access logs are useful for finding a conversation partner, but should be presented as "your team has a dependency on this asset" rather than "your team owns this asset."

NIST SP 800-128 frames the component inventory as a configuration management artifact that requires updating whenever components are added, modified, or removed — which means each of the evidence types above is also a data source that should already exist in a well-governed environment (Source: NIST SP 800-128 (updated 2019), https://csrc.nist.gov/pubs/sp/800/128/upd1/final). If your environment lacks these records, the evidence gap is the root cause, not just an inconvenience.

Asking for the right thing the first time

A vague "do you own this?" message produces a vague "I don't think so" reply. A more effective first contact presents the specific data linking the candidate contact to the asset, states what the ask is — confirm ownership and discuss disposition, dispute with alternative evidence, or escalate to their manager — and sets a response window proportional to the asset's exposure severity.

The response window should reflect your programme's policy. What drives the interval: how exposed the asset is, whether it carries authentication endpoints or sensitive data, and what escalation authority your programme holds.

Rather than "is this yours," send: "DNS registration for subdomain X was provisioned under your cost centre. Certificate issuance on [date] went through your team's service account. IAM access logs show activity from identities in your group in the past 14 days, suggesting your team has a dependency on this asset. We'd like to understand whether this should remain under your team's management, transfer to another team, or be retired. Please respond by [date] or let us know if there is a better contact."

That framing focuses on disposition rather than blame, and shifts the burden correctly — the candidate contact must engage with the data, not simply assert ignorance.

The dispute that is actually correct

Some disputes are legitimate, and dismissing them creates a worse problem than the one being solved.

A cost centre that was reorganised, a service account that was migrated to a different team, or a repository that was forked with the original team no longer maintaining it — these are genuine reasons why the evidence chain points at the wrong person. Accepting a false positive here means the actual accountable team is never engaged, the asset stays unacknowledged, and the wrongly targeted team loses trust in the programme.

The test: does the counter-evidence point to a specific alternative contact or team, or does it just create a void? "That cost centre moved to the platform team under [name] in Q3" is actionable. "We don't own that anymore" with nothing attached is not.

When a dispute is substantive, re-run the evidence chain against the named alternative. If confirmed, update your ownership record and routing rules so the same misfire does not repeat. The same class of asset may be misrouted elsewhere in your inventory — routing corrections are worth treating as a programme maintenance task.

When the asset predates everyone available

If the asset was provisioned before anyone currently in the org had their role, and billing, DNS, cert, and access records all lead to defunct teams or departed individuals, ownership must be assigned rather than discovered. The absence of a living historical claimant is not a reason to leave the asset unowned.

This situation is also the clearest case for the blameless posture: what existed before is not the question. The question is which function or team is responsible for this class of asset going forward, and how the asset will be dispositioned — continued, transferred, or retired.

The CIS Critical Security Controls are instructive here, though not in the way the framing of "finding an owner" might suggest. Safeguard 1.1 requires that an owner be recorded as an inventory field. Safeguard 1.2 requires a weekly review process — and for assets that cannot be attributed or authorised, the prescribed response is removal from the network, denial of remote connection, or quarantine, not continued operation pending an ownership search. An asset that has been externally reachable with no accountable owner is, under CIS guidance, a candidate for removal, not indefinite persistence while ownership is debated. The ownership conversation is therefore also a disposition conversation: if no owner can be established within a defined window, the default action under sound governance is to remove or isolate the asset, not to leave it running (Source: CIS Critical Security Controls, https://www.cisecurity.org/controls/cis-controls-list).

For assets that predate current personnel: escalate to the function that owns the relevant infrastructure class — network, cloud, application — and document that escalation. That function either accepts provisional ownership pending investigation or nominates a delegate. The operational requirement is that the escalation produces a named accountable person and a disposition decision, not a ticket that expires in a queue.

What to do with a refusal

A refusal that survives the evidence review — the candidate contact has seen the data and still declines without providing counter-evidence pointing elsewhere — is no longer a routing problem. It is a governance problem.

At this stage, the asset remains externally reachable and unowned, which means it is unmanaged from a risk standpoint. The practical path: escalate to the candidate contact's management chain with the full evidence pack attached, document the refusal and the date, and flag the asset as ownership-disputed in your inventory with an explicit review date.

In environments where the ASM programme has delegated authority to force provisional ownership assignment, that authority can be exercised here — assigning the infrastructure owner of the hosting environment as provisional owner until the dispute resolves. Where no owner can be established within the programme's defined window, the CIS framework supports removal or isolation as the appropriate default.

What you do not do: accept the refusal, close the ticket, and move on. That converts a governance dispute into an untracked exposure. Routing what happens next to control teams belongs to ASM-REDUCE-002; judging the weakness that the asset represents belongs to VEM.

The evidence pack test

Before any ownership contact, run this check:

An ownership claim that cannot pass this test before first contact will produce predictable results: a non-committal reply, a stalled ticket, and an asset that remains unowned. The pack exists to make the conversation productive on first contact by grounding it in data and in a clear question about what happens next.

Running this checklist against your five most recently discovered unowned assets is a reasonable way to identify which steps in your current process are consistently weak. If the same item is missing across multiple cases, that is where the programme needs a structural fix — and if that structural fix keeps pointing back to the same lifecycle gap, the real work is upstream, in provisioning controls and change management, not in the ownership conversation itself.

Sources