Look at any list of security problems that took months to fix and the common factor is rarely difficulty. It is that nobody could say whose job it was.
The DNS record pointing at a dead vendor. The service account with permissions nobody can justify. The repository that fails every scan. The cloud project billing four hundred pounds a month for something nobody recognises. Each one has a technical fix that takes an afternoon, and each one sits for a year because the first step is finding an owner and that step has no owner either.
This post is how to assign ownership so it stays accurate. For whoever keeps finding things nobody claims.
Why ownership decays
People leave and their things do not. The owner field says a name, the name left in 2024, and nothing updated.
Teams reorganise faster than metadata. The team that built it was dissolved and its work split three ways. Every asset still says the old team.
Creation is easy and attribution is optional. Anyone can create a repository, a bucket, a DNS record or a service account. Almost nothing requires saying who will look after it, because requiring that would slow down the creation, which is the thing everyone is optimising.
The obvious rule fails. "The team that created it owns it" is correct until the creator was a contractor, or an intern, or someone doing a favour for another team, which is precisely the population that produces orphans.
What an owner actually is
Be specific, because a vague owner is the same as none.
A team, not a person. People leave. Teams persist, and when they dissolve someone has to decide where their things go, which is a visible decision rather than a silent decay.
Someone who can act. An owner who cannot deploy a change, approve a spend, or make a decision about the asset is a contact, not an owner. The test is whether they can say yes to deleting it.
Someone who knows they own it. Ownership assigned in a spreadsheet nobody reads is fiction. If the owner would be surprised to hear it, the record is wrong.
One team. Two owners means neither acts. If two teams genuinely share, name one as accountable and the other as a stakeholder.
Make it a property of the thing, not a document
Ownership in a spreadsheet is stale within a quarter. Ownership attached to the asset survives, because it lives where people work.
- Repositories: a
CODEOWNERSfile, which also routes review, so it is maintained for reasons other than inventory. - Cloud resources: a mandatory
ownertag, enforced at creation by policy. A resource without one should fail to create. - Services: a field in your service catalogue, populated from the repository rather than typed.
- DNS: records in a repository as code, where the commit says who added it and why.
- Service accounts: an owner field in the account's own metadata, or a naming convention encoding the team.
The pattern: put the owner where a change to the asset naturally touches it, so updating it is part of doing the work rather than a separate chore.
Enforce at creation
Retrofitting ownership onto ten thousand existing resources is a project nobody finishes. Preventing the next orphan is a policy that takes an afternoon.
# reject resources without an owner tag
deny[msg] {
input.resource_changes[_].change.after.tags.owner == null
msg := "every resource must carry an owner tag naming a team"
}
Do this first, and the problem stops growing. Then work the backlog at whatever pace you can, knowing it is finite.
Finding the owner of something orphaned
When you have an asset nobody claims, in order of reliability:
- Git history. Who created it, who has touched it most recently. Names a person, which usually names a team.
- Billing and cost allocation. Somebody's budget is paying for it.
- Traffic and logs. Which services call it, and who owns those.
- Ask in a broad channel with a deadline. "We are disabling X on the 14th unless someone claims it." Effective, and the deadline is what makes it work.
- Turn it off and see. The last resort, and honest about what it is. Do it in a reversible way, announce it, and be ready to restore quickly.
Step four finds most of them, because the owner usually exists and simply does not know the asset is in question.
Keep it fresh
Re-confirm on a cycle, ideally attached to something people already do. An annual confirmation prompt during planning works better than a standalone audit, because it arrives in a context where people are already thinking about what their team is responsible for.
Break the process when it is wrong. An alert routed to a dissolved team should fail loudly rather than disappearing. Silent delivery to an empty group is how ownership rot stays invisible for years.
Handle team dissolution explicitly. Make reassignment of that team's assets part of the reorganisation, at the time. It is fifteen minutes then, and a six-month archaeology project later.
Track orphan count as a metric. Assets with no owner, or an owner that no longer exists. It is one number, it is easy to compute, and it is a better predictor of slow incident response than most things people measure.
The concession
There is a real objection: ownership metadata is a tax on creation, and teams under delivery pressure will enter whatever value passes validation. A required field produces a filled field, not a true one.
That is why enforcement at creation has to be paired with something that makes wrong ownership visible, which is routing. If alerts, review requests and access approvals all flow through the owner field, a wrong value produces immediate friction for the person who set it. A field used only for reporting will be wrong within a quarter, no matter how strictly it is required.
The implication
Most security backlogs are not a knowledge problem. The finding is understood and the fix is known. What is missing is a person who can say yes.
So ownership is not inventory hygiene, it is the prerequisite for everything else working. Make it a property of the asset, enforce it at creation, and route real work through it so that being wrong is noticed.
