Evidence Collection for Year 2000 Litigation

Evidence Collection for Year 2000 Litigation

by Edward Miller and Stanley H. Kremen, CDP

The Problem of Year 2000 Compliance

The current century will change in less than five-hundred days. The twentieth century will end, and the twenty-first century will begin. Many look forward to the great celebration for New Years Eve 1999 and New Years Day 2000. However, we face a major computer disaster on January 1, 2000 caused by programs that represent years as two digits without an indication of what century is being referenced. When a date such as 03/22/40 is entered into the computer, the older programs do not know whether it should be March 22, 1940 or March 22, 2040. Such a program would read the year as 1940 and not 2040. Therefore, on January 1, 2000, many computers will reset their internal clocks to January 1, 1900. By itself, this may be slightly amusing or even annoying, but the inability of many computer programs to deal with dates properly can and will create havoc. Because the civilized world is so dependent on computer technology, a global economic recession is anticipated as a result of this problem. Many businesses will cease operations, and there will be widespread unemployment. Critical parts of our infrastructure will either cease functioning or will function chaotically. Some deaths will occur. As incredible as this may sound, be assured that the consequences of this computer "bug" are inevitable. There was a time when a massive effort to fix this problem in virtually all computer programs might have been totally effective. The difficulty is that most American executives refused to believe that such a seemingly minor problem would have such dire results. In Europe and Asia, the situation is worse. While many American businesses are now doing something about the problem, very few foreign companies have even addressed this issue. What is worse is that the effort that is going on now to fix this problem began too late. We now know that this problem is so severe that only a relatively small number of companies will be prepared. In anticipation of this problem, many state and local governments have mandated that they will be prepared on time. To do so, they have passed legislation to immunize them against lawsuits for damages resulting from the Year 2000 bug. It is anticipated that the litigation costs resulting from the computer malfunctions will far exceed the cost of fixing the problem.

Today, domestic and foreign companies have instituted an enormous effort to fix this problem. Some will succeed and some will not. Many will succeed partially. Those that do succeed will be known as Y2K compliant. (Y2K is industry jargon shorthand for Year 2000.) To be Y2K compliant, a company’s computer hardware and software must be able to handle dates in both the twentieth and twenty-first centuries without error or ambiguity. However, to compound the problem, there is no set standard for Y2K compliance. There are several different proposed methods for dealing with the century change:

1. Conversion to full four-digit year format;

2. Windowing techniques;

Fixed window techniques;
Sliding window techniques;

3. A two-digit encoding/compression scheme;

4. Use of a century indicator along with a two-digit date; and,

5. Setting the system clock back twenty-eight years.

(A calendar repeats itself every twenty-eight years. Therefore, for some types of businesses, it could be acceptable to reset the system clock.)

The book by Raytheon E-Systems (How to 2000, IDG Books Worldwide, Inc., Foster City, CA 1998, pg. 393) publishes the following table that shows how the century can be represented ambiguously in a computer system. These ambiguities can occur despite many Y2K remediation efforts.

Problem Type

Examples

19xx assumed as year
Two-digit year instead of four-digit year. Only a 100-year range -- 00 through 99 -- is possible. Occurs with Julian, Gregorian, and other date formats. Some examples are mm/dd/yy and yydddd.

User interface does not allow four digit years to clarify century
Users can only input two-digit years on screens. Batch parameter input limited in same fashion.

Year is part of file or tape name
Usually occurs in backup and archiving routines -- for example, file0297.txt.

Sorting puts 20xx dates before 19xx
00, 01, 98, 99 instead of 1998, 1999, 2000, 2001.

Date within programs is truncated
If you input 1996, the program stores 96. If you input 2001, the program stores 01.

Century is hard coded
19 is always displayed in format of two-digit years.

Assumption that century is always derived from today’s date
If you input 00 for 2000 during 1997, the program stores 1900. If you input 99 for 1999 during 2000, the program stores 2099.

Possible user misinterpretation
For example, 03/02/01 can be either March 2, 2001 (mm/dd/yy, which is common in the U.S.); February 1, 2003 (yy/mm/dd, which is a common sort order); or February 3, 2001 (dd/mm/yy, the international format). Another example is that "01/02/00" reports as "1/2/" because of zero suppression.

Assume that your company, in trying to become Y2K compliant, purchases software packages from several vendors. If some of the software packages are not Y2K compliant, they cannot be implemented unless they are for non-critical applications only. However, for those applications that are Y2K compliant, treatment of the dates could be different. This is all right if the systems do not have to interface with each other. If they are required to interact, having different Y2K formats in various applications could create a disaster for your business operations. Generally, if the date formats are different, dates generated by one application would not be understood by another. Restricting the date formats to a single one may severely limit your company’s ability to purchase a complete suite of usable software. This problem is further compounded when your purchased software must interact with your already existing in-house software that has been repaired so as to be Y2K compliant.

There are even greater problems where your in-house applications use streams of data coming from outside services. Where these data contain dates in different formats, your computer applications can become very confused. While your business might have control over the way it stores its own dates, it has no control over the way an outside service stores its data. If the outside service is important to your company, then, if the service decides that it will transmit a two-digit date, your company’s computer programs had better be ready to process a two-digit date. Furthermore, the format of the data from an outside service is subject to change at short notice.

Therefore we can speak of internal Y2K compliance and overall Y2K compliance. To be compliant internally is to be able to handle all dates given all interactions between in-house software modules. Overall compliance is to be completely date independent provided that all data, both in-house generated and transmitted from the outside, is Y2K compliant. To be internally compliant is not an easy task. Sometimes there are legacy systems for which source code does not exist. In those cases, your company must evaluate the cost of eliminating the application or re-platforming it. Some programs do not use dates. In that case, you can still use that software. Otherwise, reverse engineering could be required. Sometimes, the software is not supported any more. Your company could have a special modification to an operating system that is very old. It may not have been maintained for a long time. There are old releases. If an older IBM database management system is still in use, such as IMS or DB2, it must be upgraded to make it Y2K compliant. All of the underlying hardware and operating system software must be tested. All job schedules must be tested. Your company must try to obtain certification from all third party hardware and software vendors to assure you that their software is compliant. In purchasing new software, your company must ascertain whether it must interface with in-house software. You must examine application dates coming from the new software. If your in-house software can handle dates in the new format, then your company can purchase the software. Otherwise, it is not recommended.

A rational approach to the problem would be to have a single program module handle all date conversion. This program itself would be Y2K compliant. The program would be able to handle a date of any format as long as it distinguishes between centuries. Such a program would handle all of the interfaces. The algorithms for date conversion would be complex and numerous. However, potentially there would only be a single point of failure. If an application was using two-digit years before the century change, then it will continue to use two-digit years after the century change. If it was using four-digit years, it will continue to use four-digit years. If some applications use two-digit years with a sliding window or a fixed window, it can continue to do so in the same manner. The conversion program would act as the interface. Where data streams are received from outside sources, the rule should be that the "sending" application controls the date format. Dates must be accepted in any Y2K compliant mode, and the conversion program would create a new date format dependent upon the nature of the application receiving the data.

Let us assume that your company has adequately prepared itself to be Y2K compliant sometime in 1998 or 1999 only to find out in the year 2000 that it is actually not compliant. This is where lawsuits emerge.

As a company executive responsible for business continuity, you must assume that, despite every effort to become Y2K compliant, come January 1, 2000, compliance will not be achieved. You must assume that the failure to comply will be either partial or total. You should map out a worst case scenario, a best case scenario, and a group of likely scenarios for failure. A risk analysis should be done and a contingency plan should be developed for each scenario. Although the potential failure of critical infrastructures should be taken into account, the most likely situation considered by this article is the failure of one or more critical data processing systems. The consequences of such failure are enormous. In some cases, crucial computer programs can cease operation causing equipment to malfunction. In other cases, data vital to your company’s operations can become irretrievably corrupt. Business disruptions and business failures are possible from such a scenario.

Under What Circumstances Might Lawsuits Occur?

Lawsuits are extremely costly and undesirable. Unfortunately, we live in a litigious society. People sue each other every day without regard to the cost and the toll that such action might have on their normal business activities. Your company should do whatever it can to avoid such an action. However, the year 2000 millennium bug will probably create many situations where lawsuits are unavoidable. Although some of these could be frivolous, most of them will probably occur because the damages are extensive and the company or individual(s) that caused the damage will be unable to correct the problem.

Your company must do what it can to be ready for the year 2000. Hopefully, a situation requiring litigation will not be necessary. Contracts are rarely entered into with anticipation by either party that litigation will ensue. Yet, it happens every day. Even with awareness of the potential Y2K risks, the most careful individuals could become careless. After the turn of the century, hindsight will exacerbate these situations. The litigation potential for issues connected with the millennium bug is so high that even the most prudent business executives must assume that it will happen. In addition to your company doing what it can to become Y2K compliant, you must work to ensure success should litigation occur. That being the case, your organization, as the potential litigant, should begin collecting evidence in anticipation of a lawsuit now. Failure to do so will probably result in your company being unprepared for trial. Records can be lost or destroyed.

When a lawsuit occurs, your company will either be a plaintiff or a defendant. An article published in this issue of Computer Forensics Online tm (Reid, Warren S., The Year 2000 Paper Trail) proposes a list of items to be compiled under the assumption that your company is a defendant. The subject of this current article is the collection of evidence assuming that your company is a plaintiff.

In attempting to achieve Y2K compliance, your business can perform its own remediation, outsource the remediation, or purchase new Y2K compliant systems. In most cases, it will do a combination of these things. If your own personnel attempt to modify existing systems or create new compliant systems and fail (either partially or totally), the consequences are well known. In this case, there is probably no legal recourse. However, suppose your company either outsources the conversion efforts or purchases a computer system expecting Y2K compliance only to find it non-compliant without sufficient time to mitigate its damages.

Outsourcing is a new term in the data processing industry. It refers to a company hiring an independent third party vendor (either a consultant, software house or service bureau) to perform systems analysis, programming services and/or data center operations. When outsourcing its Y2K remediation, the hiring party can either purchase new custom or customized software from an outsource vendor or it can elect to have the vendor perform all modifications to its existing software to assure Y2K compliance. Sometimes, the outsource vendor will sell or resell hardware or packaged software to its client. Furthermore, it is not uncommon for an outsource vendor to revamp some or all of its client’s data processing operations and procedures. It is important to determine in which situations the third party vendor is acting as a VAR (value added retailer) and in which situations it is acting purely as a service provider. The sale of software (often even if the package is custom or customized) is usually governed by the terms of Article 2 of the Uniform Commercial Code. Contracts for pure services are normally governed by the common law.

A buyer purchasing a non-compliant computer system could agree to waive his rights under the Uniform Commercial Code. Buyers often sign pre-printed form contracts agreeing not to hold vendors liable for breach of the implied warranties of merchantability and fitness for a particular purpose. Buyers typically agree to limited express warranties and to shortening the statute of limitations for being able to sue. If you purchase a system in 1998 or 1999 in anticipation of it being Y2K compliant, and discover in mid-2000 that it is not compliant, what recourse do you have against a vendor where there is a mutual agreement for a six-month limited warranty. If there was a promise of future performance, then you might prevail. However, in many instances, you may need to prove that Y2K compliance was promised by the vendor in some form without reliance on the fact that the system was unmerchantable or failed to meet your company’s specific needs.

A major problem is determining what Y2K compliance means. If you look at the IBM website (http://www.ibm.com/IBM/year2000/y2kfaq.html), you will find the following vague statement:

When we say a product is "Year 2000 ready," we mean the "product, when used in accordance with its associated documentation, is capable of correctly processing, providing and/or receiving date data within and between the 20th and 21st centuries, provided that all other products (for example, software, hardware and firmware) used with the product properly exchange accurate date data with it."

Many software vendors say that if the buyer’s software handles dates properly, its software works along with the buyer’s software. These statements are so non-specific as to be virtually meaningless. If a software vendor or commercial data supplier says that it will provide you with compliant dates, does it mean that years will have four digits, two digits, windows, etc. One just does not know how the dates are to be calculated. When vendor statements are that vague, and the vendor refuses to provide you with a Y2K compliance statement, do you have a legal recourse?

If you rely on a vendor that will not have its product Y2K compliant until December 1998, you may have problems. If your own applications are compliant, then you may be okay. However, if the vendor does not give you sufficient time to test before you are affected by the dates, is there a liability issue?

Supposing that a vendor claimed that the new version of a software package will be Y2K compliant by July 1998, and you decided to wait so as to be able to purchase it. Then, the compliant version becomes available much later precluding options that may have been available to you earlier. Is this a proper subject for litigation?

Furthermore, assume that the vendor is the only one producing the software that you require. In addition, the vendor specifically states that the software will not be Y2K compliant prior to a certain date. In this case, you have the choice of whether or not to purchase the package. The burden of achieving Y2K compliance is your responsibility. However, what if you need a Y2K compliant upgrade to a package already existing in your facility. Is it the vendor’s responsibility to provide that upgrade?

Often, in multiple versions of a vendor’s software, the early version has some problems. The next version fixes these problems. Frequently, the following version reintroduces the same problems. Suppose that the second version is Y2K compliant. If the third version loses some of its Y2K compliance, should you be responsible for testing Y2K issues again after the millennium?

If you have a maintenance contract on an existing software package, the vendor promises to maintain the software. However, that may not guarantee performance. If the software was installed prior to 1995 before it was generally realized that the millennium bug existed, who pays for the upgrades? What if the software was installed prior to 1990? How about prior to 1985? What if, under these circumstances, it is determined that, because the vendor began its Y2K remediation too late, it is impossible for compliance to be achieved in time for you to avoid severe consequences. Is the vendor liable?

Preparing for Potential Lawsuits

To prepare for potential lawsuits you may need the assistance of both a technical expert and an attorney. This preparation will consist of the following steps:

Analyze your company’s business operations and determine which of these depend upon data processing. In preparing for potential lawsuits, peripheral infrastructures can be ignored. For example, although continued operation of building elevators could be critical to enable your employees to work, such potential Y2K problems can be dealt with as they occur.
For each of the above business activities, determine its criticality to your company’s continuing operations. Assign a criticality value to each of these activities. For example, a criticality value of "0" could mean that loss of that function would have no impact upon your business, and a criticality value of "10" could mean that you would have to discontinue operation of your company if that function were unavailable for even a minimal amount of time.
Assume total loss of functionality for each of the above business activities. Develop multiple contingency plans (without regard to cost) to cover every assumed loss. For example, it may be possible to either revert to a manual system or to discontinue the business activity in the event of loss.
For each critical activity above, determine the cost and effort to implement each contingency plan developed. Determine whether or not the contingency plan can actually be implemented in time to salvage the operation.
For each critical activity above, ascertain whether it is worth the cost and effort to implement a contingency plan (based upon the possible risk of loss and its impact upon your company).
Based upon your above analysis, either selectively implement contingency plans or prepare for their implementation after the millennium in order to mitigate your potential damages. Keep careful records of the costs of all such efforts.
Insure against potential problems if cost effective, but do not assume that an insurance company will pay claims in case of loss. A potential lawsuit could be against your insurance carrier.
If your company has begun its Y2K remediation efforts, ascertain the status of each of these efforts in writing. This is particularly important where an outside vendor is involved in the remediation effort in any way. Status reports should be obtained from both in-house personnel and from the third-party vendor. Vague statements must be clarified. Y2K compliance must be defined. If total Y2K compliance will not be achieved in time according to the original remediation plans, determine what additional money and effort, if any, can speed up the process. Maintain a paper trail.
If your company has completed its Y2K remediation efforts, obtain written statements from all outside vendors as well as from in-house personnel as to the status of Y2K compliance. Once again, vague statements must be clarified and Y2K compliance must be defined.
If your company has not yet begun its Y2K remediation efforts, it may be too late. In any event, do not give up. Favor replacement of all non compliant systems with new hardware and packaged software rather than repair. Implement contingency plans for all critical activities.
Collect and maintain all time sheets as well as cost documents for all Y2K remediation efforts.
Take a physical inventory of all computer hardware and software owned, leased, rented or licensed by your company. Obtain a statement of the status of Y2K compliance for each item from in-house personnel. Collect and store the results of all previous Y2K compliance testing. If tests have not yet been performed, now is the time to perform them.
Collect and store all purchase, rental, lease and license agreements for hardware and software as well as all hardware and software maintenance contracts.
Solicit and obtain written Y2K compliance statements for all purchased, rented, leased and licensed items from the vendors. Such statements must also be secured from vendors maintaining data processing hardware and software. If possible, send Y2K compliance form letters to every vendor. Insist that the vendors respond using any means available to you.
Solicit and obtain written Y2K compliance statements from all suppliers. Remember, you are dependent upon them. If they are not Y2K compliant, their failure to supply you with data or raw materials necessary for your operations can cripple your business even if your company is Y2K compliant. If possible, send Y2K compliance form letters to every supplier. Insist that your suppliers respond in writing. Make sure that Y2K compliance is clearly defined. If they do not respond, consider replacing the supplier.
Solicit from both current and former employees records of statements made by third party vendors of data processing systems during the sales cycle.
From this point forward, should you elect to purchase new hardware, software or turnkey system, or to outsource new software development, insist upon written Y2K compliance statements from all third party vendors. If such statements are not forthcoming or if their standard agreements disclaim any effects of the millennium bug, do not purchase or outsource the item. Written Y2K compliance statements must be obtained as well from in-house personnel for all internal development efforts.
Make sure that all in-house personnel are aware of the millennium bug and of your company’s efforts to perform its Y2K remediation. Publish a manual.
Detailed time sheets should be maintained for all personnel (both hourly and salaried employees as well as consultants and sub-contractors) involved in data processing operations from January 1, 1999 until December 31, 2000. Remember, Y2K non compliance issues may not surface until later in the Year 2000.

Above all, assume that come the millennium you will be severely damaged by the Y2K bug. Gage all of your activities with the full foreknowledge that you will be the plaintiff in one or more lawsuits. It is hoped that these lawsuits can be avoided. Yet, without diligent preparation of evidence, you will not be ready should they occur.

Problem Type	Examples
19xx assumed as year	Two-digit year instead of four-digit year. Only a 100-year range -- 00 through 99 -- is possible. Occurs with Julian, Gregorian, and other date formats. Some examples are mm/dd/yy and yydddd.
User interface does not allow four digit years to clarify century	Users can only input two-digit years on screens. Batch parameter input limited in same fashion.
Year is part of file or tape name	Usually occurs in backup and archiving routines -- for example, file0297.txt.
Sorting puts 20xx dates before 19xx	00, 01, 98, 99 instead of 1998, 1999, 2000, 2001.
Date within programs is truncated	If you input 1996, the program stores 96. If you input 2001, the program stores 01.
Century is hard coded	19 is always displayed in format of two-digit years.
Assumption that century is always derived from today’s date	If you input 00 for 2000 during 1997, the program stores 1900. If you input 99 for 1999 during 2000, the program stores 2099.
Possible user misinterpretation	For example, 03/02/01 can be either March 2, 2001 (mm/dd/yy, which is common in the U.S.); February 1, 2003 (yy/mm/dd, which is a common sort order); or February 3, 2001 (dd/mm/yy, the international format). Another example is that "01/02/00" reports as "1/2/" because of zero suppression.