Measure unowned vulnerabilities by counting findings, and assets, with no valid owning team, and by tracking how long they stay that way. Define ownership as a named team that can change the code or system, reported as its own metric, because unowned items age quietly and distort team level numbers.
What ownership means
An owner is the team with authority and ability to change the affected asset. It is not the person who found the issue and it is not the security team by default. A finding is unowned if the owner field is empty, points to a departed person, points to a team that no longer exists, or names a mailing list nobody reads.
Why it matters for metrics
Team dashboards only count what is assigned to them. Unowned items belong to nobody's chart, so every team can look healthy while a pile grows in the gaps. Totals computed company wide will not reveal this unless you break out the unowned group.
Sources of ownership data
- Code ownership files in repositories, which map paths to teams.
- Service catalogs or internal registries.
- Cloud tags and project metadata.
- Build and deployment configuration that names a responsible group.
- Organisation charts, as a last resort, since they change often.
Prefer sources that are updated as part of normal work, because separate spreadsheets decay.
Metrics to track
| Metric | Why |
|---|---|
| Share of assets with a valid owner | Inventory quality |
| Count of open findings with no owner | Size of the gap |
| Median age of unowned findings | Whether anyone looks at them |
| Findings reassigned more than once | Ownership ambiguity |
Define valid owner precisely and check it automatically: the team exists in the directory, has members, and has an escalation contact.
Routing process
- Run a weekly report of unowned findings.
- Try the automatic sources in order.
- If none work, assign to a triage group whose job is to find the owner within a stated time.
- If no owner is found, escalate to the manager of the nearest related area, who must either claim or decommission it.
- Record the outcome.
Decommissioning is a real option. Abandoned services with open findings are often best fixed by turning them off.
Audit step
Sample ten assets from the unowned bucket. For each, work out the true owner by hand and write down how long it took and which source finally answered. That exercise shows which ownership data source to invest in.
Report it
Put the unowned count at the top of the team comparison view, as a row named Unassigned, not hidden in an Other category. Readers should see it every time.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Asset discovery and the code to asset mapping help attach findings to a responsible repository. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is the security team the default owner?
No. The owner is the team that can change the affected asset. Security can triage and escalate.
What if the owner left the company?
Treat the finding as unowned, reassign through the routing process and update the source of ownership data.
Last reviewed: 19 October 2026.
