Y2K compliance and records retention

The so-called Y2K problem has gone through a long cycle of maturation. It began as a curiosity, was discussed in computer circles as an insider issue, and passed to the outside world, first as a scare story, which then transmuted into a legitimate business issue. It grew into a matter requiring fullblown government hearings and extensive business auditing and compliance, and billions of dollars to remedy. As time drew nearer, it became something of an emergency. Now, as time grows ever so short and we are finally persuaded that life will, in fact, continue, we have at last begun to think beyond the dreaded date itself and consider life afterwards.

We have begun to ask weighty questions such as "Gee, will we get sued if our Y2K compliance isn't perfect?" "What kind of Y2K compliance documentation do we need and for how long?" Such questions are themselves proof of a fully mature crisis. Nothing less would provoke them, and only our expectation of surviving more or less intact permits us to care about the answers.

Boiled down to its essentials, the legal risk is quite simple: your computer makes a Y2K error that botches some sort of important transaction and you get sued for the error. If the error costs the plaintiff a great deal of money or causes great injury, you get sued for a great deal of money. If the computer makes many such errors, you get sued many times. If many errors cost many people much money or injure many people, you wind up getting sued for a really large amount of money. If you don't realize all of this until the lawsuits start coming in, you are lost, since it is much too late to fix anything.

In practical reality, the situation is somewhat more complicated. The nature of the transaction botched, the identity of the other party, the legal theory underlying the suit, and other matters all play into the outcome. It is also possible to be the plaintiff, even though your Y2K compliance is the issue.

Potential Plaintiffs

The first step in analyzing the risk is to determine precisely who is the plaintiff. This could be any of a number of parties, some dependent upon the nature of the transaction, some not.

In the case of the computer system at a hospital that fails due to a Y2K bug, any number of parties are in one way or another potentially "injured" by such a situation. If patients in the hospital suffer new or aggravated injuries or substandard care due to the bug, they are obviously potential plaintiffs - their "injury" is obvious.

If the system is used for accounting as well as patient management, vendors, customers, and other business partners (including partners of partners, customers of customers, and other remote parties, since any serious problem may cascade through the system for a long distance) may also sue; nonpayment, non-delivery of services, and other contractual matters are also "injuries" that may be litigated for compensation.

And this is not the end of the list. If the facility receives government funds through Medicare, Medicaid, or other federal programs, there might be liability if the failure to repair the bug violated some statutory or regulatory requirement attached to the receipt of federal money. Investors and stockholders also join the list of potential plaintiffs, if the glitch damages the organization's profitability and share price.

Other potential plaintiffs include employees and unions (if payroll and retirement calculations are erroneous), citizen advocacy groups ("...a shameful [failure/conspiracy] to deprive [senior citizens/poor people/minorities/women/immigrants/illegal aliens] of [civil rights/ health care/prenatal care/decent quality of life/access to the system] is being perpetrated!" [construct your own theory from the choices]). Last but not least, there are the assorted stray citizens (the guy who wanders in off the street to use the restroom and is caught in the elevator at midnight on December 31,1999).

Although the basic legal scenario is simple, identifying the plaintiff is more complicated. This complication rises exponentially if there are multiple computer systems involved, large numbers of affected customers, many potential affected downstream parties, complex potential effects from any problem, or large numbers of different products or transactions involved. Additional complications arise for governmental organizations because they have a different set of relationships with their service providers and constituents and are immune to many types of lawsuits.

Potential Legal Theories

There are a number of legal theories possible in a lawsuit based upon a Y2K failure, most of which depend upon the status of the party advancing the theory. Among them:

Breach of contract. Breach of contract is the failure, without legal excuse, to perform any promise that forms the whole or part of a contract (Black's Law Dictionary 1979). This is probably the most common Y2K scenario, for fairly obvious reasons: commercial organizations (and many government organizations) are bound by contractual relationships with service providers, customers, and others. A serious computer problem will disrupt the ability to meet obligations, resulting in economic damage to the contracting parties. That damage forms the basis for a breach of contract lawsuit.

Negligence. Negligence is the failure to do something, which a reasonable man, guided by ordinary considerations which regulate human affairs, would do; or it is the doing of something which a reasonable and prudent man would not do (Black's Law Dictionary 1979). This is a theory that is available to many parties all that need be proven is that the defendant knew of the Y2K problem, knew it would cause injury to others, and failed to correct the problem. The precise relationship of the parties is not important.

Breach of fiduciary duty. A fiduciary relationship exists when there is a reposing of faith, confidence, and trust, and the placing of reliance by one upon the judgment of another (Black's Law Dictionary 1979). If the organization handles money or assets for others in the capacity of a fiduciary (for example, as a trustee), it is held to a much higher duty of care regarding those assets than are other commercial parties. Failure to meet this higher duty by, for example, calculating interest incorrectly in a computer, gives rise to a separate cause for damage, and a separate basis for a lawsuit, even based on facts that would not support other legal theories.

Fraud. Fraud is an intentional perversion of the truth for the purpose of inducing another to part with some valuable thing or to surrender a legal right (Black's Law Dictionary 1979). Such an allegation might arise if, for example, a stockholder felt misled about the state of an organization's Y2K fix (stockholder suits over an organization's alleged misrepresentations are quite common), and purchased stock based upon that misapprehension, then saw the stock price go down when the problem arose.

There are undoubtedly more legal theories that can, and probably will, be used to litigate Y2K problems, but the above list should suffice to illustrate the nature of the beast. As can be seen, the legal theories are all of the mundane garden variety. The information manager accustomed to dealing with the risks and headaches of standard commercial litigation will discover few novel legal theories waiting among the approaching Y2K litigation. This means that many conventional strategies and policies will maintain their utility when applied to Y2K compliance records.

Special Situations

There are classes of lawsuits other than those discussed above that might well arise out of Y2K problems.

For example, your organization might be a computer consultancy doing Y2K fixes for other organizations. In that case, you are likely to be the defendant if a client experiences major problems.

You might also be an organization involved in a lawsuit with its own insurer. For example, an insurer might take the position that Y2K was a foreseeable problem that should have been corrected, and therefore outside the scope of business interruption insurance coverage.

An organization's computer system might also be governed by specific laws or agencies. For example, the computer controlling a nuclear reactor is subject to oversight by the Nuclear Regulatory Commission, which would obviously have a strong interest in auditing Y2K compliance efforts for it.

Finally, an organization might keep compliance information on its subcontractors or other business partners, to ensure that it incurs no liability from their failure to become Y2K compliant.

The Purpose of Y2K Compliance Records Retention

As with all other records whose retention is being contemplated, the question must be asked, "For what purpose are these records retained?" In this case, as in most others, three standard answers apply:

1. The organization needs to review its own work for business purposes. A retention period based upon this consideration is, as always, self-evident. Keep the records as long as such business purposes remain.

2. The organization needs the records to demonstrate its compliance with the requirements of some regulatory agency. In this case, the answer is also probably simple. In order to require the keeping of the records, the agency must promulgate a regulation, which will likely have a retention period. Even if it does not, a retention period may be negotiated with the agency, thereby providing the necessary certainty in the decision.

3. The organization fears lawsuits. In this case, the records are evidence that the organization complied with its legal duties, made best efforts, conducted due diligence, and whatever other legal formulations are applicable, to show it tried hard to do the right thing and ought not to get hammered in court. The obvious answer here is to keep the records as long as you might be sued. But how long is that?

Y2K and Statutes of Limitation

Statutes of limitation are conceptually quite simple. For any of the legal theories stated earlier, a period of years begins to run when the injury complained of occurs, and at the end of that period, lawsuits are barred. There are complications, however. Many injuries are hidden, not showing up for a long period of time after the act that caused them. Occupational diseases such as lead poisoning are one example. Statutes of limitation therefore often provide that the period does not begin until "the injury is discovered, or could have been discovered in the exercise of reasonable diligence" or some similar formulation. Sometimes, there is also a period of repose, which sets a final, absolute period "but in no case for more than 12 years after the act complained of" or similar language.

This frames a finite period within which a legal risk can exist. If the magnitude of the risk can otherwise be quantified, good risk management analysis yields solid information about the period within which the records' utility exceeds their burden.

All would thus be well if any residual problems materialized on January 1, 2000. Simply find the longest limitation period applicable to your operations, and work back from there based upon risk analysis and other standard parameters. However, in the case of a Y2K glitch, not all problems might manifest themselves immediately after the turn of the century. Some of this is due to the nature of the programs and data themselves - a flawed calculation involving some account might simply not be made for a considerable period of time afterward.

Some, on the other hand, are due to the nature of the fixes themselves. Few of the fixes actually involve simply converting two-digit dates into four-digit dates. This would require tremendous time and effort, as data fields, input and output fields, and other parameters must be adjusted using this method. Instead, programmers use a variety of other sometimes very complicated - techniques to achieve the desired result. Each of those fixes introduces the possibility of new bugs, whose outputs are uncertain (de Jager 1998). Some of those erroneous outputs may not occur until well into the future. And of course, there is always the possibility that original bugs remained undetected and unfixed.

An additional complication is that it might be very difficult to determine the precise scope of the risk itself. An organization might find itself with few or no Y2K problems, or it might find itself on the verge of collapse despite its best efforts, or someplace in the middle. Even supposing the risk window can be identified using limitations periods and the like, if the scope of the risk cannot be accurately identified, legitimate risk analysis cannot be done, and the window cannot be shortened.

An Approach

Synthesizing these many considerations into a records retention policy for Y2K compliance records therefore involves asking a series of questions:

Who will be the prospective plaintiffs or parties that these records will be used to assuage or defeat? What will be their legal theories?

What are the limitations periods and periods of repose or other risk periods applicable to these parties?

How long after the turn of the century may we reasonably expect serious problems to arise in our system?

The answers to these questions allow formulation of the maximum period of risk for which the records will prove useful.

Do we expect serious problems at all?

If we do, are they numerous or few?

Do we fully understand where they will arise, or must we brace for unexpected catastrophes?

Will they likely arise soon after the turn of the century, or may we expect them to crop up much later?

Do we have any idea of the dollar value of the expected problems?

What will be the cost of storing these records for a given period? Is there any downside to excessive retention of the records?

Answers to questions such as these allow an assessment of the actual magnitude and value of the risk, and therefore a judgment as to the value of whatever effort and expenditure are required to mitigate that risk. In many cases, the longest potential period of retention will prove unnecessary, but in any event, the period chosen can be chosen with confidence.

BIBLIOGRAPHY

Black's Law Dictionary. 5th Edition. 1979.

de Jager, Peter. "Y2K: So Many Bugs...So Little Time." Scientific American Magazine. December 1998.

John C. Montana, J.D., is "chief records brain" of Brain Core, a records management consulting firm. Montana specializes in records retention and destruction, and the legal requirements and ramifications of records retention. He is also a practicing attorney. He may be reached at montana@csd.net.

Copyright Association of Records Managers and Administrators Inc. Apr 1999
Provided by ProQuest Information and Learning Company. All rights Reserved