Technical debt measurement has a mature set of tools: static analysis tools that score code quality, test coverage metrics, dependency age reports, and SonarQube dashboards that aggregate everything into a single score. These tools are useful. They are also insufficient for regulated systems, because they measure debt that slows development — and not debt that causes audit failures. A system can score A on every standard technical debt metric and still be carrying compliance debt that will generate findings the first time a regulator examines it.
What Compliance Debt Is
Compliance debt is the subset of technical debt that creates regulatory risk. It includes: audit log implementations that technically record events but in formats not queryable in the way regulators expect, access control implementations that functionally restrict access but lack the documented authorisation basis that regulators require, encryption implementations that use approved algorithms but with key management procedures not documented in the System Security Plan, and backup procedures that technically create copies but have never been tested. None of these problems will appear in a SonarQube report. All of them will appear in an OCR audit, a FedRAMP continuous monitoring review, or a PCAOB examination.
The distinction between compliance debt and standard technical debt is the consequence of non-repayment. Standard technical debt slows development velocity. Compliance debt creates regulatory risk that can materialise as enforcement action, audit failure, or breach notification obligations. In regulated systems, the compliance debt register is as important as the standard technical debt register — and in some organisations, more important.
The 3-5x cost differential between finding compliance debt during development and finding it at audit reflects the reality that remediation at audit requires: stopping development to fix the gap, re-documenting affected systems, engaging external auditors to validate the remediation, and potentially notifying regulators of the gap. Retrofitting an audit log format that satisfies OCR examination requirements into a production system that has been running for two years is a substantially larger engineering effort than building it correctly in the first sprint.
The Compliance Debt Metric
A practical compliance debt metric has three components: the count of open compliance debt items, the risk-weighted severity of those items (items that will cause audit failure weighted more heavily than items that create risk but are unlikely to be examined in the current audit cycle), and the age of each item (compliance debt unaddressed for more than one audit cycle represents a systematic failure, not a development backlog item). The metric should be reported to the board and executive team on the same cadence as financial risk metrics — in regulated industries, compliance debt is financial risk.
Populating the compliance debt register requires a control-based review: take each applicable control from the relevant framework (NIST 800-53, HIPAA Technical Safeguards, PCI DSS requirements), map it to the specific system implementation, and assess whether the implementation satisfies the control as an auditor would evaluate it — not as a developer would evaluate it. The gap between "this technically works" and "this would satisfy an auditor" is where compliance debt lives.
Prioritisation
Compliance debt prioritisation differs from standard debt prioritisation. Standard debt is prioritised by development impact — fix the things that most slow the team. Compliance debt must be prioritised by regulatory exposure — fix the things that will cause the most severe audit findings first. Regulatory exposure is a function of: the likelihood of examination, the severity of the finding if the gap is identified, and the effort required to remediate. High-exposure, low-effort items should be addressed immediately.
- Create a compliance debt register separate from the standard technical debt backlog — they have different owners, different prioritisation criteria, and different reporting paths
- Populate the register through control-based review, not static analysis — the gaps are in implementation quality, not code quality metrics
- Weight items by regulatory exposure (likelihood of examination multiplied by severity if found), not by development impact
- Report compliance debt to the board on the same cadence as financial risk metrics — in regulated industries, it is financial risk
- Track debt age: items unaddressed across multiple audit cycles represent systematic process failures requiring management intervention
- Run a compliance debt review sprint before each audit cycle — this is standard practice in mature regulated-industry engineering organisations
EU AI Act: What CTOs Actually Need to Do Before August 2026
The Vendor Rescue Pattern: How to Recover a Failed Implementation in 12 Weeks
The LLM Hallucination Problem in Regulated Environments: What 'Acceptable Error Rate' Actually Means
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.