EU Regulation: Technical Debt With a Deadline
Last updated . Sources are named and dated inline - how we source claims.
Most technical debt has no due date, which is precisely why it never gets funded. European product regulation changes that. It takes the debt you already have and staples a named date to it.
An unsupported dependency becomes a support-period obligation. A missing bill of materials becomes a shipping blocker. Data your schema cannot delete becomes an erasure problem. An inaccessible interface becomes an overdue one. This page maps each instrument to the engineering work it implies.
Read This First: General Information, Not Legal Advice
This page exists so engineers and engineering leaders can have a useful conversation with their own legal and compliance functions. It is general information about what these instruments ask software teams to do. It is not legal advice, and it cannot tell you whether any of it applies to you.
Scope depends on company size, sector, product category, risk classification, and where you sell. A directive is transposed differently in each Member State, so the text that binds you is your national law, not the directive itself. Confirm applicability, dates, and interpretation with your own counsel before committing a roadmap to any of it. Every date here is cited to its primary source so your lawyers can check our work rather than take our word for it.
Why a Deadline Is the Best Debt Argument You Will Ever Get
Every argument for paying down technical debt hits the same wall. The work is real, the cost is real, and the benefit is diffuse, delayed, and impossible to attribute to a quarter. So it loses to the feature with a launch date, and it will keep losing, because a request without a deadline is competing against a request with one.
Regulation inverts that. It does not create new debt so much as convert the debt you already carry into work with a fixed expiry. The dependency you have not upgraded in four years does not get worse when a regulation lands; it becomes a dated obligation with a named article behind it and a penalty for getting it wrong. It is the rare debt argument that does not require anyone to believe your velocity estimate. It only requires them to read a calendar.
The risk runs the other way too. Teams that treat a compliance date as a documentation exercise discover late that the requirement underneath it is an engineering one. You cannot write your way to a five-year support commitment for a library abandoned three years ago, or produce a machine-readable dependency inventory for a build nobody can reproduce. The paperwork is downstream of the engineering, and the engineering is the part with the long lead time.
The Cyber Resilience Act: Dependency Debt With a Date
The Cyber Resilience Act is Regulation (EU) 2024/2847, published in the Official Journal on 20 November 2024 and in force since 10 December 2024 under Article 71(1). It is the most consequential instrument here for anyone shipping software, because it applies horizontally to "products with digital elements" rather than to a single sector.
Article 71(2) sets general application from 11 December 2027, with Chapter IV (Articles 35 to 51, on notifying authorities and notified bodies) from 11 June 2026 and Article 14 reporting from 11 September 2026. That reporting date is the one to put in front of leadership: it is the earliest point at which a manufacturer carries an active, clock-driven duty, and it lands well before the date most roadmaps are aimed at.
Source: Official Journal of the European Union, Regulation (EU) 2024/2847, Article 71
Your Bill of Materials Becomes a Shipping Requirement
Annex I, Part II, point (1) requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products". Note the floor: top-level dependencies are the minimum, not the target. Anyone who lived through Log4Shell knows the dependency that hurts you is usually transitive.
The debt it exposes: unreproducible builds, vendored code with no provenance, build steps that download from a URL nobody owns. An SBOM is trivial to generate from a build you control and impossible to generate honestly from one you do not. The work: make the build reproducible first, then emit the SBOM as a build artifact rather than a document, stored per release. See our security and supply chain guide for formats and tooling, and dependency management for the inventory problem underneath it.
The Support Period Turns End-of-Life Into a Promise
Article 13(8) sets the support period during which vulnerabilities must be handled. Its third subparagraph states that "the support period shall be at least five years", except where the product is expected to be in use for less time, in which case the period matches that expected use. Article 13(9) requires each security update to remain available for a minimum of ten years or the remainder of the support period, whichever is longer.
The debt it exposes: this clause turns unsupported dependencies from an engineering preference into a commitment you must be able to keep. You cannot promise five years of vulnerability handling on a framework whose maintainers stopped shipping patches, or a runtime that reaches end-of-life inside your own support window. The work: build an end-of-life calendar for every runtime, framework, and major library you ship, and compare it against the support period you are committing to per product. Where the dependency expires first you have three options, all budget items with lead times in quarters: upgrade, replace, or maintain it yourself.
Reporting Turns Your Incident Process Into a Stopwatch
Article 14(1) requires a manufacturer to notify any actively exploited vulnerability in its product simultaneously to the designated coordinator CSIRT and to ENISA. The timings sit in Article 14(2): an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. That last clock is widely misquoted, so state it precisely: the 14 days run from availability of the fix, not from awareness of the flaw. A separate track in Article 14(3) and 14(4) covers severe incidents, where the final report is due within one month.
The debt it exposes: detection and ownership gaps. A 24-hour clock starting when you become aware assumes you have a mechanism for becoming aware and a named owner who receives it. Most organisations discover on the day that their vulnerability intake is an unmonitored inbox. The work: a monitored disclosure channel, an on-call rotation covering it, and an SBOM you can query fast enough to answer "are we affected" inside the first day. This is the capability our observability debt material argues for, with a legal deadline bolted on.
NIS2: Unpatched Dependencies Become a Board Problem
Directive (EU) 2022/2555 binds you through national law rather than directly. Article 41 required Member States to adopt and publish transposing measures by 17 October 2024 and to apply them from 18 October 2024. Transposition has been uneven, so the practical question is what your own Member State enacted, and when.
Article 21(1) requires essential and important entities to take appropriate and proportionate measures to manage cybersecurity risk, and Article 21(2) lists the minimum set. Two items in it are pure technical debt. Point (d) covers supply chain security, including the security of relationships with direct suppliers and service providers. Point (e) covers "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure". Maintenance is named in the statute. Not modernisation, not innovation. Maintenance.
Source: Official Journal of the European Union, Directive (EU) 2022/2555, Articles 20, 21, 23 and 41
The Liability Clause Is the Part That Changes Conversations
Article 20(1) requires Member States to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation, and "can be held liable for infringements by the entities of that Article". The reference is specifically to Article 21. Article 20(2) additionally requires members of those bodies to undergo training.
This is why NIS2 belongs on a technical debt site and not only on a security one: it relocates the argument. An unpatched dependency stops being something engineering keeps asking for time to fix and becomes something a director has personally approved a position on, having been trained well enough to understand it. Very few debt arguments come with that leverage attached.
Incident reporting under Article 23(4) follows a familiar shape: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report no later than one month after that 72-hour notification. As with the Cyber Resilience Act, the final-report clock runs from the notification rather than from the incident.
The penalty structure is drafted differently from the others here and repays careful reading. Articles 34(4) and 34(5) require Member States to provide for maximum fines of "at least" a stated figure. That is a floor on the national ceiling, not an EU-wide cap, so a Member State may set higher maxima. Both paragraphs are scoped to infringements of Article 21 or Article 23.
The AI Act: Model and Eval Debt on a Staggered Clock
The AI Act is Regulation (EU) 2024/1689, published on 12 July 2024 and in force since 1 August 2024. Its application is staggered across several years rather than switching on at once, and the staggering has since been amended, so this is where imprecision does the most damage.
As originally enacted, Article 113 set general application from 2 August 2026, with Chapters I and II (including the prohibited-practices rules) from 2 February 2025; Chapter III Section 4, Chapter V, Chapter VII, Chapter XII and Article 78 from 2 August 2025 with the exception of Article 101; and Article 6(1) with its corresponding obligations from 2 August 2027.
The High-Risk Dates Have Moved
Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026 and published in the Official Journal on 24 July 2026, entering into force on the third day following publication under its Article 4. It replaces point (c) of the third paragraph of Article 113 so that Chapter III, Sections 1, 2 and 3, with the exception of Article 6(5), apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I.
Two things are commonly reported wrong, and both matter for planning. First, the two categories moved to different dates: Annex III and Annex I systems are no longer on the same clock. Second, the general application date was not touched. The second paragraph of Article 113 still reads 2 August 2026, so everything outside Chapter III Sections 1 to 3 is unaffected. This is not a blanket delay of the AI Act, and treating it as one will put your roadmap in the wrong place.
Source: Official Journal of the European Union, Regulation (EU) 2026/1744, Article 1(40) and Article 4
Which route applies decides which date applies. Article 6(1) covers AI systems that are, or are safety components of, products already covered by the Union harmonisation legislation listed in Annex I and requiring third-party conformity assessment. Article 6(2) provides that systems referred to in Annex III are also high-risk, subject to the derogation in Article 6(3) for systems posing no significant risk of harm.
The debt it exposes: the high-risk obligations are, in engineering terms, a demand for evidence about a system you probably cannot currently describe. Training data provenance, logging, human oversight, accuracy claims, and technical documentation all assume you know which model version served which decision, on what data, with what evaluation behind it. Teams that shipped models through notebooks and manual deploys do not have that lineage, and reconstructing it later is far harder than instrumenting it now. The work: model and dataset versioning tied to deployments, evaluations that run on a schedule rather than at launch, retained logs that can reconstruct a decision, and a written record of intended and prohibited use. That is the backlog in our AI product debt guide, with dates attached to some of it.
The European Accessibility Act: Inaccessible Interfaces Are Already Overdue
Directive (EU) 2019/882 on the accessibility requirements for products and services is the one instrument here whose deadline has already passed. Article 31(1) required Member States to adopt and publish transposing measures by 28 June 2022, and Article 31(2) required them to apply those measures from 28 June 2025. If you came looking for a future deadline to plan around, this is not one. It is a live obligation.
The transitional periods are narrower than teams tend to hope. Article 32(1) provides a transitional period ending 28 June 2030 during which service providers may continue providing services using products they were lawfully using before that date. Article 32(2) allows self-service terminals lawfully in use to continue until the end of their economically useful life, capped at 20 years from entry into use. Neither is a general extension for a web application you are still actively building.
Source: Official Journal of the European Union, Directive (EU) 2019/882, Articles 15, 31 and 32
The Directive Never Names WCAG
This surprises people, so be exact about it. The words WCAG and EN 301 549 appear nowhere in the directive. Annex I states functional accessibility requirements in outcome terms, such as making information available through more than one sensory channel. The route to a specific standard runs through Article 15, under which products and services conforming to harmonised standards whose references have been published in the Official Journal are presumed to conform, so far as those standards cover the requirements. That is how EN 301 549, and through it WCAG, becomes the practical yardstick. But the directive is standard-agnostic on its face, and anyone telling you it mandates a particular WCAG version is paraphrasing, not quoting.
The debt it exposes: the most familiar item on this page and the most often deferred, because it is invisible to the people approving the roadmap. Missing form labels, custom components that cannot be operated by keyboard, contrast failures, focus traps, dynamic content screen readers never announce. None of it fails a functional test; all of it fails a user. The work: automated accessibility checks in CI, a component library where accessible behaviour is built into the component rather than reapplied per page, and manual testing with real assistive technology on the flows that matter. Our UX and design debt guide covers remediation and the WCAG 2.2 criteria in detail.
GDPR: The Data Your Schema Cannot Delete
Regulation (EU) 2016/679 has applied since 25 May 2018, so it is not news. It earns its place here as the clearest example of a regulation whose real cost is schema debt. Article 5(1)(e), the storage limitation principle, requires personal data to be kept in a form permitting identification for no longer than is necessary. Article 17(1) gives data subjects the right to obtain erasure without undue delay on any of six grounds, and Article 17(2) adds that a controller who has made the data public must take reasonable steps to inform other controllers processing it.
Source: Official Journal of the European Union, Regulation (EU) 2016/679, Articles 5, 17, 25 and 30
Systems That Never Modelled Deletion
Append-only event stores, immutable audit logs, denormalised read models, warehouse snapshots, search indexes, analytics pipelines, caches, and backups. Every one was a sound engineering choice, and every one duplicates personal data into a place with no deletion path. An erasure request that resolves cleanly in the primary database and leaves eleven copies elsewhere has not been satisfied, and nobody finds the eleven copies until the first request arrives.
Retention Nobody Implemented
Most organisations have a written retention policy and no mechanism enforcing it. Storage got cheap, nothing was ever deleted, and the policy became a document rather than a scheduled job. Storage limitation is not satisfied by intent. It is satisfied by data actually ageing out, which requires every store to know what it holds and how old each record is.
Article 25 makes this a design problem rather than a cleanup project. Article 25(1) requires measures designed to implement data-protection principles at the time the means of processing are determined, not afterwards. Article 25(2) requires that by default "only personal data which are necessary for each specific purpose of the processing are processed", applying that to the amount collected, the extent of processing, the period of storage, and accessibility. Article 30 then requires a record of processing activities, which in practice means knowing where personal data lives before you can claim anything about it.
The work: a data inventory mapping personal data to every store it reaches, including derived and cached copies; a deletion path per store, with the awkward ones such as event logs and backups resolved explicitly through crypto-shredding, tokenisation, or documented retention windows rather than left unanswered; and retention implemented as scheduled enforcement rather than policy text. This is slow schema and pipeline work, and exactly the kind that only gets funded when someone can point at a legal obligation. Our compliance debt guide covers audit readiness on the same problem.
One Acronym, Two Meanings: Read This Before You Search
Everywhere else on this site, DORA means DevOps Research and Assessment, the research programme behind the software delivery performance metrics. That is the sense used in our glossary and on every measurement page here.
In an EU regulatory context, DORA means something entirely different: the Digital Operational Resilience Act, Regulation (EU) 2022/2554. The two are unrelated. One is not an implementation of the other, and a search for "DORA compliance" will return both mixed together. For the rest of this section only, DORA means the regulation.
It applies from 17 January 2025 under Article 64. Its scope is narrow but deep: Article 2(1) lists categories from credit institutions and payment institutions through investment firms, insurers and crypto-asset service providers, plus ICT third-party service providers. A drafting detail worth getting right is that Article 2(2) defines only points (a) to (t) as "financial entities"; ICT third-party service providers at point (u) are in scope without being financial entities. If you are not in one of those categories and do not supply ICT services to one, this section is background reading.
If you are, it contains the most direct statement of legacy-system debt in EU law. Article 3(3) defines a "legacy ICT system" as one that has reached end-of-life, is not suitable for upgrades or fixes for technological or commercial reasons, or is no longer supported by its supplier, but is still in use and still supports the entity's functions. Article 8(7) then requires financial entities other than microenterprises to conduct a specific ICT risk assessment on all legacy ICT systems regularly and at least yearly. That is a legal definition of the thing this entire site is about, attached to a recurring obligation. Alongside it, Article 8(1) requires entities to identify, classify and document all ICT-supported business functions and the assets supporting them, Article 8(6) requires those inventories to be maintained, Article 28(3) requires a register of information covering all contractual arrangements for third-party ICT services, and Article 26(1) requires advanced threat-led penetration testing at least every three years.
Source: Official Journal of the European Union, Regulation (EU) 2022/2554, Articles 2, 3, 8, 26, 28 and 64
Every Instrument as Debt With a Date
The same table, read two ways. Compliance reads down the middle column. Engineering reads down the right-hand one, and recognises most of its own backlog.
| Instrument | Key dates | Existing debt it converts |
|---|---|---|
| Cyber Resilience Act Regulation (EU) 2024/2847 | In force 10 December 2024. Chapter IV from 11 June 2026. Article 14 reporting from 11 September 2026. General application 11 December 2027. | Unreproducible builds, no SBOM, unsupported dependencies, no vulnerability intake channel. |
| NIS2 Directive (EU) 2022/2555 | Transposition due 17 October 2024, national measures applying from 18 October 2024. Binds via national law. | Unpatched dependencies, no supplier security review, no vulnerability handling process, untrained leadership. |
| AI Act Regulation (EU) 2024/1689 | In force 1 August 2024. Prohibitions from 2 February 2025. General application 2 August 2026. High-risk under Annex III from 2 December 2027 and under Annex I from 2 August 2028, as amended. | No model or dataset lineage, evals that ran once at launch, no decision logging, undocumented intended use. |
| European Accessibility Act Directive (EU) 2019/882 | Applying since 28 June 2025. Limited transitional periods to 28 June 2030 for certain products already in use. | WCAG violations, keyboard traps, unlabelled controls, components that were never accessible by default. |
| GDPR Regulation (EU) 2016/679 | Applying since 25 May 2018. No future deadline; a standing obligation. | Schemas with no deletion path, retention policies never implemented, personal data in stores nobody inventoried. |
| DORA, the regulation Regulation (EU) 2022/2554 | Applying since 17 January 2025. Financial sector and its ICT suppliers only. | Legacy end-of-life systems with no annual risk assessment, no asset inventory, no third-party ICT register. |
Dates verified against the Official Journal texts on EUR-Lex. Confirm applicability to your organisation with your own counsel.
Building a Compliance Deadline Register Engineering Will Maintain
Most organisations already have a compliance calendar. It lives in the legal function, it is a spreadsheet, and no engineer has ever opened it. That is the failure mode to design against, because a register that is accurate and unread is worth about as much as no register at all.
One row per obligation, not per regulation
"The Cyber Resilience Act" is not an actionable row. "Produce a machine-readable SBOM covering at least top-level dependencies, for every shipped release" is. Break each instrument into discrete things someone has to build, and cite the article behind each so nobody relitigates why it is on the list.
Name an engineering owner, not a department
Every row needs a person who can say what state it is in without scheduling a meeting. Ownership split between legal and engineering reliably produces an obligation each side believes the other is handling. Legal owns the interpretation; engineering owns the artifact.
Record the lead time, not just the legal date
A row with only a compliance date tells you when you are late. Add an estimated engineering lead time and the register tells you when to start, which is the only number that changes behaviour. Replacing an end-of-life runtime across a product line is quarters of work, so its start date is years before its deadline.
Point each row at evidence a machine produces
Evidence assembled by hand before an audit goes stale the day after. Wherever possible a row should point at a build artifact, a CI check, or a continuously generated dashboard. An SBOM emitted by every build is evidence. An SBOM someone generated last March is a screenshot.
Review on a schedule, because the law moves
The AI Act high-risk dates on this page were amended after the original text was enacted, and directives are transposed on each Member State's own timetable. A register written once is wrong within a year. Schedule a recurring review and record, per row, when it was last checked and against what source.
Keep it where engineers already are
A register living in a document system engineers have no login for is legal's register and nothing more. Put it in the same tracker as the rest of the work, so compliance rows compete for capacity in the open alongside features instead of arriving as a surprise escalation.
The register also solves a political problem. Compliance work arriving as an emergency is absorbed as unplanned interruption, and everyone concludes compliance is a tax. The same work arriving as a dated row visible for two years is simply planned work with a hard date, which is the easiest kind to defend.
Related Resources
Compliance Debt
The US-facing counterpart to this page: SOC 2, HIPAA, PCI-DSS, audit readiness gaps, and regulatory change management.
Security & Supply Chain
SBOM formats and tooling, vulnerability handling, and the supply chain debt the Cyber Resilience Act puts a date on.
Dependency Management
Abandoned packages, outdated versions, and the inventory problem underneath every support-period commitment.
UX & Design Debt
WCAG 2.2 remediation, accessibility automation, and the design system work the European Accessibility Act now requires.
AI Product Debt
Eval debt, model lineage, and drift, which is where most of the AI Act high-risk evidence burden actually lands.
Observability Debt
The detection and logging capability that every 24-hour reporting clock on this page quietly assumes you already have.
Frequently Asked Questions
Often yes, because these instruments generally attach to placing a product or service on the Union market rather than to where a company is incorporated. But scope varies by instrument, product category, company size, and sector, and this page cannot determine it for you. That is a question for your own counsel, and worth answering early: the engineering lead times here are measured in quarters, not weeks.
Sequence by lead time rather than by deadline. European Accessibility Act obligations have applied since June 2025, so for anyone selling into the EU that is present-tense work. After that, the Cyber Resilience Act items with the longest lead times deserve attention first even though general application is further out, because reproducible builds and replacing end-of-life dependencies are slow. Work backwards from each date by its lead time and start with whichever start date is earliest.
No. The SBOM sits inside a broader vulnerability handling obligation, and Annex I Part II point (1) frames it as a means of identifying and documenting vulnerabilities and components, with top-level dependencies described as the very least it must cover. The useful test is operational rather than documentary: when the next widely exploited library flaw is announced, how long does it take to answer whether you ship it, in which released versions, and to how many customers. If that answer is days, the SBOM is not yet doing its job.
Article 20(1) requires Member States to ensure that management bodies approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for infringements of Article 21. Practically, the people who approve your maintenance budget now have a personal stake in deferring it, and under Article 20(2) they must be trained well enough to understand what they are approving. The leverage for engineers is in framing: a deferred dependency upgrade is now a documented risk decision a named director signed off on, so bring specifics.
Partly, and the detail matters. Regulation (EU) 2026/1744, the Digital Omnibus on AI, replaces point (c) of the third paragraph of Article 113 so that Chapter III Sections 1 to 3, apart from Article 6(5), apply from 2 December 2027 for high-risk systems under Article 6(2) and Annex III, and from 2 August 2028 for those under Article 6(1) and Annex I. The two categories are now on different clocks, which is what most summaries get wrong. The general application date in the second paragraph of Article 113 was not amended, so treating this as a blanket postponement would put your planning in the wrong place.
Give every row a named engineering owner, a recorded review date, and evidence a machine produces rather than a person assembles. Registers rot in three predictable ways: the law changes underneath them, the owner leaves, and the evidence becomes a stale screenshot. A scheduled review addresses the first, naming an individual rather than a department addresses the second, and pointing each row at a build artifact or CI check addresses the third. Keep it in the same tracker as the rest of engineering work so compliance rows compete for capacity in the open.
Give Your Technical Debt a Due Date
Regulation will not fix your codebase. What it will do is give the work you already wanted to do a date that other people take seriously. Use it.