Skip to content
AuditFront
CQ-4 Tech Due Diligence

Tech Due Diligence CQ-4: Technical Debt Management

What This Control Requires

The assessor evaluates how the organisation identifies, tracks, prioritises, and addresses technical debt, including the current level of accumulated debt and its impact on development velocity and system reliability.

In Plain Language

Every codebase has technical debt. That is not the issue. The issue is whether the team knows about it, tracks it, and actively works to reduce it. Unmanaged technical debt is a hidden liability that can significantly erode the value of a technology asset, because it means future investment will be needed just to maintain the current state before any new features can be built.

Assessors look for evidence of debt awareness. Does the team maintain a backlog of known debt items? Is there a classification system for severity? Is engineering time regularly allocated to debt reduction - typically 15-20% of sprint capacity? Are there metrics tracking debt levels over time? Teams that openly discuss and manage their debt demonstrate genuine engineering maturity.

The impact of accumulated debt shows up as slower feature development, higher defect rates in heavily indebted areas, difficulty onboarding new developers who must navigate poorly structured code, increased operational incidents from fragile systems, and higher costs for any future change. Investors and acquirers treat high, unmanaged technical debt as a direct valuation risk.

How to Implement

Create a technical debt register cataloguing known debt items. For each item, document a description, its location in the codebase, how it originated (deliberate shortcut, outdated technology, accumulated entropy), its impact on velocity or reliability, estimated effort to fix, and priority based on impact versus effort.

Classify debt by type and severity. Common categories include architecture debt (design decisions limiting scalability or flexibility), code debt (poorly written code that is hard to maintain), test debt (insufficient coverage in critical areas), dependency debt (outdated libraries or frameworks), documentation debt (undocumented systems or processes), and infrastructure debt (manual processes, outdated tooling).

Allocate dedicated engineering time for debt reduction. The industry standard is 15-20% of sprint capacity. Some teams run dedicated tech debt sprints periodically, while others embed debt reduction into every sprint. The key is that it is a planned, tracked activity - not something that only happens when nothing else is urgent (which is never).

Use static analysis tools to automatically detect and track code-level debt. Tools like SonarQube provide technical debt metrics including estimated remediation time and debt ratio, plus trend tracking over time. Configure quality gates that prevent new code from introducing debt above acceptable thresholds.

Track debt metrics over time: total estimated remediation effort, debt ratio (debt vs. clean code), new debt introduced per sprint vs. debt remediated, and trend lines showing direction. Report these metrics to leadership to justify ongoing investment in debt reduction.

Make technical debt visible to non-technical stakeholders by translating it into business terms. Frame it as impact on feature delivery speed, risk of production incidents, and cost of future development. This helps ensure debt management gets appropriate priority in resource allocation.

Evidence Your Auditor Will Request

  • Technical debt register or backlog with categorised items
  • Sprint or team allocation records showing dedicated debt reduction time
  • Static analysis reports showing debt metrics and trends
  • Debt reduction metrics over the past 6-12 months
  • Leadership reporting on technical debt status and remediation plans

Common Mistakes

  • No awareness of or tracking for technical debt; team does not discuss it
  • Debt acknowledged but never prioritised for remediation; backlog grows indefinitely
  • All engineering time consumed by new features; zero allocation for debt reduction
  • Debt reduction happens only during 'quiet periods' that never materialise
  • Static analysis warnings accumulate without action, normalising poor code quality

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.8.25 Related

Frequently Asked Questions

How much technical debt is acceptable?
Some debt is inevitable and can even be strategic - deliberate shortcuts to hit a market window are a valid trade-off. The key questions are: is the debt tracked and understood, is the trend stable or improving rather than growing, is critical debt affecting security or reliability being addressed, and is the debt level sustainable for the team's velocity? A SonarQube debt ratio under 5% is generally considered healthy.
Should we try to eliminate all technical debt before a due diligence?
Absolutely not, and attempting it would be unrealistic. Assessors expect to find debt in every codebase. What they want to see is awareness, a systematic management approach, and evidence of ongoing reduction. A team that openly discusses its debt and has a credible plan is viewed far more favourably than one that claims to have none - because no debt is simply not believable.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment