Technical Debt: A New(ish) Risk Management Lens
- bennym40
- Apr 21
- 6 min read
“Something breaks and then all that’s left is a story – like all stories – about how well people handle change.” Coda, Simon Spurrier & Matias Bergara
The views and opinions expressed on this account are my own and do not reflect the official policy or position of my employer. Any content provided is for informational purposes only and should not be considered or relied upon as professional advice.
Organisational Change and Risk go Hand-in-Hand
Change introduces risk to an organisation by disrupting how it operates. It can invalidate the assumptions that existing processes, systems, and controls rely on. Most risk and governance frameworks are designed for stable environments, so when strategy, regulation, technology, or markets change, previously effective controls may fail.
Change can also expose weaknesses that were previously hidden. For example, under-investment can lead to stretched teams and manual workarounds. These workarounds may function well in stable conditions, but struggle when faced with higher volumes of work, faster processes, or increased complexity.
While organisational shocks may trigger issues, it is the organisation’s internal vulnerabilities - its accumulated technical, process, and human debt - that determine how severe and long-lasting the impact will be.
Why Risk Frameworks Often Miss Under-Investment
Risk teams often focus on short-term performance, ensuring risks are currently managed within appetite and controls meet their existing success criteria. A strong bias towards assessing quarterly performance can reinforce this. However, this short-term view can overlook the long-term consequences of under-investment.
Even when it is clear that under-investment will ultimately lead to poor control performance, it is unlikely to be next quarter, and so control scores remain favourable until they break.
This can leave risk teams exposed when issues caused by under-investment crystallise, particularly during periods of change. To address this blind spot, organisations can adopt a new perspective: Technical Debt.
What is Technical Debt?
Technical Debt refers to the future cost of fixing or maintaining systems, processes or resources. Originally a software engineering term, it can be applied more broadly to assess under-investment in the wider business.
How Does Technical Debt Build Up?
Evolving Standards: As organisational standards evolve, and strategies, markets, technologies, or processes change, older systems may no longer meet current needs.
Deliberate Choices: Sometimes organisations take shortcuts to achieve immediate benefits, knowing they'll need to address the consequences later on.
New Regulations: For example, the introduction of Solvency II created a significant operational liability for UK insurers. As this liability moved on to firms' balance sheets it ended up costing the industry billions[i].
Shifting Strategies: Changes in market practices or business goals can create new obligations, such as the switch to online retail in the late 1990s.
The Impact of Technical Debt
Over time, unmanaged Technical Debt:
Makes systems harder to understand, operate, and change.
Increases cost and risk.
Reduces reliability and agility.
“Paying down” Technical Debt may involve improving documentation, modernising processes, or removing previously accepted shortcuts. The goal isn't to eliminate Technical Debt entirely, but to manage it consciously so it doesn't undermine long-term outcomes or introduce unacceptable levels of risk.
The House Analogy
Think of a poorly maintained house:
Shortcuts during construction, or deferred maintenance, may save time or money initially.
Over time, these small issues grow into major problems, increasing costs and efforts.
Eventually, the level of effort spent each year just to keep the house functional will exceed the initial maintenance cost.
Beyond a certain point, failure to invest in the house will make it unliveable.
Why Framing Under-Investment as Debt is Useful
Viewing under-investment as debt helps organisations make informed decisions. Like financial debt, Technical Debt:
Carries "interest", paid through increased effort or costs.
Can be a rational choice provided that costs and benefits can be identified and quantified.
Deferring "payment" may improve short-term results.
For example:
Smaller insurers delayed Solvency II investments to reduce medium-term costs. They benefited from waiting for clearer regulatory guidance and agreed market solutions.
Entrepreneurial firms often take on Technical Debt to experiment, innovate and move quickly. Once the new initiatives become part of the long-term operating model they can be more confident that investments in systems and processes can be justified.
The key to successfully utilising Technical Debt is identifying it and assessing its future cost. Failing to do so can lead organisations to overestimate profitability, underestimate management strain, and make poor long‑term decisions. Unmanaged or “runaway” Technical Debt eventually makes it difficult even to maintain the status quo, let alone support growth or change. In the insurance industry, legacy data platforms are a common example: costly to maintain, limited in functionality, riddled with key person dependencies, and a growing constraint on competitiveness.
In some situations, it may make sense to retain Technical Debt until it can be "written off", for example where:
A business line is being discontinued,
Remediation costs exceed benefits, or
A planned technological change will result in a process or system being retired.
Challenges in Identifying Technical Debt
Technical Debt is often invisible until systems or processes fail. It typically sits in less visible areas, such as documentation gaps, system and control limitations, or information gaps.
Common challenges include:
Lack of documentation.
Cultural undervaluation of under-invested areas.
Under-investment spread across multiple teams.
An over-confidence in the flexibility and scaleability in existing processes.
A disconnect between revenue and operational strategy.
When teams are stretched, they often focus on visible outputs and allow less visible, but often critical processes to deteriorate. This can make it harder to identify sources of Technical Debt.
Teams may be reluctant to highlight under-investment: they may see their role as doing the best with the resources they have.
Risk teams can often miss dangerous accumulations of Technical Debt:
Control frameworks tend to focus on tangible outputs of processes, and so fail to capture the deterioration in performance of underlying processes.
Definitions of control success tend to focus on immediate business needs.
"People" risk assessments tend to be conducted at an organisational, rather than function or process level.
Assessment of system and technology suitability is often outside the scope of standard risk assessments.
Challenges in Quantifying Technical Debt
Most organisations lack a consistent way to measure Technical Debt. As a result, it is often treated as a qualitative concern with limited influence on decisions.
It often involves uncomfortable conversations about spending money on work that delivers little immediate or visible benefit, with the opportunity cost being the greatest tangible risk. Short‑term incentives can also discourage firms from seeking to measure Technical Debt, particularly where performance improvements are driven by an unacknowledged increase in Technical Debt.
Ignoring Technical Debt can create systemic optimism in financial planning, masking the true cost of operations, and underestimating the ultimate cost of change initiatives. This dynamic is visible not only in firms, but also in national infrastructure, where chronic under‑investment has led to declining resilience and rising long‑term costs.
Organisations often acknowledge the creation of Technical Debt at the outset of a change project or strategic initiative (although they might not use those words). However, there often isn’t a formal framework, or recognised terminology, to record the requirement for future additional investment. The awareness of the size and nature of this Technical Debt can then be forgotten as new initiatives are undertaken, knowledgeable personnel disappear, and time passes.
How Risk Teams Can Help
Where these sources of Technical Debt introduce a material immediate risk to the business, risk teams are well placed to use their standard toolset to address them. However, where this debt has the potential to introduce an unacceptable risk at some unspecified future date, the standard toolset can fail.
Risk teams can play a crucial role in identifying and managing Technical Debt:
During Projects:
Participate in scoping and close meetings to identify deferred deliverables.
Track control development work in the wider organisation that has been deferred until after project completion.
Ongoing Monitoring:
Use Risk Reviews / Deep Dives to uncover under-invested areas.
Use root cause analysis to identify gaps in systems, processes, or resources.
Include consideration of resource, system, and technology adequacy at a function and process level in risk assessments.
Use Risk and control reviews to reveal warning signs such as outdated documentation, manual workarounds, overdue committee and audit actions, and poor Management Information.
Building a Technical Debt Log
Risk teams can maintain a dedicated log to help track and manage Technical Debt. This log can include:
Links to specific processes, teams, or risks,
Potential impacts of combining different sources of debt.
This log can be used to support:
Stress testing the operating model to assess resilience.
Identifying operational risks and performance issues before they materialise.
Challenging achievability of medium-term strategy.
Challenging operational investment prioritisation decisions.
Providing a more comprehensive view of direct and indirect Project risks.
Conclusion
Technical Debt is an inevitable part of organisational growth and change. However, by recognising and managing it proactively, organisations can reduce hidden liabilities, improve organisational flexibility, and make better long-term decisions.
I hope this blog sparks ideas and discussion. If you found it interesting, please share or connect with me on LinkedIn to contribute or provide feedback!
[i] PRA response to the Treasury Committee’s inquiry into Solvency II, February 2018, https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/report/response-to-treasury-committee-inquiry-into-solvency-2-august-2018.pdf

Comments