MONOLITH LAW OFFICE+81-3-6262-3248Weekdays 10:00-18:00 JST

MONOLITH LAW MAGAZINE

IT

What are the Laws Related to Disputes and Troubles at the System Operation Stage?

IT

What are the Laws Related to Disputes and Troubles at the System Operation Stage?

It is well known that various disputes and troubles can arise in projects to develop IT systems. However, it is not the case that everything is safe and sound once all stages of the development project are successfully completed. IT systems used in companies, by their nature, typically handle a large amount of confidential and personal information, and various problems can occur even at the operational stage. Therefore, it is important to utilize legal expertise in considering measures and prevention against such situations at the operational stage.

How Legal Discussions Around Systems Change Between Development and Operation

What are the legal issues surrounding the ‘development’ and ‘operation’ of IT systems?

A typical legal issue related to IT systems used in companies is the ‘flaming’ problem during the ‘development’ stage of a project. System development projects often involve a large number of people, funds, and time, and it is common for them to proceed while carrying various risks of disputes and troubles, big or small.

https://monolith.law/corporate/collapse-of-the-system-development-project[ja]

In the above article, we have organized the types of disputes that often occur in a series of system development projects according to a legal framework. Also, what personalityizes legal issues related to IT systems is the ‘project management obligation’ that the system development expert, the vendor, is supposed to bear comprehensively.

https://monolith.law/corporate/project-management-duties[ja]

However, after ‘development’, IT systems move into the ‘operation’ phase. In a nutshell, operation in IT systems means using and operating the developed system to carry out actual work. Since it is often necessary to be familiar with the specifications of the system to utilize it, the power of IT engineers is often needed here as well. The fact that technical knowledge is required in both development and operation of IT systems means that the distinction between the two can sometimes be ambiguous in practice. An example that succinctly illustrates this is the existence of ‘support obligations’.

https://monolith.law/corporate/support-obligations-of-vendors-after-system-development[ja]

In the above article, we introduce a court case that recognized ‘support obligations’ as an obligation to provide support for operation and introduction after development, distinct from the ‘project management obligations’ that vendors bear during system development projects. In other words, there are cases where the legal obligations of vendors who undertake development work are determined while taking into account the circumstances of the subsequent operation phase. Also, when the development of a new system progresses simultaneously with the abolition of the old system, issues such as ‘data migration’ from the old system may arise. In such cases, the operation of the old system and the development of the new system are closely related.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

How to Organize Legal Issues Related to System Operation

As we have seen, the practical aspects of IT systems are closely intertwined between ‘development’ and ‘operation’. However, in the operation phase, the development project has ended, so it is necessary to consider the issue of ‘project management obligations’ separately. In order to discuss the legal issues of ‘development’ and ‘operation’ in a unified manner, it is necessary to organize them in a slightly more legal-oriented and abstract framework. For example, the organization from the legal perspective of ‘responsibility’ related to IT systems, which is explained in the following article, is one such example.

https://monolith.law/corporate/responsibility-system-development[ja]

In the above article, we explain about civil liability for breach of contract, warranty liability for defects, and tort liability, taking into account the context of IT systems. However, cases where warranty liability for defects becomes an issue in operation are not often anticipated, except for cases where defects are discovered after acceptance. Therefore, it would be best to first organize with the two points of breach of contract liability based on contract content and tort liability not based on contract relations in mind.

First, Consider Whether There is a Breach of Obligation on the Vendor’s Side

The issue is whether there is a reality of ‘infringement of others’ rights’ in the case of tort liability, or a breach of contractual obligations in the case of breach of contract liability. In the case of breach of contract liability, the contents of the Service Level Agreement (SLA) will be an issue. Also, note that both breach of contract liability and tort liability require intent or negligence.

Next, Confirm the Occurrence of Damage on the User’s Side

The obligation to compensate for damages is borne in relation to the actual damage incurred on the user’s side. Therefore, whether it is a case of breach of contract or tort, if no damage has occurred on the user’s side, there will be no obligation to compensate.

Further, Consider the Applicability of Negligence Offset and Limitation of Liability Clauses

Even if the vendor side is liable for damages, if there is some negligence on the user side, it is possible that a process such as negligence offset will be applied. Also, if a limit is set on the amount of compensation in the contract concluded in advance, the amount of compensation may change accordingly. For example, in the contract template known as the METI Model Contract, the following provision is placed regarding limited liability (the underlined part is added by the author).

(Damages)
Article 53 The parties A and B may claim damages against the other party if they suffer damage due to a cause attributable to the other party in relation to the performance of this contract and individual contracts. However, this claim cannot be made after ○ months have passed from the completion date of the acceptance of the deliverables stipulated in the individual contract that is the cause of the claim for such damages or the confirmation date of the end of the work.

2. The total cumulative amount of damages under the preceding paragraph shall be limited to the amount of ○○○ stipulated in the individual contract that caused the cause of liability, regardless of the cause of the claim, such as breach of contract, legal warranty liability for defects, unjust enrichment, tort, etc.

3. The preceding paragraph shall not apply in the case where the obligation to compensate for damages is based on the intentional or gross negligence of the person liable for damages.

Common Troubles and Disputes in System Operation: Case Studies

What should you be aware of when resolving troubles and disputes in system operation?

In practice, the following are representative examples of troubles and disputes that can be anticipated in system operation.

Accidents such as data loss caused by mistakes of the operation manager

Work related to system operation often involves handling important corporate secrets and personal information, and accidents can occur due to carelessness. One such example is “data loss”. We explain this issue in detail in the following article.

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

It is important to take precautions, such as backing up data in advance, to prevent accidents like data loss. If these measures are neglected, it can be extremely difficult to hold the vendor responsible for the operation accountable, so caution is necessary.

Security attacks including viruses

Also, in the case of IT systems like EC sites that are heavily used by a large number of people on the web, major incidents or accidents can occur due to security attacks including viruses. Detecting such security attacks and taking measures against them may also be part of the operation tasks.

Bugs and malfunctions that become apparent after acceptance

Furthermore, bugs and malfunctions may become apparent after acceptance. It is not always possible to exhaustively consider all potential bugs and malfunctions in the pre-test process, and they may become apparent afterwards. In such cases, since delivery has already been completed, the performance of the obligation itself is usually considered to have been completed, and the vendor is normally exempted from liability for non-performance. However, claims for damages based on warranty liability for defects may be recognized. We explain this issue in detail in the following article.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Summary

In the “operation” phase of a system, there are numerous troubles and disputes that are different in nature from development projects. However, by basing on legal theories such as liability for breach of contract, tort liability, and warranty liability, it is possible to organize a unified field without being trapped by these differences.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Return to Top