Skip to main content
Tech debt without an owner never gets fixed. It accumulates, compounds, and becomes someone else’s problem. Draftt resolves ownership for every resource in your inventory using signals from your cloud infrastructure, source control, and internal developer portals.

​
Why Ownership Matters

An unfixed piece of tech debt costs more with every passing day:
  • Velocity tax: Engineers spend time working around the debt instead of building features
  • Knowledge silos: Only original authors understand the implementation, blocking the team
  • Compound risk: Security debt becomes a breach vector; infrastructure debt becomes an outage
  • Scaling blocker: Adding new team members doesn’t improve throughput because they get stuck on tech debt
Ownership makes remediation possible because someone is explicitly responsible, understands the context, and can make decisions without waiting for other teams.

​
How Draftt Resolves Ownership

Draftt uses multiple signals to determine who owns a resource, checked in order of confidence.

​
Cloud Resource Tags

Ownership tags on the resource itself are the most direct signal. If a resource is tagged with ownership metadata in your cloud provider, that takes priority. Tag keys recognized: owner, owner-team, service, application, cost-center, maintained-by Best practice: Use standardized tag naming across your cloud accounts. Consistency matters more than convention.

​
CMDB

If you connect ServiceNow CMDB, Draftt reads CI records to resolve ownership from your existing CMDB data. This is particularly valuable for organizations where CMDB is the authoritative source of infrastructure ownership. See ServiceNow CMDB for setup.

​
Internal Developer Portal

If you connect Port, Draftt reads service catalog data to resolve ownership. IDP catalog entries represent deliberate ownership declarations and are a high-confidence signal. See Internal Developer Portal for setup.

​
Fallback: Orphaned

If no owner is found through any signal, the resource is flagged as orphaned. Orphaned resources are high-risk: they often harbor security debt, infrastructure debt, and cost waste because no one is accountable for them.

​
Orphaned Resources

An orphaned resource is one where Draftt cannot determine ownership through any method. Common causes:
  • Missing cloud tags
  • No matching entry in IDP catalog
  • No CODEOWNERS coverage
  • Team that created the resource no longer exists
Remediation: Assign an explicit owner through cloud tagging or IDP catalog entry. Alternatively, if the resource is no longer needed, decommission it.

​
Where Ownership Appears

Once resolved, ownership data is available across the platform: Inventory - Every resource shows its resolved owner and team. Filter by owner to see all resources belonging to a team. Policies - Policy status breakdowns can be viewed per-team to understand which teams have the most governance violations. Integrations - When Draftt pushes findings to Jira, Slack, or other tools, ownership context is included so findings reach the right people.

​
Best Practices

Create a standard that all cloud resources must have owner tags from day one. Enforce this through your IaC templates.
// Terraform example
resource "aws_instance" "app_server" {
  tags = {
    Owner     = var.owner_email
    OwnerTeam = var.owner_team
    Service   = var.service_name
  }
}
If you use ServiceNow CMDB or Port, connect them to Draftt. These sources represent deliberate ownership declarations and are the most reliable signals for organizations with mature service catalogs.
Make orphan resolution a recurring task. Resources without owners should be assigned or decommissioned.

​
What’s Next