Legal Issues Associated with Databases in IT Systems

When dealing with legal issues related to IT systems, it is necessary to have a systematic understanding of the law. However, it is equally important to understand the components of an IT system. In this article, we will explain how IT systems are composed of various parts and how these parts interact to function. We will also discuss legal issues that are particularly related to databases, which may not be readily visible from the user’s perspective.

IT Systems are Composed of “Interface” and “Logic”

What is the “Interface” in IT Systems?

When trying to understand the structure of an IT system, the most noticeable aspect is likely the appearance of the interface. Indeed, in the general process of system development, after defining requirements such as functionality, the next steps usually involve “interface design” and organizing “interface transitions”. These aspects of the interface are naturally noticeable to the users who order system development, and it is also the area where communication between users and vendors is most likely to be active. In the following article, we explain the “obligation to cooperate” that users bear towards vendors throughout the entire process of system development in order to achieve project goals.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

In this article, we mainly explain the need for users to collaborate with vendors during phases such as basic design (i.e., the interface) as part of their obligation to cooperate in system development.

The “interface” in IT systems is typically described according to the rules of computer languages such as HTML and CSS. Discussions about the “interface” of an IT system are often referred to by various names such as “front-end” and “UI (User Interface)”, but the main points of discussion are “ease of operation” and “visibility” from the user’s perspective.

What is the “Logic” in IT Systems?

However, if an IT system is based solely on the “interface”, it would be nothing more than a static “interface” without any “movement” or “change”. Even if the system accepts input from users and displays output through the “interface”, there is a process of “calculation” involved.

Complex calculations and controls are performed by components that are not visible to the user, which could be referred to as the “back-end” of the system. Processes such as searching for data from the interface, rewriting data, adding, or deleting, are only possible because there is a pre-built database in the background. Various operations on the information in the database are usually done in a computer language called SQL.

By creating a path from the trigger, such as a button set up on the interface side, to the execution of the necessary SQL statement, a complete picture of a system with movement and change is completed.

Note that discussions about assembling various logics that are not visible from the “interface” are often referred to as “back-end”.

The Risk of Discussing Systems Solely from the Perspective of ‘Appearance’

Up to this point, our discussion has laid the foundation for understanding the structure of IT systems (assuming they operate on the web). Understanding these matters is significant for legal discussions, conflict prevention in projects, and crisis management. Specifically, there can be communication gaps between users who focus solely on the ‘appearance’ on the screen and vendors who handle important tasks on the unseen ‘logic’ side.

The Risk of Users and Vendors Having Completely Different Concerns

For example, users who discuss IT systems mainly in terms of the ‘screen’ often pay little attention to the complexity of the internal structure. Therefore, they may not understand how what appears to be a ‘minor addition of functionality’ or a ‘slight change in specifications’ can impact many processes. The following article explains legal issues that often arise when decommissioning existing systems during the development of a new system.

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

Here, we explain that troubles often occur during data migration to the new system when the old system is decommissioned. In other words, the complexity of the internal calculation and control mechanisms, which are unimaginable from the appearance, can be a source of unexpected trouble for the user side. Also, if the user does not understand the ‘feelings of the system-making vendor’, situations may arise where changes are made incrementally after the fact.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

In such cases where changes in specifications or additions of functions are ordered after the fact, whether it is possible to increase the reward afterwards can sometimes become a serious issue.

https://monolith.law/corporate/increase-of-estimate[ja]

The Risk of Users Being Indifferent to the Backside ‘Logic’

Furthermore, the parts that cannot be observed by the user may have become a major incident when trouble is discovered. The following is such an example.

The Risk of Issues Arising in Maintenance and Security

This includes situations where additional functions cannot be implemented, or the operation gradually becomes heavy while using it, and it stops working.

Also, there is a method called ‘SQL Injection’ as a security attack that performs a security attack that extracts personal information and confidential information that should not be displayed on the screen due to the inadequacy of the code implemented on the screen side. The following article details cases that have become serious disputes due to this.

https://monolith.law/corporate/risks-of-libraryuse-and-measures[ja]

The main theme of this article is the risks associated with the use of frameworks and libraries, but the cited court case is one where an attack was made on vulnerabilities using SQL Injection.

The Risk of Governance Not Extending to the Work of Operation Managers

The indifference of IT system users to the backside ‘logic’ is also linked to the problem that governance is difficult to extend to the work of IT system operation managers. The following article explains the importance of database handling work on the theme of ‘data loss due to negligence of operation managers’.

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

The Risk of Logic Being Wrong Even If It Appears to Be Working Correctly

The fact that the system’s story does not stop at the ‘screen’ means that even if the system appears to be working correctly on the surface, the actual ‘logic’ may be wrong. This can be unexpectedly revealed in irregular operations such as ‘once every six months’ or ‘once a year’.

In such cases, it becomes a problem of defect warranty liability under the law as a case where a defect was found after the system was delivered once.

https://monolith.law/corporate/defect-warranty-liability[ja]

As a countermeasure in case a defect is found after acceptance, the flow is explained in detail in the following article.

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

Summary

Systematic Understanding of System Development and Legal Affairs

When dealing with legal issues related to system development, it is crucial to understand which component of the IT system the problem arose from, even before identifying the legal points of contention. Whether it’s a legal issue or an IT system issue, in disputes arising from system development projects, it’s particularly important to maintain a holistic view and to strive for collaboration across different industries.