The term “legacy systems” plays an increasing role in business risk management. Legacy systems commonly refer to outdated computer systems, networks, programming languages, or software. The definition of “legacy system” is subjective because these systems may vary in outdatedness. For example, hardware has age limits, and software ceases to be updated and becomes incompatible with new operating systems. Computer systems are often acquired, built, and implemented at various points throughout a company’s history. Furthermore, changes in business practices may render once acceptable systems obsolete by demanding new abilities from unchangeable software.
Regardless of their limitations, legacy systems continue to play a key role in companies of all sizes. Dealing with legacy systems is about balancing business goals, legal liabilities, technology, and user needs. Although some believe that IT staff should be responsible for this balancing act, lawyers play a crucial role because technology issues affect a company’s overall risk management. This article aims to provide guidance for lawyers in assessing risks associated with legacy systems.
Identify the System
The initial consideration with any legacy system is to identify the type of system a company utilizes:
- Is the system a commercial, off-the-shelf solution?
- Is it a custom-built solution?
- What type of code is utilized in the system?
- Who originally built the system, and are they still in existence?
Determining the type of system used will provide key information to assess whether that system is still viable, and what risks exist in the current network infrastructure.
Identify Roles and Responsibilities
Next, the contracts that govern the use and maintenance of the system should be located and reviewed to understand the responsibilities of the parties. It may be difficult at times to locate these documents, especially for a system that may be decades old. Furthermore, maintenance of a system should be assessed from both a technological and contractual perspective. Who is responsible for ensuring that updates, patches, and any other changes are implemented in a timely manner?
The Equifax breach exemplifies the importance of system patches. Access to Equifax’s systems and the data of approximately half the U.S. population resulted from Equifax’s failure to implement a patch that was available two months before the infiltration. Another example is The Royal Bank of Scotland and the NatWest system failure in 2013. Customers were unable to access accounts, use debit or credit cards, or make online payments on Cyber Monday—a failure that RBS officials admitted was a result of decades-old systems and a failure to maintain those systems.
Keep It or Replace It
In some cases, the original designers of these systems have either moved on to other companies or retired from the workforce, without leaving sufficient documentation to provide guidance to those that remain. If your IT team does not understand a system, how can it protect and evolve it to meet the needs of the business? This inevitably begs the question: Is the system so old that it cannot even be maintained?
Legacy systems may incorporate old code and software that a modern workforce is unable to support. In some instances, the coding language is so archaic that it is no longer taught in school. For example, COBOL, a programming language used in many legacy mainframe systems including that of the banking industry, is used only to maintain existing applications and is not commonly taught anymore. These systems can become so outdated that they are unable to scale to encompass new tasks and technologies, which in turn becomes an inhibitor to innovation and evolution within a company.
The Importance of System Architecture
Many companies rely on multiple systems that are cobbled together without a clear system architecture. To resolve operational issues that may arise, IT might develop patchwork solutions that inadvertently create security vulnerabilities and further add layers of complexity. The pitfalls of complexity are exemplified by the cyber attacks on the U.S. Office of Personnel Management (OPM). OPM was infiltrated in two separate incidents: (1) the hackers gained access to OPM’s system for almost two years before OPM became aware; and (2) the second incident lasted for approximately one year before becoming known. OPM’s complex structure, combined with poor cyber hygiene and outdated security technology, contributed to the delay in realizing the unauthorized access.
System complexity creates issues with system recovery and redundancy. These incremental enhancements balloon into a nightmare that traps companies as prisoners in their own legacy systems. IT management quickly morphs into risk management, continually requiring that the company maintain a record of these risks and develop internal solutions to minimize those risks.
Even if these systems are not complex, they still suffer from a lack of developer familiarity with the system as well as a lack of documentation regarding the overall software architecture. Without continuity in the workforce to provide for an exchange of information as new employees take over management of these operations, there is little to no guidance available to keep these systems running.
Cybersecurity Risks
All these factors contribute to growing vulnerabilities associated with legacy systems from a legal, technological, and operational perspective. Given that systems integrate with interdependent systems, it is challenging to create automatic protections from new threats. Furthermore, patching is more difficult because it is not simply pushing a patch out to one system. If the technology team does not or cannot understand a network’s infrastructure, it is difficult to implement a patch to the system. In some cases, system developers do not provide continued maintenance and support, so patches are not even available to fix known security or design flaws. For example, Microsoft announced in 2016 that it would no longer support Windows XP. Security protocols should be uniform and integrated across all systems, but with no clear system architecture, this task can become seemingly impossible.
In certain industries, the risks may be even higher. Two recent regulatory changes that may impact the use of legacy systems are the New York Department of Financial Services Cybersecurity Regulation, 23 NYCRR 500 (DFS Regulation), and the forthcoming European Union’s General Data Protection Regulation (GDPR). Both regulations demand higher standards for data protection and security, requiring that companies not only understand their systems, but in some cases proactively redesign those systems if they don’t comply.
In the United States alone, numerous states are considering changes to cybersecurity and data privacy laws that will strain these legacy systems even further beyond their capabilities. Many states, including Delaware, South Dakota, and Colorado, have proposed legislation in the last six months (in response to the Equifax breach) that would shorten the timeframe for notifying citizens of data breaches and expand the definition of what constitutes a breach that requires notification. These proposed regulatory changes would necessitate that companies have a strong knowledge of their systems, the data maintained in those systems, and system access points in order to efficiently determine whether unauthorized access occurred. Legacy systems pose significant hurdles to compliance because of their complex structure, which may make complying with these proposed regulations more difficult.
The Growing Role of a Lawyer
As these legacy systems continue to hit boundaries, and maintenance becomes harder because of age and the lack of an informed workforce to maintain these systems, companies must critically assess next steps. Companies should begin by creating a comprehensive plan of action. They must bring together an interdisciplinary team to assess the legacy system’s long-term viability, the company’s need for the system, and the appropriate plan of action to address the vulnerabilities and risks within that system. Input should be received from all sectors of an organization (legal, IT, marketing, security, privacy, financial, etc.) throughout the entire process.
The legal liabilities play a pivotal role in that analysis: if the creator of a legacy system is no longer in existence or has strategically decided not to maintain a system, what happens in the event of a breach? Who is held responsible for a system vulnerability? It is important that the contractual relationships among the system providers, either in a legacy system or newer systems, are clearly understood and considered in the plan of action.
Legacy systems play a pivotal role in business. Migrating these legacy systems to newer technologies involves a delicate balance between an expensive overhaul of an entire system and incremental fixes. Ultimately, a company must assess its current environment to determine whether the vulnerabilities and risks, to the extent they are even known or can be discovered, can be sustained by the company or whether the technology’s lifecycle has run its course. Technology continues to evolve at an unprecedented rate, and companies must critically assess their situation. Lawyers must be prepared to delve deeply into these issues with their clients to understand both the legal liabilities that attach to these legacy systems and the risks associated with migrating to new systems.
I would like to thank Conor Gilsenan for reviewing and providing insight into this article.
