New Regulation: Software Defect or Change Request?

When legislation introduces new requirements for documentation, logging, data access or resilience, the same dispute often follows. The customer sees the modification as remediation of a contractual defect or non-conformity (Mangel) already owed under the contract. The provider treats it as a chargeable change request.

There is no general answer. A new regulatory requirement does not automatically make existing software defective; nor is every modification automatically a new service that must be paid for separately. The relevant factors include the contract type, the validly agreed services and purposes, interpretation of the agreement and any supplementary statutory rules. The contract is the starting point, but it is not necessarily the only source of the provider’s obligations.[5]

Four distinct levels of analysis

1. Regulatory responsibility

Regimes such as DORA assign primary regulatory responsibility to the regulated entity. Under Article 28(1)(a) DORA, a financial entity remains fully responsible even when using third-party ICT services.[1]

That does not determine the service the provider owes. Regulatory accountability and the provider’s contractual scope are separate questions.

2. The contractually agreed purpose

What matters is the contractually agreed characteristics and intended use. If software was expressly sold as DORA-compliant, suitable for GoBD purposes or designed for a regulated process, regulatory suitability may form part of the contractual performance. If the commitment was limited to a clearly defined function, an additional new function is more likely to require a contract change.

3. Ongoing maintenance and updates

Maintenance and support agreements vary considerably. Some cover only defect remediation and security updates. Others promise adaptation to changes in law, continuing compliance or functional maintenance. Terms such as “updates” or “legislative changes” should therefore not be left undefined.

4. New functionality or restoration of conformity

Non-conformity must first be assessed at the time relevant to the particular contract type—for example, transfer of risk or acceptance of the work (Abnahme), where applicable. An agreed characteristic already missing at that time calls for a different assessment from a regulatory requirement that arises years later. A subsequent legal change will generally create an adaptation duty only where the contract provides for continuing legal, maintenance, update or preservation obligations, or where such a duty follows from the statutory rules applicable to the specific continuing contractual relationship. It also matters whether the change involves a parameter or report, or requires an entirely new architecture for archiving, audit or exit.[5]

What DORA actually regulates

Article 30 DORA requires specific provisions in ICT service contracts, including the service description, service levels, incident assistance, data return and termination arrangements. For services supporting critical or important functions, additional provisions include audit and exit arrangements.[1]

DORA does not, however, generally require all future development prompted by regulation to be provided free of charge. For incident assistance, Article 30(2)(f) expressly requires the parties to agree whether it will be provided at no additional cost or at a cost determined in advance.[1]

Under Article 30(4), financial entities and ICT third-party service providers are to consider standard contractual clauses developed by public authorities when negotiating contracts. This does not automatically amend existing agreements. Whether a legacy contract requires amendment depends on its content and interpretation and on the contractual rights required for regulatory compliance; BaFin has referred in its practical guidance to potential renegotiation needs.[2]

Consumer law does not automatically carry across to B2B contracts

Sections 327 et seq. of the German Civil Code (BGB) contain special rules for consumer contracts concerning digital products. Section 327f BGB requires updates—including security updates—necessary to maintain conformity during the relevant period.[3][4] These provisions primarily govern consumer contracts. Statutory recourse and supply-chain effects, including section 327u BGB, remain unaffected; sections 327 et seq. do not establish a general B2B update regime.

This does not mean there are no update or defect-remediation duties in B2B arrangements. Those duties arise from the contract type, service description, agreed qualities, maintenance agreement and general legal rules—not from an undifferentiated transfer of digital consumer law.

A defensible decision matrix

A modification is more likely to amount to defect remediation or maintenance already owed where:

• the regulatory characteristic was expressly promised,
• the agreed purpose cannot be achieved without the modification,
• the provider assumed responsibility for continuing legal or compliance updates,
• an existing function fails to meet the agreed requirements,
• the maintenance scope clearly includes changes of this kind.

A modification is more likely to require a change request or renegotiation where:

• the regulatory regime introduced new requirements only after the contract was concluded,
• new functionality or a material system change is required,
• no continuing adaptation to legal change was agreed,
• the original intended use can still be achieved without the enhancement,
• new audit, export, data-portability or exit services are added,
• scope, cooperation, liability and cost need to be defined afresh.

This matrix is no substitute for applying the law to the facts of a particular case. It does, however, help prevent either party from using regulation as a catch-all argument.

What contracts should cover

Contracts for software used in or around regulated activities should at least specify:

• which versions of laws and standards form the baseline at contract signature,
• whether, and to what extent, changes in law are included,
• which security and compliance characteristics are promised,
• how changes will be assessed, prioritised and commissioned,
• who is responsible for specifying regulatory requirements in functional terms,
• the customer’s cooperation duties,
• how incident, audit and regulatory-authority assistance will be charged,
• how subcontractors, data locations and exit are addressed,
• when a modification is treated as a defect, maintenance service or change.

A blanket statement such as “all legal requirements must be complied with at all times” often creates more uncertainty than protection. It leaves open which laws, roles, systems, dates and services are meant.

Conclusion

Regulation often defines the outcome required of the supervised entity. The contract must translate that outcome into a specific service obligation for the provider. Whether a modification is owed at no additional cost, forms part of maintenance or constitutes a new change does not turn on the heading of the legislation. It turns on the performance commitment, intended use, contract type and change clauses.

Professional scope: The civil-law assessment of a particular contract should be undertaken by qualified legal counsel. Information security and compliance professionals should support that assessment by describing the requirement, system impact and control objective precisely.

Sources

[1] European Parliament and Council. Regulation (EU) 2022/2554 of 14 December 2022 on digital operational resilience for the financial sector, OJ L 333, 27 December 2022, in particular Articles 28 and 30. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554.

[2] German Federal Financial Supervisory Authority (BaFin). DORA für IKT-Drittdienstleister [DORA for ICT third-party service providers]. Presentation of 21 February 2024. https://www.bafin.de/SharedDocs/Downloads/DE/Anlage/dl_Praesentation_DORA_IKT_Drittdienstleister.pdf?__blob=publicationFile&v=1.

[3] Federal Republic of Germany. German Civil Code (Bürgerliches Gesetzbuch), in particular sections 327f and 327u. https://www.gesetze-im-internet.de/bgb/__327f.html; https://www.gesetze-im-internet.de/bgb/__327u.html.

[4] European Parliament and Council. Directive (EU) 2019/770 of 20 May 2019 on certain aspects concerning contracts for the supply of digital content and digital services, OJ L 136, 22 May 2019. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0770.

[5] Federal Republic of Germany. German Civil Code (Bürgerliches Gesetzbuch), in particular sections 133, 157, 307, 313, 434, 446, 535, 633 and 640. https://www.gesetze-im-internet.de/bgb/.