Technical debt comes in three forms. Legacy equipment that can't meet today's needs, software projects where corners have been cut, and poorly implemented or completely ignored governance frameworks. The common thread? Risk.

Technical Debt

Technical debt is the deficit between the assumed performance of something and what it actually delivers. Because of the disparity, there is an unavoidable underperformance. Technical debt doesn't age well. As the disparity grows so your exposure to risk grows.

Technical debt can slowly accrue. Aging hardware and operating systems eventually slide backward out of their manufacturers' support cycles. The technical debt is the mounting security risk that you're exposing your organization to by running systems that don't receive security patches.

Sometimes you can inherit technical debt through a merger or an acquisition. You can also manufacturer technical debt, especially in software development projects. Design and implementation decisions---often forced on the development team due to budget constraints or unrealistic deadlines---can introduce technical debt that is baked into the application and exists, fully formed, at launch.

IT governance frameworks such as cybersecurity and data protection policies and procedures can accumulate technical debt, can be created with technical debt already embedded in them, or can suffer from both.

in all cases, the technical debt directly equates to risk. It is a sure indicator that attention needs to be applied to the problem.

IT Equipment and Technical Debt

All IT equipment must be maintained. Security patches must be applied to software and firmware, and operating systems must be upgraded as they become obsolete and unsupported. Hard drives need to be replaced at the end of their expected service life, or at the first warning signs of developing errors. If the hard drive in question is not part of a RAID array don't wait for warning signs. Act when the drive has fulfilled its projected duty cycle.

Eventually, all equipment and operating systems become obsolete. Running old, unsupported equipment is a security risk. Despite this, it can be a hard sell to the commercial side of the business to replace something that, to them, is still working just fine. And even when something is earmarked to be upgraded and replaced, technical debt persists until the replacement has actually taken place.

Sometimes, running expired operating systems or old hardware is beyond your immediate control. Laboratory and industrial control PCs are particularly prone to operating system lock-in. This can happen if a piece of crucial third-party software hasn't been updated since it was released. That can force you to run the operating system that was current when the product was launched. it may be a hardware-based issue. If the software only works with a particular, ancient interface board that's only compatible with a particular vintage of PC hardware you're stuck with the operating systems those POCs can support.

Completely replacing aged hardware and software isn't as easy as it sounds. It might control production or other mission-critical machinery or processes. You can't just dump the old stuff if what's available today doesn't integrate with your production systems.

The older the systems are, the more likely it is that the people who implemented them have left the company. There may be no deep knowledge of the aged systems in your support teams. Often, when these old systems are discovered to be more deeply interconnected and embedded than was previously understood.

Development Projects and Technical Debt

Non-trivial development projects have a lot of demands placed on them. Whether the application is for in-house consumption or is a product that will be marketed, the stress points are similar. Most of them revolve around deadlines, specifications, and budgets.

The specification is a list of functionality and content that the software must provide. The specification must be more than a lengthy wish list. The time available for development, testing, and documentation dictates what content can realistically be achieved with the development resource that you have available and the technologies that they are familiar with.

Too optimistic a specification or too short a development phase amounts to the same thing. The work doesn't fit into the time available. The impact this has on the development team is profound. If they find themselves under the gun, known techniques, methodologies, and technologies are going to be preferred over devoting time to appraising new platforms, frameworks, or whatever.

When you're on the death march to a deadline you don't have time to start experimenting with new technologies and potentially introducing risk. That risk may be functional issues within the software that impact the users or they may be insidious issues that give rise to security vulnerabilities.

Sometimes development comes under pressure from the commercial side of the business. They may stipulate a new technology is used to ensure your product stacks up against the competition. That means you're forced into trying to learn the new technology and still hit the deadline.

These types of self-inflicted wounds affect the architecture of the product and the code quality. You won't get the best out of a new framework, language, or even development paradigm until your developers are sufficiently familiar with it to understand its idioms and best practices. At the least, it's likely to produce code that performs poorly and is difficult to maintain. In the worst case, it can introduce security risks.

Third-party libraries and toolkits speed up development, but they may harbor security vulnerabilities and their own technical debt. Using third-party code simplifies development but can complicate matters for your security team.

The business and commercial sides of the organization need to be involved in early conversations with development so that a realistic but mutually satisfying product description and specification can be drafted, taking into account deadlines and technologies both current and cutting edge. Your security team needs to be engaged as well. And because your development team is never sat around doing nothing, there have to be provisions made for research. Otherwise, it won't happen.

Formally scheduling time and resources for research---including training---is the only way to ensure that essential research takes place. You might have to recruit to achieve this. without research, you'll never be able to move to new technologies in a controlled fashion. And without control, you're left with risk.

Governance and Technical Debt

Technical debt can creep into the creation of governance frameworks in a similar way that it does with software development. Instead of developing software, you're creating policies and procedures, such as IT governance or data protection systems. You wouldn't give a development project to a team that has never written code before. The same thing applies to governance documentation.

You can't expect great results if you give the task to someone who doesn't have the appropriate skillset. Writing good governance documents is difficult. Without that skillset, it's tempting to copy chunks out of other organizations' policies and procedures and try to edit them into a cohesive whole, but it doesn't work. The result is a patchwork quilt of bits of documents that were designed for other organizations.

Your governance authors must know and understand the legislation or standard that you're trying to satisfy or address, and be experienced in producing governance and policy documents. If that's not you, engage with someone who has those skills.

Another common failing is making governance documents impressive instead of making them factual. They need to be a true reflection of what you do and need to control, and how you're going to do it so that you satisfy the legislation or standard you're working with. It's impossible to pass an audit if the documents you're being audited against don't reflect your actual processes, workflows, and safeguards.

Having accurate and applicable governance documents achieves very little if they're not being used. Compliance complacency is when you have the policies and procedures, but no one uses them. They must be adopted and used by your workforce otherwise your procedures are not being conducted in accordance with your policies. That's bad enough, but it also means your processes won't generate an audit trail. Even worse, not following procedures can lead to security lapses and data breaches.

Maintaining a governance system requires time and resources too. You need to perform internal audits for example, and you must monitor the legislative landscape. Legislation changes over time, and is repealed and superseded. The business may choose to, or be compelled to, adhere to a standard that they've not been forced to comply with before. For example, you might start taking online payments and need to comply with the Payment Card Industry Data Security Standard (PCI-DSS). Your governance documentation will need to be amended to reflect the new demands and to ensure that all clauses of the standards are addressed.

Facing Your Debts

Technical debt never sleeps, and it gets worse the longer you leave it. What it takes to address the problem ranges from the easy to the very difficult. Establishing a patching policy and setting out a schedule is easy. Eradicating lock-in to legacy systems might require untenable upheaval and expenditure.

If you have technical debt that you cannot address---or that cannot be addressed until some other significant event takes place---make sure you have the risk captured and characterized in your operational risk assessment and cyber risk assessment documents. Record what steps have been taken to mitigate the risk, and what contingency steps you can should the risk occur.