Tracking stale cloud resource ownership across team transitions

Infrastructure ownership frequently becomes orphaned when team members move internally or depart, yet these changes receive far less attention than formal offboarding processes. The gap exists because updating resource tags and role assignments falls between departments—HR handles the title change, IT manages badge access, but nobody systematically updates who owns what in the cloud. This article outlines a three-part strategy to catch ownership drift as it happens rather than discovering it months later during a security audit.

Consider Marcus, who spent two years in platform engineering before promotion to a data platform role. His title and badge access were updated, but forty-one environments still carried the tag owner: marcus.reyes@company.com. Eight months later, an approval request for one of those environments landed in his queue. He approved it despite having no involvement with the project for nearly a year, because reviewing and rejecting would have consumed more time than clicking Approve. This scenario reflects not negligence but systemic inattention to infrastructure ownership during role transitions.

The solution requires no organizational restructuring. A query to identify inactive owners, a policy to enforce ownership assignments, and one additional step in existing team transition processes can prevent ownership from drifting into the background.

1 – The query that flags an owner who's gone quiet

Keeping owner tags current starts by mapping email addresses to IAM usernames, then cross-referencing owner tags against credential activity logs. For AWS, this means joining owner tags to the aws_iam_user_last_accessed_details table to surface credentials showing no recent activity:

SELECT r.resource_id, r.owner, MAX(la.last_authenticated) AS owner_last_active
FROM (
  SELECT resource_id, tags ->> 'owner' AS owner
  FROM aws_ec2_instances
  WHERE tags ->> 'owner' IS NOT NULL
) r
JOIN aws_iam_user_last_accessed_details la
  ON la.user_name = split_part(r.owner, '@', 1)
GROUP BY r.resource_id, r.owner
HAVING MAX(la.last_authenticated) < now() - interval '90 days'
ORDER BY owner_last_active;

Entra ID maintains similar audit records under a different structure. Since userPrincipalName already matches the credential directly, the join between VM owner tags and sign-in logs requires no additional parsing:

SELECT r.resource_id, r.owner, MAX(s.created_date_time) AS owner_last_active
FROM (
  SELECT resource_id, tags ->> 'owner' AS owner
  FROM azure_compute_virtual_machines
  WHERE tags ->> 'owner' IS NOT NULL
) r
JOIN entraid_auditlogs_signins s
  ON s.user_principal_name = r.owner
GROUP BY r.resource_id, r.owner
HAVING MAX(s.created_date_time) < now() - interval '90 days'
ORDER BY owner_last_active;

GCP presents a different challenge. Its IAM layer does not maintain records of when credentials last accessed resources. The nearest equivalent signal comes from the directory that issued the identity—typically Google Workspace login records for the person behind the label:

SELECT r.resource_id, r.owner, MAX(w.last_login_time) AS owner_last_active
FROM (
  SELECT resource_id, labels ->> 'owner' AS owner
  FROM gcp_compute_instances
  WHERE labels ->> 'owner' IS NOT NULL
) r
JOIN googleworkspace_users w
  ON w.primary_email = r.owner
GROUP BY r.resource_id, r.owner
HAVING MAX(w.last_login_time) < now() - interval '90 days'
ORDER BY owner_last_active;

Ninety days of silence from someone responsible for a resource isn't definitive proof they moved, but it's the kind of sign worth fifteen minutes of someone's time instead of eight months of nobody's.

2 – The policy that prevents orphaned environments

Queries identify what has already become stale. To prevent the next handoff from slipping through, ownership must live in the actual role-based access system governing the resource—a cloud IAM binding, a Kubernetes RoleBinding, or a custom role in an infrastructure-as-code platform—rather than as a text label in a tags field. A policy engine can then enforce ownership as a real constraint:

package ownership

# METADATA
# title: require an active owner
# description: A resource can't lose its last assigned Owner without a replacement.
deny[format(rego.metadata.rule())] {
    count(input.resource.roles.owner) == 0
}

format(meta) := meta.description

Implementation varies by platform. A custom Terraform pipeline requires an OPA server integrated into the CI job, storage for role bindings the policy reads, and ongoing synchronization as the organization changes. Platforms like env zero handle this differently: Custom Roles already cascade through org, project, and environment levels, so the policy evaluates against role assignments the platform already tracks on its existing drift-check schedule. Wherever the policy runs, removing someone's Owner role during offboarding or transfer without assigning a replacement fails immediately rather than waiting for someone to notice months later.

3 – The step every transfer checklist is missing

Most teams maintain some process for moving someone off a project—an offboarding checklist, a Slack message to IT, or similar. Few ask what that person still owns. Before revoking access, run the query from Section 1 against their name and send the results to their manager or team lead for reassignment. Complete the reassignment before access revocation. Deferring this step leaves ownership in limbo, hoping someone will eventually notice.

Reassign first, then revoke. Don't leave it for someone to hopefully notice later.

Why this keeps happening

Departures dominate attention because they feel final and trigger formal processes. Internal moves receive far less scrutiny despite being more frequent: nearly a third of roles were filled internally in 2024, up from the prior year. No offboarding checklist activates because nobody left the company, yet someone is no longer the appropriate owner even if they retain technical access.

This mirrors a related problem from earlier coverage focused on discovery: ensuring every resource has an owner initially. This piece addresses what happens when owners change roles, which occurs more often than departures.

Org charts will keep changing. Ownership needs to keep up.

These practices will not reduce the frequency of reorganizations. Internal moves typically represent positive career development. What must change is whether ownership updates follow team reassignments instead of remaining attached to an outdated role for the next year. A resource does not care about its previous owner; it needs to know who owns it now.