Publication date: November 04, 2026
Technical debt, GDPR and NIS2 – how yesterday’s shortcuts turn into tomorrow’s liability
Technical debt is a phenomenon that sooner or later affects almost every IT project. It consists in choosing a solution that is quicker to deliver but inferior in technical quality. A team usually “takes out” this loan under pressure from the business side, for which the key metric is time-to-market – the sooner the product reaches the market, the better.
In the short term this brings a quick win, but in the future the company has to start paying the “interest”. It shows up as ever higher system maintenance costs, a slowdown in the pace of work, and the mounting frustration of developers who, instead of developing the product, must keep fixing the same defects over and over. Although the term “technical debt” appears nowhere in legislation, concepts such as due diligence and the adequacy of technical measures in practice force companies to keep that debt from spiralling out of control.
Technical debt is not homogeneous; it accumulates in many places. One of the biggest problems is legacy code – code built on technologies that are no longer maintained. It often degenerates into so-called spaghetti code: a structure so tangled that a change in one place causes an unexpected failure in an entirely different part of the system.
Another barrier is the absence of automated tests, which forces the team into manual testing – where mistakes are easiest to make. Closely related is code duplication, that is, solving the same problem repeatedly in different parts of the application. Nor should the lack of documentation be forgotten, which gives rise to so-called tribal knowledge. When key employees leave, the organisation is left with a system that no one can operate or develop efficiently.
Technical debt is not merely an IT department problem – it strikes directly at the stability of the company. Outdated architecture leads to outages and performance degradation, which can result in breaches of SLA commitments and financial penalties. The greatest nightmare, however, are regressions: situations in which new features break functionality that previously worked correctly.
The most serious risks, though, are those to security. Failure to update components (third-party dependencies) exposes the company to zero-day attacks and to vulnerabilities catalogued in public CVE databases. Hackers routinely scan the internet for systems running old libraries for which security patches are no longer issued. Ignoring this problem is the simplest way to become an easy target.
The law today requires companies to take a proactive approach to risk. Under the GDPR (Article 32), controllers must implement measures that take account of the current state of the art. Using outdated encryption methods, or libraries that no longer receive updates, may amount to a breach of these provisions.
Technical debt also strikes at the principle of accountability. If, because of the poor state of its code, a company is unable to give effect efficiently to, say, the “right to be forgotten”, the supervisory authority may treat this as gross negligence. In the event of a data breach, the existence of substantial technical debt will be an aggravating circumstance – and may drastically increase the amount of the fine.
New regulations – the NIS2 Directive and the amended Polish Act on the National Cybersecurity System (KSC) implementing it, in force since 3 April 2026 – place responsibility for these matters directly on senior management. NIS2 puts strong emphasis on supply chain security and vulnerability management. If a system is so fragile that installing a patch risks bringing it down, the management board is caught in a trap: the law requires vulnerabilities to be patched, while the technical condition of the system makes that impossible.
Such omissions carry not only financial penalties but even a ban on holding managerial positions. Standards such as ISO/IEC 27001, ASVS and the OWASP guidelines are becoming the points of reference – ignoring them is treated as knowingly accepting an excessive level of risk.
Managing technical debt does not mean halting all work; it means introducing healthy rules. Key among them is the boy scout rule – leave the code in a better state than you found it. It is also worth applying TDD (test-driven development), that is, writing tests before the code, which builds a “safety net”.
To combat vulnerabilities, SCA-class tools that automatically monitor external packages are indispensable. CI/CD pipelines with built-in static (SAST) and dynamic (DAST) analysis should be the standard. To stop knowledge leaking out of the company, it is worth adopting a docs-as-code model (documentation kept together with the code) and maintaining architecture decision records (ADRs). In this way it is possible to build a system that is not only modern but, above all, secure and legally compliant.