Technical Debt Inventory and Attributes

Description — The one controlled type that best represents the central technical domain, ownership boundary, remediation focus, evidence, and closure criteria.

Benefit(s) — Routes the item to the appropriate owners, governance practices, evidence expectations, and remediation expertise while enabling comparable reporting by debt type.

Source — Manual.

Examples — Technology Debt

Notes — Valid values: Requirements Debt; Architecture Debt; Design Debt; Code Debt; Test Debt; Build Debt; Documentation Debt; Infrastructure Debt; Integration Debt; Configuration Debt; Versioning Debt; Technology Debt; Data Implementation Debt; Security-Related Technical Debt.

Description — Optional additional controlled types recorded only when other technical domains are materially involved.

Benefit(s) — Captures materially involved technical domains without weakening the single primary classification used for accountability and reporting.

Source — Manual.

Examples — Architecture Debt; Security-Related Technical Debt

Notes — Valid values: Use the same fourteen-type value set as Primary Technical Debt Type. Record only when another domain is materially involved.

Description — The principal reason or mechanism through which the condition arose, such as schedule pressure, funding constraint, incomplete Requirements, provider change, skill gap, lifecycle failure, or weak governance.

Benefit(s) — Supports prevention, systemic analysis, and selection of treatments that address the origin of the condition rather than only its symptoms.

Source — Manual.

Examples — Provider support ended after the original implementation.

Description — Whether the condition was intentionally created or retained, unintentional, inherited, emergent, or of unknown origin.

Benefit(s) — Distinguishes deliberate tradeoffs from accidental, inherited, or emergent conditions, improving accountability, review, and prevention decisions.

Source — Manual.

Examples — Emergent

Notes — Valid values: Intentional; Unintentional; Inherited; Emergent; Unknown.

Description — When or how the enterprise became aware of the condition, separately from why it arose or whether it was intentional.

Benefit(s) — Shows when and how the enterprise learned of the condition, supporting detection-effectiveness analysis, accountability, and process improvement.

Source — Manual.

Examples — Discovered Later

Notes — Valid values: Known at Creation; Discovered Later; Suspected; Hidden Until a Triggering Event; Unknown Origin.

Description — The controlled categories describing the item’s current or potential consequences.

Benefit(s) — Provides a consistent way to identify and aggregate the kinds of burden or exposure the item creates across Assets, portfolios, and the enterprise.

Source — Manual.

Examples — Security; Operational; Strategic; Changeability

Notes — Valid values: Financial; Delivery; Operational; Service; Security; Compliance; Resilience; Maintainability; Changeability; Scalability; Interoperability; Data; Knowledge; Strategic; Customer-Related.

Description — The degree of confidence in the current type, cause, Intent, Awareness, consequence, and scope classifications.

Benefit(s) — Signals how much reliance governance bodies should place on the current classification and where additional investigation or evidence is required.

Source — Manual.

Examples — High

Description — The governed value for tags associated with the Technical Debt Item.

Benefit(s) — Improves discovery and flexible grouping for local reporting or analysis without overloading governed classification fields.

Source — Manual.

Description — Whether the item is local to one bounded area, affects several Assets, or represents a systemic condition arising from a common cause.

Benefit(s) — Determines whether governance should remain local, span multiple Assets, or escalate to portfolio or enterprise treatment for a systemic condition.

Source — Manual.

Examples — Cross-Asset